Dexter dIMU Support

[Martin Zenkel]

Hi,

building up some balancing vehicle I’m trying to implement the Dexter dIMU I²C-sensor, especially the accelerometer
http://dexterindustries.com/manual/imu-sensor/
http://dexterindustries.com/files/dIMU_Datasheets.zip

I’m deriving from I2CSensor which seems to be very straightforward. The problem is that every Read../Write.. call attempt hangs (e.g. setting the mode or reading a value from the appropriate hex register address). The same applies to the gyro on the same device (of course with the correct I²C- and register-addresses). After reading some lines about the I²C bus I wonder if it might be the case, that MonoBrick Firmware doesn’t support some special I²C detail (maybe another mode) yet?

The same device (both the accelerometer and the gyro) delivers measurement values with the standard EV3 software, using the blocks from
https://github.com/DexterInd/EV3_Dexter_Industries_Sensors/raw/master/Dexter.ev3b

Unzipping this file and analyzing the *.vix-files in it gives me no hint (apart from a I²C-address shift, which I tried too).

Do you have any idea? Thank you in advance.

Best regards,
Martin

BTW: MonoBrick Firmware is a really great project!

[Anders Søborg]

Hi

Try to use this as a starting point. My guess is that you did not call the initialize on the base class in your constructor. Post some code if this does not work. Also when you are done make a pull request on github – then you can help expand the number of sensors that are supported by MonoBrick firmware…

Anders

[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.)

[Anders Søborg]

Hi Again

You might get some helpful info here – but you will have to do some reverse engineering 🙂

I have to go to bed now, but please let me know how it goes…

Anders

[Martin Zenkel]

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

[Anders Søborg]

Please let me know how it goes. I would really like to support more sensors

Anders

[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

[Anders Søborg]

Hi

Please remember to let us all know how this goes…

Anders

[Author]

Posts