Mindboards

gloomyandy wrote: PS Are you having fun yet...

As long as this thread is not dead I'm having fun. It wasn't what I expected, but I don't mind solving serious problems. You can't imagine how much I am learning from this, I2C, electronics, breadboarding and patience to name a few.

The blinkM had the same 47k pull ups. From the readings I concluded the the IMU and the blinkM pulled the lines low part of the time and that this was the reason for a low voltage reading. But I could be wrong.

I'll try Matts theory with Andy's setup tomorrow. But I read in the data sheet that the limit for Vlo is 0.1*Vdd for the gyro and 0.25*VDD for the accelerometer. For Vhi the limits are 0.9*VDD and 0.75*VDD respectively.

gloomyandy wrote:So you are suggesting that the problem is that the IMU is failing to recognize a logic 0 from the NXT? What makes you think the VIL for those chips is as low as 0.1V. A more normal value would be 0.8v (as used by the AT91 in the NXT)...

Yes, that is what I am suggesting. I got the number 0.1v from the datasheet, so it should be correct. I agree, it should be much higher than 0.1v, however, it looks like it isn't.

aswin0 wrote:...The blinkM had the same 47k pull ups. From the readings I concluded the the IMU and the blinkM pulled the lines low part of the time and that this was the reason for a low voltage reading. But I could be wrong.

If they were pulling the lines low, and that is why you got the 0.97v reading, then there is a BIG problem with the devices. When the blinkM or IMU pull the line low, it should be LOW (even 0.05v is probably too high), as there are no "protection" resistors (as the NXT has) to act as a voltage divider.

aswin0 wrote:I'll try Matts theory with Andy's setup tomorrow. But I read in the data sheet that the limit for Vlo is 0.1*Vdd for the gyro and 0.25*VDD for the accelerometer. For Vhi the limits are 0.9*VDD and 0.75*VDD respectively.

Assuming you mean VIH, not VHI (not sure what that means), the 0.97 volts high (pulled up by the 47k, without being connected to the NXT) SHOULD be okay as a high, even though it is really close to the minimum (of 0.9v for the gyro).

Well from the i2c sections of the data sheets. For the ITG-3200 we have Which given a 3.3V supply is 0.99V and 2.31V

and for the ADXL345 we have: Which gives 0.825 and 2.475

I'm still rather concerned about the voltages when nothing is connected. Really the bus should be floating at that point

gloomyandy wrote:So you are suggesting that the problem is that the IMU is failing to recognize a logic 0 from the NXT? What makes you think the VIL for those chips is as low as 0.1V. A more normal value would be 0.8v (as used by the AT91 in the NXT).

Aswin an easy way to test this theory is to set things up with your bus pirate with a 47K pullup and place a 4.7K resistor in line with the output of the bus pirate (in effect making the bus pirate have the same interface as the NXT). If the bus pirate can still talk to the IMU then the NXT should be able to as well... So the connections would be bus pirate -> 4.7K -> IMU + 47K pullup.

I tested the theory with this setup. The bus pirate was not able to interface with the IMU!
So it seems that Math is right. The inline resistors do prevent the IMU from recognizing a LOW on the clock and data lines.

Well. This leaves me two options, quiting is not one of them.
The first option is to disable the inline resistors on the NXT. Then I end up with a sensor that can only be used on one port only on this particular NXT. I also risking to ruin my NXT.
The second option is to get my level shifter to work. I'll have to understand how it works with I2C, I have to remove the pullups from the high side and replace them with 82K ones (I have to recognize the pullups on this board first) . I have to hope that I can get this complex schematic to work.
I don't know yet.

These are the results of connecting the IMU via a level shifter.
It took me some time to understand the level shifter from Sparkfun. In the end it proved to be very, very simple. Once I understood it I removed the pull ups from the high voltage (HV) side, plugged it into my breadboard, installed some 82K pullups on the HV side and wired my sensor to the LV side of the level shifter.

The first tests with the bus pirate were very promising, everything worked fine. I then replaced the bus pirate for the NXT and a got the same results as ever. The sensor and the NXT could not communicate. Just to double check I swapped the IMU for the blinkM and everything worked fine again. From this I conclude that the pullups cannot be the (only) problem.

Have I reached the end of the line? Am I running out of options? Probably. I'm starting to think that the IMU uses timing characteristics that the NXT cannot handle. Some problems with the bus pirate in sniff mode seem to point in that direction. The new version of the firmware cannot sniff the lines anymore, it only sees NACKs and ACKs. According to the developer of the bus pirate this happens only at high I2C speeds, but I'm using the lowest speed available for tests with the bus pirate (5K).

Does anyone here have the timing specifications of the NXT I2C implementation? I want to compare these with the specs I find in the datasheet of the IMU sensors.

I think standard FW uses about 9k6. RobotC (and maybe other FW's) have the ability to run faster.

Can you make sure that the data lines are now going low enough? Before, you confirmed my suspicion about the "protection" resistors. Can you try adding the resistors (4k7) in series again with the bus pirate, but this time use the level shifter? Does it work?

You are right, I still have to rule that out. I'll do so tomorrow.
But I'm still considered about the I2C protocol. The sensor uses fast mode and the NXT standard mode. I don't know wether there are timing differences between the two. except from the speed obvious.

Other than speed related differences, they are the same. Any hardware I2C device (not bit banged), should be able to go at almost any speed, as I don't think there are timeouts, and it doesn't need a processor to keep up with super high speeds. If the I2C interface in the IMU is hardware, speed is most likely not the issue. If it is software based, then it may have a timeout, which could be causing the problems. When you successfully communicate using the bus pirate, what speed do you use?

If worst comes to worst, you could try a "permanent" mediator processor, but you would certainly lack speed (and you probably need all the speed you can get).