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).
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.
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?
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.