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.
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)?
Team 3504 had a similar problem we found that when the digital side card is connected to the C-rio by a DB37 Cable we could not get a reading. However when we switched to the DB37 ribbon 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).
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.
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.
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?
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.
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.
That is the expected clock rate for I2C on the digital side car… 6.5us access period * 4 cycles to make the waveform.
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?
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.
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.