Problem with reading I2C

[skoehler]

Hmm. Consider Example 2 on page 9 (only i2c address byte is being sent, 2 byte data is returned) or this quote from the bottom of page 8 + top of page 9:

Q: How to Read Data from HMC6352?
A: In Standby Mode - Use “A” command.
In Query Mode - Send 43(hex) slave address to read data and clock out the two register data bytes for heading.
An initial “A” command is needed to update the heading after each read.
In Continuous Mode - Send 43(hex) slave address to read data and clock out the register data bytes for heading.
The “A” command is not allowed or required.

My interpretation is (why is the language is datasheets always that awkward?) that you need to perform a 2 byte read immediately after sending the I2C address byte. You are not allowed to read 3,4 or more bytes in one go. Just two of them. I think that the posted code is actually correct.

I believe that advantage of continuous mode is less I2C overhead. (you don't need to initiate measuring with a separate I2C command).

Well, since a I2C read with zero-length data is certainly a special case. Maybe the leJOS I2C implementation doesn't handle it as it should? (even though I trust Andy that he tested it pretty much)

[matejdro]

So are you sending any configuration commands to the device (to put it into continuous mode)? If so can you post both your code and the robotc version... You may also want to try using high speed mode, as this will also enable pulse stretching for the device, it may be that it is not always ready to send the data when we ask for it.

Oh and can you provide a sample of the actual values read from the device and the associated return value from i2c_transaction. I'd like to see that data pattern as the value switches from just below 127 to just above (or in your case I assume to 0). When the first byte changes from 127 to 0 does anything happen to the other byte?

Oh and is this a home built sensor? If so what pull up resistors are you using with it? What port are you trying this on? Can you try it on port 1 and on port 4 and report any differences... Oh and what version of leJOS are you running, if you are not using the very latest build can you try it again with that. I assume your code is running on the NXT and not via the PC side interface?

Andy

No commands, continuous mode is set only once and then stored into sensor's EEPROM. I'm using "slow mode" because I thought it's most compatible and because RobotC works with it without problems.

I will try to create some samples tomorrow. First byte does not change when second byte goes to 0 again. What do you mean by data pattern? Sensor will simply report value around 127 and when you turn it little, it will jump to 0. It works perfectly, but goes 0-127 twice instead of 0-256.

It is bought sensor. I have tried on ports 3 and 4 with no difference. I'm using 0.9.1beta. What do you mean by PC side interface? I just pressed Ctrl + F11 in eclipse and program started running.

[skoehler]

Are you uploading/executing the Java program on the brick? It doesn't sound like you do. It sounds like the Java program is running on the PC remote controlling the NXT via USB or Bluetooth. Flash the leJOS firmware to the brick, and follow the tutorial on how to create a leJOS NXT project in Eclipse. leJOS NXT projects are for Java programs that run the brick itself. You're probably using a leJOS PC project.

[matejdro]

I have NXJ project. I think it uploads it because there is program file left even after program is finished.

[skoehler]

I have NXJ project. I think it uploads it because there is program file left even after program is finished.

Thanks for checking that.

[gloomyandy]

So does the other byte ever change? As you rotate the sensor at some point the second byte should change. What I would like to see is the set of values in both bytes as you rotate the sensor for say a full 360 degrees... As I said before please try the high sped mode and report back what happens.

[matejdro]

This it how it goes:

firstbyte secondbyte
0 0
0 127
0 0
0 127
1 0
1 127
... (and so on)

This it how it should be:

firstbyte secondbyte
0 0
0 127
0 256
1 0
1 127
... (and so on)

(I hope it's enough representative, I will give full dump tommorow).

[skoehler]

This it how it should be:

firstbyte secondbyte
0 0
0 127
0 256
1 0
1 127
... (and so on)

In Java, bytes are signed. So this is how it should be:

0 0
0 1
...
0 127
0 -128
0 -127
...
0 -1
1 0
...
1 -1
2 0
...

[gloomyandy]

Do the values really go from 0 0 to 0 127 directly or do they go through a series of increasing values like 0 1, 0 2 etc. (which is what I would expect)?


How are you connecting the module to the NXT? Have you added any pullup resistors? According to the datasheet the module does not contain any and the NXT requires that i2c sensors have the pull up resistors mounted. If you have added them what values did you use? If you have not added the pull ups you may just be getting lucky that the sensor works with robotc due to the different ways it and leJOS drive the port. It looks to me as if the top bit of a byte is always being read as a 0 and this may be caused by the lack of pullup resistors...

[matejdro]

Sorry for the delay, here are the values. Just for the record, I have also included values from RobotC:

LeJOS: http://pastebin.com/gGFVZg6W
RobotC: http://pastebin.com/WJvE7eMT

I rotated sensor for about 1 and half full circle and took reading every 50ms. Code for reading is included at bottom of the file.

As you can see, MSB goes 1-127 twice instead of 0-256 on leJOS, while it works without problems on RobotC.

As for pull-up, yes we use 47k resistors.

[gloomyandy]

Did you try the high speed mode?

Looks to me like some sort of timing issue with resulting in the first bit being read as 0, The pull up resistors you are using are perhaps also too low (Lego recommend 80K I think). If you get chance you may want to try this again with a higher value pull-up... Other than that this will be very tricky to fix without having access to the actual device...

Andy

[matejdro]

High speed does not help.

We were using 80K first, but then switched to 40K just in case, because it's closer to I2C specifications. And again, both values were working fine with Robotc.

Is there any way to dump some low level data, so you would have easier time figuring out what is wrong?

[gloomyandy]

If you can going back to 80K would be worth it. The Lego spec calls for 80K I think. Also what length of cable are you using? If you have a very short one you may want to try that... Other than that without being able to hook one of these up and look at what is happening on a scope or i2c analyser there is not much else we can do. If I get chance over Easter I will try and put together a test build of the firmware that adds some delays into the read routines, but if high speed made no difference then I suspect that will not help...

Oh and I just tried to take another look at the two pastbin items and can't seem to get to them, can you check to see if they are still available?
Andy

[matejdro]

Will try 80K.

Pastebins works fine for me. But here is copy: http://dl.dropbox.com/u/6999250/LER.zip (Btw, I have noticed that I copied wrong function from code in pastebin version. I added proper one here).

[gloomyandy]

Hi,
I've had a quick look at the code and can only really see one possible thing that may be causing what you are seeing. I've built a new version of the firmware with a potential fix in it. I assume you are running the latest release version of leJOS? if so you can download this test version from the following location:
http://www.gloomy-place.com/lejos/i2ctest.bin
Use this to flash your NXT instead of the release lejos_nxt_rom.bin and try running your tests again.

Oh one other thing I noticed that you are using getData to read your results (at least that was the code in the drop box file). This may not be a good idea as getData will always write a register address to read from to the NXT. My understanding is that this device does not support that mode of operation. The code that you posted at the start of this thread (using i2cTransaction), did not do this so you may want to revert to using that code. No idea if this is causing any problem, but if the new firmware does not help you may want to try changing this...

Andy