2009-03-18

Bolometer Baseline Noise Improvement

I integrated the bolometer with the RS-232 sampler to perform some baseline measurements and discovered it had enormous noise problems. It is no wonder the digital display system never performed very well. Here is a chart of the measured bias power taken over night.

Initial *Horrible* Baseline Noise

The time constant of the previous measurement systems prevented resolution of the instantaneous noise floating on the bias power. Part of the noise seen is the relatively poor ADC noise floor, but the periodic noise bursts are the result of RFI from my QRSS beacon Hellschreiber cycles. This was not observed before as the previous modulation was essentially "CW" in the sense the local field was amplitude modulated only very rarely (Just a brief CWID every full beacon cycle). The Hellschreiber beacon interval bounces the loop much more.

Cleaning Up The EMC Problem

Adding bypass capacitors to the servo amplifier supply and the amplifier compensation pin improved things enormously:

Much Improved Baseline Noise After Supply and Loop Filtering

Here we can see good resolution of RF and optical delivered powers. Events labelled are:

  1. Application of red laser pointer beam to sensor.
  2. Removal of sensor housing and disturbance of reference heatsink associated with connection of the sensor head lash-up to the RF signal generator.
  3. Application of RF power to sensor in steps, eventually saturating it then backing off to 15 mW or so.
  4. Application of red laser pointer beam to sensor.
  5. Application of green laser point beam to sensor.
  6. Removal of RF power from sensor.
  7. RFI from QRSS Beacon (also visible just after #2).

Laser power application was by rather unsteady hand-held aiming at the sensor plate. The entire experimental set-up being a rather poor lash-up.

More RFI Filtering

Additional bypassing of the offset null essentially cured the RFI problem. The first three bursts visible here are leakage into the sensor itself from my lousy "BK Precision 4040A" signal generator which will leak RF floating on the mains or otherwise absorbed by its unshielded case into the output. The RF input was left connected to the (unpowered) signal generator. Disconnection of this pushed any RFI effects down into the ADC noise.

Further Improvement of RFI Problems

Note the periodic wiggle to the baseline. This appears to be uncompensated thermal drift and correlates to the room temperature cycling up and down with the air conditioning. The large narrow impulses are where I have disturbed the sensor by wafting air towards it or removing the draft exclusion covering. The smaller impulses are somewhat more mysterious. The initial downward drift is likely due to a reference heatsink temperature drop as I turned the lab lights off and was largely absent from the room while data was being collected.

Here is a much longer baseline series collected after filtering was added to the sampler hardware to suppress any RFI picked up by its fairly high impedance inputs. The reading before 10 pm is from 80 mW of applied RF to check the system calibration. Beacon RFI pulses are visible before midnight at which point I unplugged the coax leading to the leaky signal generator previously described.

Much Longer Baseline Series After Sampler Improvements

Note the lack of wiggles over the night where the lab was closed up and the air conditioning quiescent. I left the room and turned off the lights just before 2 am, the effect is clearly visible as the reference heatsink cools. Prior to this the lab temperature was rising slowly after the air conditioning cut off for the night. Once the sun rises the air conditioning starts cycling again, causing rapid quite significant baseline shifts. The impulses associated with the wiggles may be power supply glitches associated with the air conditioner compressor mains loading.

Supply Glitches?

To test this hypothesis, I set up the sampler to use all three channels. Channel 0 captured the bias heater supply voltage, channel 1 an attenuated reading of the bench supply voltage, and channel 2 a stable reference voltage from a pair of AA batteries to ensure the sampler was not itself drifting. The result is most enlightening and also somewhat concerning:

Bias Heater Voltage With Supply Voltage Monitoring

The 3 volt battery supply is essentially a perfectly straight line, only dithered by the remaining ADC noise which is about 2 LSB currently. The sampler drew 120 uA from the batteries (an input impedance of about 24.3 k), causing no measurable voltage droop over night. (Not sure about the glitch near 12:00, it was roughly when I entered the room, perhaps I disturbed the alligator clip connections to the battery. The four smaller single-bit glitches are likely ADC noise, especially as the battery voltage is likely sagging over time and the noise will naturally shift down with it, stochastic processes giving the odd outlier as noise adds to the signal below the ADC resolution/noise floor. Consumer AA batteries aren't exactly precision voltage references anyway.)

The "12 V" bench supply (attenuated by 3 for measurement purposes) on the other hand is clearly all over the place. Not only does its average voltage drift quite significantly (perhaps itself correlated to temperature), there are very significant voltage spikes. I've noted in the past clicks and pops in audio circuits without much supply rejection - now I have somewhat more scientific proof that the supply has some problems. It is an Electronics Australia kit from back in the 90s - the so called "Recession Compatible" power supply. I have a pair, and they have been very useful over the years, it is possible that the electrolytic capacitors in them have degenerated from age. I'll dig out the schematics and see what I can do to eliminate the problem.

The 5 volt rail regulation must be fairly good, the 3 volt battery voltage is almost perfectly flat, so the old LM7805 regulating the digital and analogue electronics seems to be OK. This was the main thing I wanted to determine from this particular run.

The bias heater readings are quite similar to the previous day. Over the night the air conditioning only cut in once. The spikes associated with the thermally related maxima and minima are still unexplained now that supply glitches are eliminated. It may be air movement from the air conditioning output registers; when the air circulation first starts there is more turbulent flow until a stable circulation is established. Similarly when the air cuts off it takes a moment for convection to be re-established after the air conditioning forcing stops. With the current draft exclusion just being a potting box placed over the sensor, which itself is just held to a heat sink with an alligator clip, it is perhaps unsurprising that changes in air movement in the room have significant transient effects.

Sampler Experience & Development

As an aside, to prove the sampler didn't just have a noisy channel I swapped the channels around:

Swapping The Channels Around to Check for a Noisy Channel

The sample rate does drift a bit, more than 1% it seems. It sits around 43-44 Hz but at the end of each data run I need to recalibrate the sample rate by counting the samples collected and comparing them to the capture time. No doubt the sample rate is drifting around with temperature but the data content itself is likely the main culprit (as it changes the amount of characters sent over the RS-232 link, I am suppressing leading zeros and the sampling bursts are synchronously related to the communication events). Code changes to the sampler firmware would allow more deterministic sampling, and perhaps the sampler should be clocked with an xtal instead of the internal RC oscillator. I'll probably work on this shortly and post the firmware changes along with the supporting tool chain I've developed.

As can be seen from the Gnuplot output evolution, the sampler and its data management tool chain has been vastly improved during this work on the bolometer (and continues to improve). Like many projects, using the bolometer and sampler as mutual test vehicles has been very useful. This seems a fairly common practice in R&D; in much the same way C was developed along with UNIX and (closer to home) my Object-Relational Mapping and GUI Interface Compiler was developed along with several .NET and PHP5 web development projects. This kind of interrelation between project requirements is often very helpful and IMO breeds better quality outcomes for all the projects involved.

Leave a comment on this article.

Parent article: RF and Optical Bolometer.