Following the manufacturer's recommendations, I put a 1μF capacitor in the circuit to decouple power supply noise at VS. This meant replacing the .1μF capacitor that sparkfun had put there. Not a particularly big deal, and well worth it as you can see in the attached graph.
The down side is that the vertical axis, whatever that happens to be, remains fairly noisy on the accelerometer and to a lesser extent, on the magnetometer, but clearly the non-vertical axes have had significant reductions of noise. For the purposes of comparison, I did offset the 1μF data set so that the two sets of data shared a common mean value. The 1-sigma error shading is computed solely from the .1μF data set, however.
Showing posts with label ADXL345. Show all posts
Showing posts with label ADXL345. Show all posts
Thursday, October 6, 2011
Sunday, October 2, 2011
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 VDDI/O, and for a 1μF tantalum capacitor at VS, with an optional 10μF tantalum capacitor in parallel.
If the circuit instead only has a .1μF capacitor at VS, 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.
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 VDDI/O, and for a 1μF tantalum capacitor at VS, with an optional 10μF tantalum capacitor in parallel.
If the circuit instead only has a .1μF capacitor at VS, 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.
Labels:
9dof,
accelerometer,
ADXL345,
arduino,
atmel,
avr,
electronics,
ethernet pro,
gyroscope,
HMC5883L,
i2c,
imu,
magnetometer,
maker,
microcontroller,
SEN-10724,
sparkfun
Friday, September 23, 2011
Arduino, Wire, and I2C
In previous postings, I described connecting a sparkfun.com sensor board to the Arduino and getting magnetometer readings from it. In this post, I intend to go into a little more detail about how I2C works, while providing similar functionality using the accelerometer on the same board.
The first thing to understand is that I2C is a completely 8-bit bus protocol, which means that all addresses and all data are 8-bit quantities (0-255). The bus consists of a single "master" with up to 112 unique "slave" devices. The limit of 112 is due to the fact that a device address is actually a 7-bit quantity (more on this later), and 16 addresses are reserved. Multiple masters are apparently possible, but aren't relevant for this project. Slave devices can't talk to other slave devices. Off-the-shelf devices, like the three on the SEN-10724 board, have pre-assigned addresses managed by a central authority.
Devices have a 7-bit address. This 7-bit address is stored in the 7 MSB (most significant bits) of an 8-bit quantity when sequenced on the bus, with the least significant bit indicating whether the operation is a read or a write (1 or set being "read"). As an example, the HMC5883L datasheet lists 8-bit addresses 0x3D for read, and 0x3C for write. Convert these to binary and you'll find a 7-bit address of 0x1E followed by a binary 1 for read or 0 for write. Some manufacturers will list only a 7-bit address in their data sheet, some will list 8-bit addresses, some will do both.
The datasheet for the Analog Devices ADXL345 lists both - 0x1D is the 7-bit address, which results in 0x3A for writes and 0x3B for reads. However, it also supports an alternate addressing of 0x53/0xA6/0xA7 if pin 12 is tied to ground. The schematic for the sparkfun board indicates that pin 12 is indeed tied to ground, so let's assume that we're going to be using alternate addressing for that device.
Each I2C device will also have a number of registers that are readable and/or writable. Table 16 on page 14 of the ADXL345 datasheet lists this device's register map. For this project, we're most interested in registers 0x32-0x37. If you look at the table, you'll see how manufacturers design for 16-bit quantities, which is (at least in this case and in the case of the HMC5883L) to have adjacent 8-bit registers containing the most significant and least significant bytes of a 16-bit quantity.
Let's start with the X axis on the accelerometer, which according to the board's silkscreen is the side-to-side direction (along the short edge of the board). The following Arduino sketch implements a simple program that prints out the X axis acceleration once a second.
If you upload this sketch to your Arduino, with the IMU connected as described in the earlier post, you'll probably get a sequence of zeroes in the serial monitor. If, for example, you tried to change the address in the above code to the primary (0x1D), you probably wouldn't see anything at all. So why is it only showing zeroes, even if I shake the heck out of the board? My guess is that the device doesn't start up in a mode where continuous measurements are taken (which is how the HMC5883L operates), and that to get these measurements, other registers must be manipulated...
To be continued...
The first thing to understand is that I2C is a completely 8-bit bus protocol, which means that all addresses and all data are 8-bit quantities (0-255). The bus consists of a single "master" with up to 112 unique "slave" devices. The limit of 112 is due to the fact that a device address is actually a 7-bit quantity (more on this later), and 16 addresses are reserved. Multiple masters are apparently possible, but aren't relevant for this project. Slave devices can't talk to other slave devices. Off-the-shelf devices, like the three on the SEN-10724 board, have pre-assigned addresses managed by a central authority.
Devices have a 7-bit address. This 7-bit address is stored in the 7 MSB (most significant bits) of an 8-bit quantity when sequenced on the bus, with the least significant bit indicating whether the operation is a read or a write (1 or set being "read"). As an example, the HMC5883L datasheet lists 8-bit addresses 0x3D for read, and 0x3C for write. Convert these to binary and you'll find a 7-bit address of 0x1E followed by a binary 1 for read or 0 for write. Some manufacturers will list only a 7-bit address in their data sheet, some will list 8-bit addresses, some will do both.
The datasheet for the Analog Devices ADXL345 lists both - 0x1D is the 7-bit address, which results in 0x3A for writes and 0x3B for reads. However, it also supports an alternate addressing of 0x53/0xA6/0xA7 if pin 12 is tied to ground. The schematic for the sparkfun board indicates that pin 12 is indeed tied to ground, so let's assume that we're going to be using alternate addressing for that device.
Each I2C device will also have a number of registers that are readable and/or writable. Table 16 on page 14 of the ADXL345 datasheet lists this device's register map. For this project, we're most interested in registers 0x32-0x37. If you look at the table, you'll see how manufacturers design for 16-bit quantities, which is (at least in this case and in the case of the HMC5883L) to have adjacent 8-bit registers containing the most significant and least significant bytes of a 16-bit quantity.
Let's start with the X axis on the accelerometer, which according to the board's silkscreen is the side-to-side direction (along the short edge of the board). The following Arduino sketch implements a simple program that prints out the X axis acceleration once a second.
#include <Wire.h>
// Wire library uses 7-bit addresses and automatically
// sets the r/w bit
static const uint8_t ADXL345 = 0x53;
static const uint8_t DATAX0 = 0x32;
void setup()
{
Wire.begin();
Serial.begin(9600);
}
void loop()
{
// Put the read address on the bus
Wire.beginTransmission(ADXL345);
Wire.send(DATAX0);
Wire.endTransmission();
// Request data starting with the X register
Wire.beginTransmission(ADXL345);
// 2 bytes gets us the LSB and MSB of the X data
Wire.requestFrom(ADXL345, (uint8_t)2);
// store the data in a signed integer quantity
int16_t x;
// pointer to use to store the data
byte *p = (byte*)&x;
// wait for 2 bytes to be available
while (Wire.available() < 2) {}
*p = Wire.receive();
p++; // advance the pointer to the next 8 bits
*p = Wire.receive();
Wire.endTransmission();
Serial.println(x); // finally, print the quantity
delay(1000); // delay a bit to avoid flooding
}
If you upload this sketch to your Arduino, with the IMU connected as described in the earlier post, you'll probably get a sequence of zeroes in the serial monitor. If, for example, you tried to change the address in the above code to the primary (0x1D), you probably wouldn't see anything at all. So why is it only showing zeroes, even if I shake the heck out of the board? My guess is that the device doesn't start up in a mode where continuous measurements are taken (which is how the HMC5883L operates), and that to get these measurements, other registers must be manipulated...
To be continued...
Labels:
9dof,
accelerometer,
ADXL345,
arduino,
gyroscope,
HMC5883L,
i2c,
imu,
magnetometer,
maker,
SEN-10724,
sparkfun
Monday, September 12, 2011
"9" degrees of freedom IMU on Arduino
This past weekend I finally got around to playing with the "9 degrees of freedom" sensor board (SEN-10724) I'd purchased from sparkfun.com. I'm not sure if it makes sense to call it that, but what you get is a 3-axis gyro, a 3-axis accelerometer and a 3-axis magnetometer. The gyros give you information about rotational acceleration, the accelerometer measures linear acceleration, and the magnetometer works like a 3-axis compass.
The circuit off to the side there shows how I managed to get it hooked up and talking through my Arduino UNO. The short of it is this: it's a 3.3V device (well, 3 devices) and it needs pull-up resistors (I used 4.7K) on the data and clock lines in order to function. It's wired up to the analog inputs 4 and 5 on the Arduino board, which is what the provided "Wire" library uses to talk to devices like this, that use the I2C protocol.
Honestly, I'm a little bit unclear as to how it's actually able to talk to the sensor stick/IMU (inertial measurement unit) without doing level conversion between the 5V Arduino and the 3.3V IMU, but it does seem to work reliably in this configuration. If I were doing something more significant (a production board, for example) I'd probably be a bit more careful about matching the signal levels.
The Wire library for Arduino is just a basic library for talking to I2C devices. Getting into the specific interfaces is another matter, though for a quick start, I used the HMC588L compass library provided by Love Electronics in the UK. This was enough to get me started and verify that I was able to communicate with the magnetometer. There's a pretty decent tutorial on that page on how to use the library, though the sample works pretty well as-is. If you have trouble compiling the sample code, I found that for some reason it has a period (".") at the very beginning of the file - remove that period to make it compile.
Quick update - looking at the example .pde file in linux using hd (hex dump), it turned out there were three unprintable characters at the beginning of the file. The easiest way I found to fix the problem was to remove any odd characters before the /* at the start of the file, then save it as a new sketch. That new .pde file can then be used to replace the original example .pde file in the library, or you can just use the fixed version in your sketchbook.
The circuit off to the side there shows how I managed to get it hooked up and talking through my Arduino UNO. The short of it is this: it's a 3.3V device (well, 3 devices) and it needs pull-up resistors (I used 4.7K) on the data and clock lines in order to function. It's wired up to the analog inputs 4 and 5 on the Arduino board, which is what the provided "Wire" library uses to talk to devices like this, that use the I2C protocol.
Honestly, I'm a little bit unclear as to how it's actually able to talk to the sensor stick/IMU (inertial measurement unit) without doing level conversion between the 5V Arduino and the 3.3V IMU, but it does seem to work reliably in this configuration. If I were doing something more significant (a production board, for example) I'd probably be a bit more careful about matching the signal levels.
The Wire library for Arduino is just a basic library for talking to I2C devices. Getting into the specific interfaces is another matter, though for a quick start, I used the HMC588L compass library provided by Love Electronics in the UK. This was enough to get me started and verify that I was able to communicate with the magnetometer. There's a pretty decent tutorial on that page on how to use the library, though the sample works pretty well as-is. If you have trouble compiling the sample code, I found that for some reason it has a period (".") at the very beginning of the file - remove that period to make it compile.
Quick update - looking at the example .pde file in linux using hd (hex dump), it turned out there were three unprintable characters at the beginning of the file. The easiest way I found to fix the problem was to remove any odd characters before the /* at the start of the file, then save it as a new sketch. That new .pde file can then be used to replace the original example .pde file in the library, or you can just use the fixed version in your sketchbook.
Subscribe to:
Posts (Atom)




