View Full Version : ADXL345 I2C Accelerometer NOT WORKING
ive been having some trouble coding for the accelerometer and i am very confused as to how i can use the i2c bus to actually read from the accelerometer
it would be very helpful if i could get some some sample code or a basic outline of what i need to do
ive been having some trouble coding for the accelerometer and i am very confused as to how i can use the i2c bus to actually read from the accelerometer
it would be very helpful if i could get some some sample code or a basic outline of what i need to do
There is a class for the sensor that only has a few functions and they are documented. What exactly are you having trouble with? You can look at the LabVIEW example for the ADXL345 to see a wiring diagram.
-Joe
brian3795
09-02-2011, 15:00
There is a class for the sensor that only has a few functions and they are documented. What exactly are you having trouble with? You can look at the LabVIEW example for the ADXL345 to see a wiring diagram.
-Joe
Either we have a borked ADXL345, or the LabVIEW code isn't working. The example code just returns a "sensor not responding" error code. It's wired correctly, with the "correct" address of 0x3A.
Either we have a borked ADXL345, or the LabVIEW code isn't working. The example code just returns a "sensor not responding" error code. It's wired correctly, with the "correct" address of 0x3A.
Do you have any equipment (oscilloscope or logic analyzer) you can debug this with? Can you look at the I2C bus to determine if the traffic looks good or not?
-Joe
brian3795
09-02-2011, 15:18
Do you have any equipment (oscilloscope or logic analyzer) you can debug this with? Can you look at the I2C bus to determine if the traffic looks good or not?
We have access to a scope...have any references for us as to what "good traffic" will look like?
We have access to a scope...have any references for us as to what "good traffic" will look like?
Just look at the data sheet for the ADXL345... it should have some waveforms in it.
brian3795
09-02-2011, 16:42
Yep, see them...will give the scope a try and see what's up.
brian3795
12-02-2011, 17:20
Well, we ended up getting it to work in SPI mode (we did have to shorten the loop time from 100ms to 10ms). So we'll just live with that unless we run out of DIO ports. Thanks!
I have been trying to hook up my accelerometer and have had similar problems. I am writing in Java and have tried using the ADXL345_I2C class to interface with the accelerometer, but to no end. Every time I try to get the acceleration all I get back is 0, no matter how much I shake it.
I have also tried using I2C directly and still got nothing.
I would like to try SPI, but I don't know how I would get the data back in the code, the DigitalInput class only returns boolean values, not doubles.
If someone could tell me how to use SPI in Java or what I'm doing wrong with the I2C I would really appreciate it!!! Thanks.
I have been trying to hook up my accelerometer and have had similar problems. I am writing in Java and have tried using the ADXL345_I2C class to interface with the accelerometer, but to no end. Every time I try to get the acceleration all I get back is 0, no matter how much I shake it.
I have also tried using I2C directly and still got nothing.
I would like to try SPI, but I don't know how I would get the data back in the code, the DigitalInput class only returns boolean values, not doubles.
If someone could tell me how to use SPI in Java or what I'm doing wrong with the I2C I would really appreciate it!!! Thanks.
There is not currently an easy-to-use API in java for accessing SPI so I recommend against that (unless you are savvy C++ to Java porters and would like to contribute an implementation). I2C should work (works on the sensor I have) but check for errors on the console.
Joe
(Bump on an old thread and hope someone sees it!)
Hello all,
I am having the same problem. We are using Java. Can someone post the wiring diagram from LabView or a screenshot of it? I can not find one though I looked. I did put a scope on the clock and data and they show traffic, but I don't have a protocol analyzer to tell if the traffic is correct.
Also can anyone who has it working confirm if we need to put out own pullup resistor on the CS pin to get into i2c mode? It doesn't look like it, but it could just be the cRIO telling the senor to wake up over and over again.
The code seems so simple I can't imagine it is the code, but if anyone knows any non-obvious points, that would also be appreciated.
Thank you in advance!
Bob
PS My first CD post!
We have it working. We did nothing but solder the pins to the board and wire the 4wires to the digital sidecar. The LabVIEW example shows how.
Joe
We are having the same issue.
Tried multiple DB-37 cables - round, ribbon, several different connectors, etc.
Tried multiple 4-pin I2C cables.
Tried 2 different ADXL345 board.
Tried both a 4-slot and 8-slot cRIO.
Checked that the pull-up resistors in the DSC are working - we see about 3k between 5V and SDA, 5V and SCL.
SDA and SCL see about 4.6V.
We don't have a scope to check waveforms unfortunately.
We are programming in Java, and all we get back are 0.0 for all three axes.
There are no errors thrown.
I would love to get this working, but we opted to use a 2nd analog gyro turned sideways instead.
Hello all,
I am beginning to wonder if the issue is the specific combination we are using. Does anyone out there have it running with this combination:
* Java
* 8 slot cRIO
So far I have seen LabView and 4 slot examples running, but nothing confirmed with Java and 8 Slot. I wonder if there is a bug somewhere in the library support?
Does anyone have _any_ i2c devices working with that combination?
Thanks again!
Bob
We ARE using LabVIEW and tried both SPI and I2C examples, having updated the example from Sourceforge as mentioned in another thread. We rang out several round cables (checked good), but don't have a flat cable (it was damaged during repair). (I can't see why that should make a difference). We don't have a scope available.
There seem to be teams for which it works, and teams for which it doesn't. Again, we ARE using LabVIEW and are fully updated. The example gets into the Read VI and appears to stay there waiting for a response. I have no way of knowing whether the accelerometer didn't receive the previous write or it just isn't sending a value to be read.
Can ANYONE help??? National Instruments???
If you are stuck in read, that usually means that one of the I2C lines are stuck low. Make sure there are no shorts on your sensor.
Joe
I've experienced quite a variety of issues, but let me share what I have done to get it finally working to some degree. This is using the Labview example with I2C interface only.
1) Make sure the cable you use to connect from the CRIO to Digital Side Car is correctly pinned and in proper working order.
a) We found our round molded ones from previous years to be faulty as others have described here.
b) We tried the ribbon cable from last season (from Andymark irrc) which also did not work for us.
c) We repaired this years ribbon cable, which does work.
2) Make sure your connections to the accelerometer as well as to the digital side car are clean and good. It appears from my testing the I2C is very very sensitive to poorly made cables and it will have a large impact on it's ability to communicate.
3) When using the example I2C, I found I had better success when I ran the driver station application on the same laptop as the example. I noticed in the example code an open/close for the driver station so I started running it.
4) Even with all of the above, sometimes it works, sometimes it fails to respond, sometimes it works for a while, then fails. All the failures are a failure to respond.
We tried more than one.
Another way this can happen is if the sensor is not powered. Are all the power supply LEDs lit on the digital sidecar?
Hello all,
I found it - it was multiple faulty cables to the sidecar. The only one that works is a new flat cable from this year that I repaired according to the instructions on the KoP site. It looks like I probably had two problems at the beginning and after I fixed the other one, had the faulty cable issue. Once I got it running, it has been stable.
I will post some photos is anyone is interested in seeing some documentation of an end to end system including some scope shots of traffic.
I guess the "bad" cables must be good enough for the low order PWMs and other channels we were using to fool me.
So the moral of the story, even if you are sure your round cable is good, ONLY use a new flat cable without a twist until you get it working. Then switch other items one at a time so if it stops working you know what it was that went wrong.
Thanks to all who replied!
Bob
Glad you got it working. I'm surprised at the problems people are having with this. It has always worked great for me... But I guess that's how it goes.
"That's how it goes" is not what I expect to hear from NI. We only have one ribbon cable and we can't get our accelerometer to work with it. Why doesn't the round cable work? We checked it for continuity & shorts. Or perhaps the problem is really not the cable? Does anyone know where we can buy a cable that WILL work reliably?
The only "bad cables" I've heard reasonable explanations for are the round cables that Joe Ross reported do not have all of the pins connected. As for the other reports, I have no idea how much of that is speculation or other variables that are not being accurately conveyed here. The I2C signals only operate around 150kHz on the digital side car, so I don't expect any there is any cable quality problem that would cause issues, short of "the pins aren't connected at all". I suspect there are other problems like poor soldering, very long cables between the DSC and the sensor, damaged sensors due to hooking up power and ground backward and some point in the past, etc.
-Joe
agartner01
07-02-2012, 21:09
Could someone take a look at this thread:http://www.chiefdelphi.com/forums/showthread.php?t=101921 same problems in c++.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.