Arduino, Wire, and I2C Part 4: Noise and analysis

These weekend I spent some time recording sample data sets from the sparkfun SEN-10724 and looking at it. I'd say I was analyzing the data, except that might give the impression that I actually have a good idea what I'm doing.

The recording of data, I actually set up using the sparkfun "ethernet pro" board, which is basically an Arduino with built-in ethernet and seemingly poorly designed voltage regulation (it gets pretty hot if you power it with the intended voltage levels). I felt more comfortable using the ethernet rather than serial-over-USB since I would be sending more data than was reasonable for the 9600bps that the Arduino UNO is fixed at (over USB - the firmware for the atmega8u2 that handles the USB-to-serial interface is programmed such that it will only operate at 9600bps).

After finding a few errors with decoding the data (mostly in the PC side, the microcontroller was programmed to send the raw measurements as-is), I found that the ADXL345 accelerometer has noise levels way out of spec. I've plotted the measurements and attached images of said plots at the end of this post. The XYZ measurements of the ADXL345 all had significant levels of noise (RMSD 5-12 LSBs) and the magnetometer had noise on the X-axis only (RMSD 9 LSBs). During the test data recording, the sensor board was in a breadboard sitting on my desk with no significant sources of vibration.

One concern I had is that the schematic for the SEN-10724 had two .1μF capacitors "near" the ADXL345. The datasheet calls for a single .1μF capacitor between ground and V_DDI/O, and for a 1μF tantalum capacitor at V_S, with an optional 10μF tantalum capacitor in parallel.

If the circuit instead only has a .1μF capacitor at V_S, that might explain why the measurements look so noisy. In-circuit measurement of the capacitors is impossible, and I don't have a stockpile of SMD capacitors (strangely enough, after the 3 separate LED cube builds) to replace it with. Time to email customer support.

GPS receiver

I spent a chunk of today implementing tools to capture and examine the data from a Trimble Copernicus GPS receiver chip.  Unfortunately, even though it supports the output of "raw" measurements, the pseudorange (in meters) can't be derived easily (if at all), and the Doppler measurements appear to be an order of magnitude larger than they should be.  The SNR measurements look appropriate (in dB*Hz), but I'm uncertain about the phase measurements.  It may turn out to be totally useless for science, which would be disappointing.

I'll have to look into this further next week.

AVR programming

Today marked a bit of progress on a couple of my microcontroller projects.  First, I discovered the reason that my LED cube controller board wasn't working.  It turned out to be because I had swapped two control lines on the schematic.  Unfortunately, it's not something I can fix in software.  The swapped lines are a clock pulse line and an output enable line, going to each of eight '574 8-bit flip-flop chips.  The two lines work in completely different ways (clock pulse latches the flip-flop outputs on low-to-high transition, and output enable is active low), and are being driven in completely different ways (output enable is supposed to be a shared signal driven by a single pin from the microcontroller, while the clock pulse is supposed to be individually selected one at a time from a 3-to-8 multiplexer chip's output).  So there really isn't a clean (or perhaps even viable) solution to fix this in software.  As a result, I made a revision "C" of the board design and submitted it for manufacture.  The LED cube is getting pretty expensive at this point.

The other bit of success I've had was in hooking up a Trimble Copernicus GPS receiver-on-a-chip that's mounted on a Sparkfun breakout board, through a logic level converter to an atmega8u2 breakout which is programmed to be a USB-to-serial device.  It.. sort of worked, in that I could see bits of data being sent from the receiver, but the firmware on the atmega8u2 would only work at 9600 bps, while the Copernicus talks at 38400 bps or 4800 bps, depending on which interface you chose to use.

The bad news is that the tool chain provided by Ubuntu is way out of date and I can't really compile for the atmega8u2 with what's been provided.  Newer versions of the tool chain can, in theory, be built, but the instructions as listed in that link don't actually work.

After much hair pulling, I managed to find this sticky thread on avrfreaks.net.  I had to do a little bit of tweaking to get the scripts to download the source files to use a site that was actually up in a couple of instances, but the level of hassle to get that tool chain built and installed was far less than what I was going through with the others.  I was able to build LUFA.  I did not, however, install any of the LUFA bootloaders onto the sparkfun device, opting instead to reinstall the original sparkfun firmware to see if it was capable of switching baud rates.  It was, and I was able to confirm NMEA messages coming out of the Trimble receiver chip.  Progress.

I'm still 6 days away from having the Rev. C LED cube controller boards in my hands, but I'm hopeful that when I get that put together, I'll finally have that working as well.