Unable to read accelerometer [Archive]

View Full Version : Unable to read accelerometer

StephenNutt

13-02-2012, 20:30

We've been trying for several days to read values from the accelerometer with no success. We have verified the accelerometer works correctly by accessing it using an Arduino. We have tried with both the round and flat DB37 cables to connect the digital breakout board, fixing our broken ribbon cable as described at the US First site. We have tried two I2C cables and two digital breakout boards.

Stepping through I2C::Transaction in I2C.cpp, aborted is always being set to true on line 102. There is no documentation as to what this means, but on lines 102 and 103 data and dataHigh are being set to 0. If anyone has any thoughts, or could step through ADXL345_I2C::GetAccelerations down into I2C::Transaction to see what they get we would be most grateful.

Thanks

Steve

Ernst

13-02-2012, 23:49

The accelerometer is an analog device. Try hooking it up to the analog breakout instead of the D I/O board. You might have a bit more success.

Also, you may want to reference this PDF (http://www.usfirst.org/sites/default/files/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2012_Assets/Accelerometer-Gyro.pdf). It contains information on the 2012 Accelerometer and Gyro.

Cuog

14-02-2012, 00:01

wireties

14-02-2012, 00:51

FIRST Team 1296 is using the 2012 I2C accelerometer and we are getting data. It is very noisy and it drifts (almost too much to be usable) but the I2C link seems to work. We are in the middle of creating a derived class that filters the thing and resets it when the robot is sitting still (as determined by the encoders).

Is your sidecar powered properly? Did you connect it to the pins closest to the NXT connector (check the manual)? Are you sure your cable is good (check for end to end continuity and for an shorts from one pin to another)? Are you sure your cable is in the correct orientation (it is easy to plug in backwards on either side)?

HTH

Trevor_Decker

14-02-2012, 01:21

wireties

14-02-2012, 01:43

Team 3504 had a similar problem we found that when the digital side card is connected to the C-rio by a DB37 Cable (http://www.andymark.com/product-p/am-0500.htm) we could not get a reading. However when we switched to the DB37 ribbon (http://www.andymark.com/product-p/am-0500.htm) we could get data from the accelerometer.

I believe that the DB37 ribbon was in the kit of parts this year.

I have seen that in so many posts that we tried both and both worked (and both were noisy). I wonder what makes the difference. Perhaps it depends on which molded cable one is using (though I'm confident we have never ordered one, all came from past KOPs).

Trevor_Decker

14-02-2012, 02:28

I have seen that in so many posts that we tried both and both worked (and both were noisy). I wonder what makes the difference. Perhaps it depends on which molded cable one is using (though I'm confident we have never ordered one, all came from past KOPs).

I think it might have to do with length of the cable. I2C is a serial signal so the extra latency may be casing problems. (this still doesn't make much sense to me).

How much noise are you getting, and is it evenly distributed on all three axis?

wireties

14-02-2012, 02:53

I think it might have to do with length of the cable. I2C is a serial signal so the extra latency may be casing problems. (this still doesn't make much sense to me).

How much noise are you getting, and is it evenly distributed on all three axis?

Our molded cable and ribbon cable are the same length so perhaps it is the length causing issues. Minimizing the length from the sidecar to the sensor becomes important I reckon.

The noise is everywhere. Some of it is just LSB noise, some of it is 'real' vibration and some may be power/ground related. We need to hard mount ours so the vibrations are beyond the bandwidth of the sensor. Hopefully this (and some filter caps) will help. I think we might filter the data to make it usable. The drift of the zero G setpoint is more troublesome. We plan on resetting the V and D sums when the wheel encoders say the robot is sitting still.

StephenNutt

14-02-2012, 12:58

Thank you everyone for all the suggestions.

The Digital break out board is powered - the LEDs are on. I will double check this though as it was not something that we verified.

We have tried with both the round and flat DB27 cables. Admittedly our flat ribbon cable has been damaged and then repaired as much as possible. I've checked the pins and it appears to be working correctly, but it does not hurt to re-check the cable.

From memory our I2C cable is around 50cm long, but I've never measured it. Checking with http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus/frequently-asked-questions/i2c-faq.html In typical applications, the <maximum> length is a few meters (9-12ft).

Currently noise is not an issue - the read values are all zero.

I'll follow up tomorrow evening after the meeting, until then please continue making other suggestions of things to check.

Again, thank you all for the help

Steve

StephenNutt

15-02-2012, 20:13

I borrowed a Total Phase Beagle I2C analyser from work and have some additional info.

When successfully reading the I2C bus from an Arduino the clock speed is 100kHz. When unsuccessfully using the cRIO the clock speed is 38.4kHz (the Beagle reports the clock as every 26us)

The accelerometer is not acknowledging with an ack - the SDA line is not going low after after the final bit is sent from the cRIO.

Does any team have an oscilloscope and can measure the clock speed for me. Our oscilloscope is giving us a clock speed of closer to 43kHz.

Additionally, we are currently using the old 8 slot cRIO. Has anyone managed to get the accelerometer going with last years cRIO rather than the new 4 slot cRIO?

Again, many thanks to all for any help

Steve

Alan Anderson

16-02-2012, 08:13

Additionally, we are currently using the old 8 slot cRIO. Has anyone managed to get the accelerometer going with last years cRIO rather than the new 4 slot cRIO?

Our programming testbed is an 8-slot cRIO. After we replaced the thick white 37-pin cable with the ribbon cable from the Kit of Parts, the accelerometer works fine with I2C.

You might have one of the boards that responds to the alternate address of 0xAC instead of the default 0x3A. Try changing that in the example code and see if it starts responding.

StephenNutt

16-02-2012, 15:12

Our programming testbed is an 8-slot cRIO. After we replaced the thick white 37-pin cable with the ribbon cable from the Kit of Parts, the accelerometer works fine with I2C.

You might have one of the boards that responds to the alternate address of 0xAC instead of the default 0x3A. Try changing that in the example code and see if it starts responding.

Thank you for verifying the accelerometer works on the 8-slot cRIO. We've successfully used the accelerometer at address 0x3A with an Arduino so that does not appear to be our issue.

wireties

16-02-2012, 15:27

Thank you for verifying the accelerometer works on the 8-slot cRIO. We've successfully used the accelerometer at address 0x3A with an Arduino so that does not appear to be our issue.

Ours is also an 8-slot setup.

How long is your cable? I mean total length from cRIO to sidecar plus from sidecar to accelerometer. Our cable to the accelerometer is quite short, maybe that is the difference? I know I2C is designed to work over very short distances, it is more often used on the same circuit board or across a backplane. There are dedicated I2C drivers that work well over a couple meter long cable but more often the driver is really just some sort of logic port on a FPGA or a I2C peripheral and not as strong as the I2C spec recommends.

HTH

StephenNutt

16-02-2012, 16:25

Ours is also an 8-slot setup.

How long is your cable? I mean total length from cRIO to sidecar plus from sidecar to accelerometer. Our cable to the accelerometer is quite short, maybe that is the difference? I know I2C is designed to work over very short distances, it is more often used on the same circuit board or across a backplane. There are dedicated I2C drivers that work well over a couple meter long cable but more often the driver is really just some sort of logic port on a FPGA or a I2C peripheral and not as strong as the I2C spec recommends.

HTH

I'll measure it tonight, and create a short cable to check. Thanks for the help.

jhersh

16-02-2012, 17:26

I borrowed a Total Phase Beagle I2C analyser from work and have some additional info.

When successfully reading the I2C bus from an Arduino the clock speed is 100kHz. When unsuccessfully using the cRIO the clock speed is 38.4kHz (the Beagle reports the clock as every 26us)

That is the expected clock rate for I2C on the digital side car... 6.5us access period * 4 cycles to make the waveform.

The accelerometer is not acknowledging with an ack - the SDA line is not going low after after the final bit is sent from the cRIO.

This basically means that no device believes that it is being addressed. Possibly signal integrity, though at that speed I'd be surprised. Are you using the scope to watch the signals at the sensor or at the DSC?

-Joe

StephenNutt

16-02-2012, 22:25

wireties

16-02-2012, 23:42

So we found the issue - the I2C cable. No idea what is bad about it, it is approx 20" long, well within the I2C specifications. We tried a cable a hair under 12" and that works.

Many thanks to all for your suggestions.

Steve

Great to know Steve, thanks for updating the thread with the solution. We'll be careful to keep the cable under 12". Good luck at your competitions!

jahuber

25-02-2012, 18:38

Team 3184 can verify that the cable length matters. We had 24 inch cables, shortened them to about 10 inches, and we now get values from the ADXL345.

DavisC

26-02-2012, 10:52

Does the 12" standard include the length of the DB37 cable, or just the length from Accelerometer to DSC?

Thanks,
Davis

wireties

26-02-2012, 11:39

Does the 12" standard include the length of the DB37 cable, or just the length from Accelerometer to DSC?

Thanks,
Davis

We are talking about the length of the cable from the sidecar because the ribbon cables and molded DB37 cables all seem to be the same length. BUT it is the total length that matters so making a really long ribbon cable would kill you (it seems from current data) as well.

YWS

03-03-2012, 13:45

Dear All,

I believe we have determined what the root-cause is with I2C interfacing to the accelerometer is. The issue is that the FPGA implementation of the I2C interface within cRIO contains a timing error. The error is that the data hold time is approx -90 ns, whereas a typical hold time is either zero or some small value. The ADXL345 requires min hold time to be in the range from 0 to +900 ns. The negative hold time is the most likely reason for the ADXL345 NACK-ing the I2C bus transaction request, which causes the errors reported in previous posts.

The fact that some users got the system to operate with I2C may be related to temperature/voltage variations effecting the ADXL345 IC behavior with marginal timing, as no 2 pieces of silicon are equal.

The I2C bit rate being used by the cRIO system is about 35 KHz. The specific bit rate has nothing to do with the failures reported as the failures appears to be data hold related. The fact that it works with Arduino is just that Arduino most likely produces proper I2C timing, which also happens to be at ~100 KHz.

Our Boardshop I2C adapter also works well with ADXL345 board as well.

We have switched to the SPI interface now. The problem is that while we are able to toggle all the SPI output lines without using the "SPI" protocol" when the SPI protocol is used (via the FPGA) the lines do not change their states. MOSI, SCLK, CS do not "wiggle".

Would anyone have any suggestions in making the SPI work with Labview?

Thanks.

Team 3624 mentor.

Vijay

07-03-2012, 01:57

Hi,

I had read all the posts regarding this topic. My problem is somewhat related to it only.

But I can transfer and gain data from the Accelerometer through i2c controller.

I can read the axis values as well. But my problem was I can read the same axis value even though I changed the position of the accelerometer. When I once switch off and on the board the value of the axis was changed, but the value remains same until switch off and on the board again.

I hope you can understand my problem and provide a nice solution. I face this problem more than a month, so, I expect the solution as soon as possible as you can.

Vijay