L3G4200D random spikes

Question

I've searched this forum a bit in regards to the L3G4200D gyroscope, and haven't seen this problem mentioned, but I have seen others talk about it on other forums. I am seeing a strange large value in my output when the gyroscope is stationary. Unfortunately no one seems to has been able to answer why this is, so thought I'd ask around

So, I am collecting data from the gyro using i2c at 400kHz (fast mode), collecting the gyroscope data using multibyte read (six bytes at a time). Sampling at 100Hz (tried the top 800Hz too), also tried with the filtering on and off at different values. I'm not using the interrupt pin, but I am using the 'block data update' attribute in the GYRCTRLREG4, so that the data isn't outputted until both LSB and MSB are read. Full 2000dps and not done anything with the FIFO. I can post my exact register values if it helps, but figure most of you wont have the datasheet to hand.

The image below shows my problem. The data being output is good, calculated correctly (to my knowledge) and general noise is very acceptable. But then I noticed these annoying 'blips' appearing randomly when the device is stationary. If I leave it still for a couple of seconds I'll get one of these spikes, always equaling around 250-255 (thus ~18 when converted, using '(output * 70) / 1000'). The spikes, as I say, are random, can appear in any plane (in the image below you can see the first spike in the X plane, second in the Y), always around the same value, and one, two, or all three can happen at the same time. The large value is only for a single sample, then goes back to normal.

I saw in another thread somewhere that I should be using the block data wait function in GYRCTRLREG4, as I mentioned before, but no change. I've narrowed the problem down to being when the MSB is zero or higher, i.e. a positive number, then when the MSB and LSB are combined I'm getting these large numbers. For example, I grab the two bytes necessary for the X plane, I get a -6 in the LSB, and a 0 in the MSB, combining them gives me 250, then converting gives (250 * 70) / 1000 = 17.5 dps (i.e. too large for stationary/incorrect). In the same sample, the two bytes for the Y plane are -3 LSB and -1 MSN, combining them gives -3, and converting gives -0.21 (i.e. expected/correct).

Been on this problem for days now, I'm also seeing a bit of these random spikes with my magnetometer, so I'm thinking it's me reading the device (via i2c) incorrectly?

Any suggestions or things to try are really welcome!

Answer 1

Because you're observing a similar problem with your magnetometer my guess is that you have a problem on the I2C bus. While it could well be a code problem because of the intermittent operation first I'd check how the bus is connected. A few things to check / try:

• If you're not using external pull-up resistors try 10K pull-up resistors on SDA and SCL. The internal pull-up on most microcontrollers won't be strong enough.

• If possible reduce the length of bus as much as possible and try to keep it routed away from high-speed signals.

• If using a breadboard try to keep the connections as direct as possible to avoid excess capacitance.

• If you're using prototype boards that already include pull-up resistors they may be ending up in parallel and you may in effect have a pull-up resistance value that is too low.

• If you can arrange access to a scope that would be ideal to make sure the clock and data lines look nice and square and aren't skewed too much.

If those steps don't work Texas Instruments has the Troubleshooting I2C Bus Protocol application report that goes into more detail on calculating the pull-up resistors and problems you can run into with capacitance.

Answer 2

What may be happening is that a new sample is being take between reading the LSB and the MSB. So if MSB = 0 and LSB = -4 you should get 252, or about 1g. If the next reading is MSB = 1 and LSB = 2, you should get 258, which is reasonable. They problem is when for 1 sample only the MSB has updated to 1 and the LSB is still -4 you get 508, about 2g, which might be this blip.

BDU on CTRL_REG4 is supposed to prevent this. Maybe read that register off the sensor and ensure the block hold is enabled?

Answer 3

try with a Median Filter and these spikes will fade away.

Please refer to my question here on StackExchange and then read this post about the same problem