![]() |
Re: Unable to read accelerometer
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 |
Re: Unable to read accelerometer
Quote:
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! |
Re: Unable to read accelerometer
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.
|
Re: Unable to read accelerometer
Does the 12" standard include the length of the DB37 cable, or just the length from Accelerometer to DSC?
Thanks, Davis |
Re: Unable to read accelerometer
Quote:
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. |
Re: Unable to read accelerometer
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. |
Re: Unable to read accelerometer
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 |
| All times are GMT -5. The time now is 20:15. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi