ADXL345 accelerometer problems

We are having trouble getting our accelerometer to work. I have it hooked up to the digital sidecar with I2C, and am getting no reading from it.
We are using the 8 slot crio with java. Everything has been updated to the latest.

Any ideas?

We need more info
How is it wired? What is it wired to? How are you programming it (what is the code)?

It is wired using the 4 i2c pins of the accelerometer to the 4 i2c pins on the digital sidecar.
Here is our code:


package edu.wpi.first.wpilibj.templates;


import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.*;
import edu.wpi.first.wpilibj.ADXL345_I2C.AllAxes;

public class RobotTemplate extends IterativeRobot {
    ADXL345_I2C accelerometer;
    
    public void robotInit() {
        accelerometer = new ADXL345_I2C(1, ADXL345_I2C.DataFormat_Range.k4G);
    }
    public void autonomousPeriodic() {
        ;;
    }
    public void teleopPeriodic() {
        AllAxes ac = accelerometer.getAccelerations();
        System.out.println("X: "+ac.XAxis+" Y: "+ac.YAxis+" Z: "+ac.ZAxis);
    }
    
}

And all of the wires are straight through? (VCC to VCC, SCL to SCL, SDA to SDA, GND to GND)

And can you get a voltage on SDA and SCL? They should be around 5 volts.

If possible, an oscilloscope would be useful in determining whether or not the I2C bus is working. You should hook up a probe to the SDA line, and confirm that the bits are changing.

Yes, they are.

Just checking… :wink: And the voltage?

Not sure about the voltage.
I will check it tomorrow.

There is about 4.6 volts on the sda and scl.
I am getting a square wave on the scope, but not really sure what I am looking for.

Got it working!
Used the flat db37 cable included in this years Kop, instead of the old round one.

Interesting. We are having the same problem. We tried replacing the old round cable with the flat one and nothing worked. I’m certain that the flat cable is either bad or just needs to be re-built (currently working on that one). However, I’m curious why the flat cable would work in your situation as opposed to the round cable.

We have hooked our accelerometer up to an o-scope and all seems fine.

Does anyone else have any other suggestions?

Did you flip around the connector as described on the KoP website?

That’s what we just did and sure enough it worked. Makes sense as when we Ohm’ed it out, pin 1 went to pin 15 on the other end. I didn’t think to check the KoP website, but I’m definitely going to check it out. It still seems like a curious situation that the flat works for the accelerometer but the round doesn’t. :-/ Oh well, I’ll take it at face value for now.

Thanks for the follow up!

Hello all,
We are having the same problem. We are using Java, and I can see traffic on the i2c bus with a scope, but no way to decode it. Signal integrity looks ok, clocking as expected and I can see packets, but no analyzer to decode the traffic.

Symptom is no values returned. We don’t have labview and so far I am unable to find the wiring diagram or any diagnostic. Based on this thread I also tried both flat and round cables between cRio and side car.

I used the code in one of the threads and it is simple enough that shouldn’t be the issue.

If anyone has it working can you post a photo of the sidecar wiring?

Also, do we have to provide our own pullup resistor on CS? The datasheet says one is required for i2c, but it an external one does not seem to help the situation. Could be two problems though.

Thanks in advance!

Bob

Hello all,
(Apologies if replying to myself is bad form, just wanted to let this thread know the problem was solved.)

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

It’s definitely good to follow up with the resolution. That way others who find this thread when searching for information on a similar problem can see how it was fixed.

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.

We’ve been using an official round cable on our programming testbed for months. It wasn’t until a week ago that we tried the I2C connection to an ADXL345, and it took a couple of hours of failure before I remembered some people describing making it work with a ribbon cable instead. So I repaired the KOP cable (chipped of a little plastic by accident in the process), swapped it in, and had instant success.

Has anyone managed to use I2C with the original white 37-pin cable?

Which round cable didn’t work? In 2009 and 2010, it was a cablestogo pn 02688. Last year it was SF Cable pn D720-03.

We have been using the round cable for testing with an ADXL345 from last year and it worked fine. Several new sensor boards did not work and I suspected that the students had connected them wrong and smoked them. As crunch time comes, I was not comfortable that we had only the old board and no new ones working. We ordered three new boards and they didn;t work either. The old board worked in two robots with the round cable. After reading this thread, we tried the flat ribbon and as was predicted here, all 6 boards work.
Anybody know why the older board works with the old cable?

Rob Coe
Mentor to Team 28

The cable I was using has no identifying marks on it that I can see. Based on the box I pulled it from it is likely one from 2010, though I can’t be sure. We didn’t label the ones we got in the Kit of Parts with the year we received them.

We are getting “real” data from the accelerometer using the molded 37-pin cable. But it is very noisy - maybe we should try a ribbon cable. It does not make obvious sense why it should matter, they are of similar length. But we will try it.

It looks like most of the common causes for this problem have been described very well, but I thought I would add one more possibility for anyone searching this thread. Our team had no connectivity to the accelerometer at first with any cable combination. It turned out that the accelerometer was responding to the alternative address even though no jumper had been added to the board. I tested the jumper with an ohm meter and did not find a short, but the device clearly acted as if it had been programmed with a jumper. If anyone else has trouble with no communications at all over I2C, try both addresses before giving up, even if there is no solder jumper on the board.