Determining sampling rate based on I2C port speed

[hippicurean]

Hi all,

I have a system set up such that the NXT will read four bytes of data from a sensor at every program cycle. The NXT is loaded with the nxtOSEK operating system, so the I2C port speed is limited to 9.6 kbit/s. I would like to find out the maximum sampling rate with which the NXT can cope. For starters, four bytes are equivalent to 32 bits, so 9600 bit/s would indicate 300 samples per second, yes? What about the one-byte worth of commands that the NXT master has to send to the sensor (slave) in order for the latter to respond, i.e. SLA+R (slave address + read bit)? Would that lower the potential sampling rate even further? Could someone please shed some light on this? Thanks.

Cheers
Hippie

[mattallen37]

Well, first I need to say that I have never used nxtOSEK. Second, my I2C knowledge is limited.

Okay, so based on what I heard about I2C tests with the Lego FW (which is limited to the same speed), the number of bytes doesn't make a huge difference on the overall time it takes to read. Maybe it does make a difference, but I don't think it's linear by any means. And yes, the master overhead is also limited to the speed. That means that if the master sends the address, read bit, and register number, that is 2 bytes of master overhead limited to the 9.6k bit per second. In theory it seems logical that (according only to the I2C speed), you could read the sensor 200 times a second, but then there are also other bits used (ack, nack...). I would say maybe 190 reads per second based on the I2C reads, but probably even less considering the time it takes for the FW and user program to execute.

[gloomyandy]

The other thing to remember is that every byte sent over the i2c bus is actually 9 bits not 8 as there is an extra ack bit associated with each byte. As Matt mentioned there are also other bits involved in the protocol and as I think nxtOSEK uses a very old version of the leJOS i2c driver (which was based on the Lego implementation) there will be extra states involved. Also are you reading a particular register from the device, or simply issuing a read request? The actual transactions for a read of 4 bytes looks something like this...
start (2 clocks)
send device address + read (9 clocks)
delay (5 clocks)
read 4 data bytes (9*4 clocks)
end (1 clock)
so the 4 byte read will be at least 53 clocks so 181 samples max

If you are issuing a read from a particular register address then things are a little more tricky...
start (2 clocks)
send address + write (9 clocks)
send reg address (9 clocks)
stop (2 clocks)
restart (2 clocks)
send address + read (9 clocks)
delay (5 clocks)
read 4 data bytes (9*4 clocks)
end (1 clock)
which gives a total of at least 75 clocks... which is 128 samples max...

Note that the above sequences include some non standard states (like the delay, an extra stop and the end states), which are issued by the Lego i2c code (and also be leJOS when operating in Lego compatibility mode)...

Andy

[hippicurean]

Thanks for the input, Matt and Andy. Wow, the sampling rate is far slower than I thought. By the way, I forgot to mention in my opening post that the NXT also has to read from the slave register address. Is it even possible for the NXT to request data from a slave without specifying the register address? How would it know where to read from, e.g. TWDR (TWI data register) in my AVR-based sensor? Andy, you're right about the nxtOSEK and its antiquated I2C driver set. Unfortunately, all emails to the developer have gone unanswered, and he is the only contact listed on the Sourceforge project page.

Cheers
Hippie

[mattallen37]

If I2C speed is more important to you than processing speed, you should look into using either ROBOTC or NXC. Both of them are based on C/C++, both support fast I2C, and both are still actively being developed (with great support).

Just as an I2C speed example, I was able to bring one of my NXC I2C drivers from about 14.4ms per read to about 2.5ms per read (over 5 1/2 times the speed). Of course, NXC program execution isn't as fast as nxtOSEK or ROBOTC, but it all depends on what you need.

[gloomyandy]

Or if you are happy using Java you may want to consider leJOS (i2c speed of 125KHz). If you are interested in i2c performance you may want to take a look at the following threads...
https://sourceforge.net/apps/phpbb/mind ... 89&start=0
https://sourceforge.net/apps/phpbb/mind ... 7&start=10

Andy

[hippicurean]

Thanks to both again for the information. Unfortunately, the software platform that I'm using is dependent on nxtOSEK. My programming is mainly done within the Matlab/Simulink environment, and there are only two software tools (one is actually derivative of the other) that support both Simulink and NXT - and these tools are both underpinned by nxtOSEK. As I've already constructed extensive models (i.e. at least a couple of years' worth of work) in Simulink, moving to a completely new platform is virtually unthinkable. Updating the leJOS I2C drivers in nxtOSEK may require a lot work or it may not. I wouldn't know because the developer doesn't care to respond to my queries regarding this issue.

I've learnt an important and painful lesson, alas belatedly: Don't depend on free or open-source software for important tasks unless it's widely-used and well-supported.

Cheers
Hippie