[Martin Zenkel]

Hi Anders,

sorry for the late response.

After comparing both I2CSensor implementations (down to some IO-related UnixDevice class) I could not resolve my Dexter dIMU I²C communication issue.

To proceed with my main objective I’m using the HiTechnic tilt sensor now which is already implemented in MonoBrick Firmware. It is an I2CSensor too but/and it works fine. I’m doing some research concerning timing, threading and so on in order to get a responsive/reproducable balancing loop solution. Further more I’m working on various details, e.g. wondering if (and hoping that) there will never be a time-consuming garbage collector or background system task that breaks my balancer activity.

I think I’ll come back to the dIMU later, keeping you up-to-date of course.

Best regards, Martin

[Martin Zenkel]

Thank you, I’ll take a look at it.
Martin

[Martin Zenkel]

Hi, thank you for the very quick response.

To answer your hints and proposals:

I already cloned the github monoev3 repository to check the code of the handful of I²C-sensor implementations that ship with MonoBrick firmware and I already did call Initialise() on the base class in the constructor. This is the code (excl. ReadAsString):

public class DexterAccelerometer : I2CSensor
{
	public DexterAccelerometer(SensorPort port) : 
		base(port, 0x3A, I2CMode.LowSpeed) //0x3A: Dexter-dIMU-documentation, 0x1D: Freescale-datasheet
	{
		Initialise();

		byte mode = 0x01 << 3 + 0x01; //4g measurement
		WriteRegister(0x16, mode);    //THIS CALL DOES NOT RETURN
	}
}

In my previous post the I²C details of MonoBrick Firmware and the I2CSensor class came into my mind because I took a look at the Tutorial Segway with RobotC. There the Dexter dIMU gets initialized with a I²C mode constant named sensorI2CCustomFastSkipStates, whatever that means. This mode is one of six according to the RobotC driver suite common file (line 218ff). So compared to RobotC I guess that MonoBrick Firmware implements ‘only’ the sensorI2CCustom and sensorI2CCustom9V mode (equivalent to I2CMode.LowSpeed and I2CMode.LowSpeed9V) – just a guess.

Secondly, what strengthens my suspicion: In the Dexter’s ev3b block description (unzipped, in Accel4.vix) they write decimal ...DataType="Byte[]">[29,22,9]... for the “Accelerometer Initialization 4G” (as the comment below states). It seams that they send only three bytes, containing hex [1D,16,9] which means [I²C address, register address, value]. Looking into MonoBrick Firmware’s I2CSensor.WriteAndRead implementation it seams that some overhead is built around this essential 3-byte information. Might this be an incompatibility? Sorry, but maybe I’m completely wrong. 😉

(Apart from that, my confusion with the “I²C address shifting”-topic is resolved in so far, as I have meanwhile seen I2CAddress >> 1 in your I2CSensor.WriteAndRead implementation. So I use the “left shifted” one, as shown and commented in the snipped above.)

[Author]

Posts