Possible I2C speed up for digital sensors about nxt-python HOT 13 OPEN

Excellent idea, and nice to see you again Linus. I spent an hour or two writing 
a quick bit of code to implement this, and it's looking good. When using 
bluetooth, the time for one sample goes from 162ms to 112ms, a reduction of 
31%. When using USB it's 45 to 33 or 26%. With some intense hacking I was able 
to further reduce it to 28ms by sending a another ls_write request directly 
after sampling to prime for the next read, but that method carries the risk of 
a small nuclear explosion.

Actually, it just messes things up if you're not trying to probe at insane 
speeds.

Anyway, this is promising. I will commit my changes and see if anyone finds 
problems with them. For now, fixed. I may also look into this in v2.

In v2, the exact same changes can be made: For bluetooth, the inprovement is 
from 145ms to 100ms, or 31% decrease. With USB, it's 45ms to 31.8ms, 29%.

Thanks for pointing this out!

Unfortunately, this caused a bug with query results detailed in Issue 13, so I 
had to revert it. What a shame!

I have noticed another possible bug in our code which may have been causing 
Issue 13 and will be taking another look at this. See my comment to that ticket 
for more details.

I have no idea what happened to my effort on this and can only guess that I 
couldn't get it to work at all. In any case I'm not working on it at the moment.

Marcus, is it possible for you to continue work on this? Those speed increases 
would be very useful if it works correctly.

Everything I tried introduced some new bug with the communication. I tried many 
fixes and none of them helped. If anyone else wants to take a look at this, 
they're welcome to, but I can't make it work.

It's really a shame that this doesn't work. Unfortunately, I'm not familiar 
with the nxt-python sourcecode, and I haven't set it up right now (also I don't 
have an NXT at hand atm). But I can again confirm that this "shorter command 
sequence" works, and we've not yet found a sensor that doesn't support it. I 
can definitely say it works for the LEGO Ultrasonic, and for the HiTechnic 
Accelerometer, Color V1 + V2, IR Seeker, and EOPD sensors.

The whole magic, complete with documentation of the trick, happens in this 
function: 
http://www.mindstorms.rwth-aachen.de/trac/browser/tags/version-4.04/RWTHMindstor
msNXT/COM_ReadI2C.m (I already posted it).

Maybe it helps if I try to describe the whole process, how we do it 
sucessfully, in my own words again:

Open sensor:
1. Set correct sensor mode: Use SetInputMode with LOWSPEED_9V and RAWMODE
2. Let the sensor boot up (depends on sensor, wait between 50 and 300ms).
3. Depending on sensor: Send commands via LSWrite. I.e. for ultrasonic: Send 
CONTINUOUS_MEASUREMENT (0x02) to register 0x41 and address 0x02 (this might be 
enabled by default anyway).
4. "Flush out old data?", a comment made by Dick Swan, developer of RobotC for 
NXT: This is just sending an LSRead command (and collecting the answer packet).

Now the actual retrieving data:
1. Send LSWrite with the register you need to retrieve. You don't neet to 
request an answer packet.
2. Now, in a loop, we keep on polling LSRead
3. a) Statusbyte == 0 or bytesRead > 1 means SUCCESS! Break from loop, 
interpret data
   b) Optional: Statusbyte == 221 or == 224 means errors we probably can't recover from (wrong sensor mode, cable disconnected). Retry or exit, whatever you want, try for yourself.
   c) If timed out: Give up
4. Interpret content of the LSRead command from step 2.


As I said, it's actually very simple. Instead of using LSGetStatus, EVER, you 
can just use LSRead. LSRead returns the statusbyte just as LSGetStatus, but 
ALSO returns data payload if available. So if statusbyte == 0, use the data.


We don't do sensor-name-checking like Vendor ID and so on, but I tried this, 
and it works, too. But maybe this is not the best test case, I don't know.


Anyway, just wanted to tell you guys this and "not let you down". I know it's a 
bit frustrating when people just tell other people what to do and don't 
implement it themselves... Sorry, and good luck anyway.

So actually, Marcus, I know you tried lots of thing and we also had a 
discussion about this in another issue (with a new bug introduced). However, I 
wanted to try to post the "packet sequence" again. It might be that the bug is 
introduced "at a higher level" somewhere in nxt-python. But if looked at the 
whole thing at low "packets in, packets out" debug level, I honestly can't 
imagine why it would in one programming language and not in the other.

As for "drivers": We've tested this on Windows and Linux with both USB and 
Bluetooth (Fantom, serial port, libusb, /dev/rfcomm), and apparently people are 
also using it on Mac OS...

Best regards, Linus

All right, I will look at this again.

I was discussing this issue with the developer of MindSqualls (a package 
similar to nxt-python, but for .net) on the Mindboards forums here: 
https://sourceforge.net/apps/phpbb/mindboards/viewtopic.php?f=3&t=1014

His version of the algorithm is:
1. Use LsWrite() to tell the sensor which I2C register you need
2. Pause 22 ms.
3. Call LsRead() to get the value.
3a. If error == PendingCommunicationTransactionInProgress repeat from step 2.
3b. If error == CommunicationBusError repeat from step 1.
3c. If error == unknown Fail.
4. Return the value from LsRead.


He reports these performance improvements:

> Response-time: 104 ms -> 81 ms
> Commands: 3.9 -> 2.1

Some news again from the mindboards thread I linke to above: Apparenty the 
problem that is described in Issue 13 only occurs with USB connections (it also 
says so in Issue 13). This I2C speed-up however is only important for Bluetooth 
connections.

So why not enable this faster algorithm for Bluetooth, but nor for USB?

Every time I try to work on this, I break things. If you could come up with a 
patch that works and implements the improvements, it would really help this 
along.