Trouble with the AXDL345_I2C accelerometer.

[LukeS]

I apologize in advance for creating another accelerometer thread, but none of the others were able to help me, and I didn't want to hijack l0stboy's, in case we're having different problems.

My problem is the one most people are having: I always read 0.0 on all axis.

I have the module connected to the I2C port on the sidecar, yes I2C closest to the NXT connector, not the digital outs next to it.

We are using the new flat ribbon cable to talk to the DSC. One of the connectors was flipped, but we fixed it, per the instructions on the KoP site. It has been verified working by using two PWM servos, and two digital encoders.

I have verified that the pins are connected one-to-one from the accelerometer to the sidecar. I have tested the cable using an ohm-meter, and have while it is connected measured 5.1V on the "5V" pin, and 4.7V on the "SDA" and "SCL". I do not have easy access to an oscilloscope, but can get one if truly necessary.

Looking at the spec sheet for the ADXL345, and the WPILibJ source code, we noticed that the read bit is not set during I2C.read(), so I tried replacing

registerAddressArray[0] = (byte) registerAddress;

with

registerAddressArray[0] = (byte) (registerAddress | 0x01);

To clarify, why I did this is because the spec sheet (from Analog Devices) says

the 7-bit I2C address for the device is 0x1D, followed by the R/W bit. This translates to 0x3A for a write and 0x3B for a read.

However, this did not fix the problem either.

We have also tried replacing the accelerometer, but it didn't work either.

Here is the code I am running to test the accelerometer:

package edu.wpi.first.wpilibj.templates;

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

public class RobotTemplate extends IterativeRobot {

	ADXL345_I2C accel;

	public void robotInit() {
		accel = new ADXL345_I2C(1, ADXL345_I2C.DataFormat_Range.k2G);
	}

	public void teleopPeriodic() {
		ADXL345_I2C.AllAxes vals = accel.getAccelerations();
		System.out.println(
				" X: " + vals.XAxis+
				" Y: " + vals.YAxis+
				" Z: " + vals.ZAxis);
	}
}

Any help is greatly appreciated.

[sand500]

we had this same problem, when we switched to the flat cable, it worked for a while, but it doesnt work now.

[wireties]

Ours is working (albeit very noisy) with the default code so the library does not need changing.

- do you have your sidecar power connected?
- did you average some readings and save a zero G offset (not your problem yet)
- are you sure the accelerometer is not plugged in backwards?

I'm not a java expert but should accel be a pointer if you are going to instantiate the class with 'new'?

HTH

[LukeS]

Originally Posted by wireties

Ours is working (albeit very noisy) with the default code so the library does not need changing.

Thank you, that is good to know. Now, I am curious though, how it works at all if I'm reading the spec sheet correctly.

Originally Posted by wireties

- do you have your sidecar power connected?

Yes, as verified by it running several servos (as mentioned), and on all the power LEDs. However, it was pointed out to me shortly before I left today that it had 24V going in to it (it should have 12V), so that may be the issue. My mind is blown that it was properly running the servos at the correct voltage with twice the voltage running in to it.

Originally Posted by wireties

- are you sure the accelerometer is not plugged in backwards?

Yes, we must have checked that 100 times today.

Originally Posted by wireties

I'm not a java expert but should accel be a pointer if you are going to instantiate the class with 'new'?

In Java anything that's not a primitive (various sized ints, 32&64 bit floats, boolean and char) is automatically a pointer (or "reference" in Java-speak).

[wireties]

Originally Posted by LukeS

Thank you, that is good to know. Now, I am curious though, how it works at all if I'm reading the spec sheet correctly.

In other systems where I have used I2C, the read/write increment for the address is automagically added/removed by the I2C transceiver - perhaps that is the case here? The I2C clock and data lines originate on the 9403/FPGA so I can't tell looking at the sidecar schematic.

Originally Posted by LukeS

Yes, as verified by it running several servos (as mentioned), and on all the power LEDs. However, it was pointed out to me shortly before I left today that it had 24V going in to it (it should have 12V), so that may be the issue. My mind is blown that it was properly running the servos at the correct voltage with twice the voltage running in to it.

They all are 5V beasts (6V for servos) I think but it is surprising the 24V did not heat up the regulators a bit.

Good luck!