2
\$\begingroup\$

I'm curious as to how fast I can communicate between multiple sensors. I have a board with an adxl345 digital accelerometer and an itg3200 3-axis MEMS gyro on I2C. I'm trying to build an IMU which requires fast polling of both sensors. The faster I try to poll, the more error codes I get. How can I calculate the optimal delay required for simultaneous communication? Also how fast can I2C really communicate between multiple sensors?

PS. Im on an atmega128 chip @16MHz.

\$\endgroup\$
2
  • \$\begingroup\$ What you you mean by faster: higher I2C clock, or a shorter intervall between the polls? And what type of errors do you get, are they error codes from the devices, or I2C communication errors? \$\endgroup\$ Commented Nov 28, 2012 at 7:43
  • \$\begingroup\$ They are I2C error codes. Yes Im interested in the shortest interval between the polls. \$\endgroup\$ Commented Nov 29, 2012 at 21:08

1 Answer 1

3
\$\begingroup\$

\$I^2C\$ is a clocked serial protocol, which in general means that there is very little which limits the speed electrically. Most \$I^2C\$ busses run at 100kHz or 400kHz, which will far outstrip most IMUs' ability to output data.

For example, I was on a robotics team which used a Memsense nIMU and if you look at the datasheet, it says that the bandwidth is 50Hz, and it outputs 34 bytes in a packet. This means that you could theoretically pull up to \$50*34*8=13,600\$ bits per second or 13.6 Kbps. The chip we ran with could run up to 400kHz so it could handle quite a few of these on the bus at maximum data throughput.

Looking at the datasheet for the atmega128 you provided, it says the "TWI" or two-wire interface is limited to 400kHz. Knowing the \$I^2C\$ protocol, this will be 2 clocks for the start condition, 1 clock for the stop condition, and 9 clocks for the address, and 9 clocks per byte. So using the nIMU I referenced before, this gives a virtual \$34_{bytes}*9_{clocks per byte}+9_{address clocks}+2_{startbit}+1_{stopbit}=318\$ clocks per packet. This means that there was no limit on the sampling rate, we could read \${400,000/318}=1257\$ packets per second. Since we're limited by the sampling to 50 packets per second, we could instead have 25 IMUs sending out data.

Looking at the ITG datasheet, you'll need to do some math to calculate exactly the maximum sampling rate, but I think 125Hz looks like a good baseline (see section 8.2). It outputs 3, 16 bit numbers giving 48 bits per sample. \$48*125=6,000\$ bits per second. Well within range of the 400kHz you has access too. With the adxl345 it looks like the maximum data output rate is 3,200 bits per second (I think?).

So from the looks of it, the combined maximum throughput of the two devices you've picked is 9,200 bits per second, and the atmega128 has a throughput of ~400,000 bits per second. I don't think you need to worry about the ability of \$I^2C\$ bogging down the system.

\$\endgroup\$
2
  • \$\begingroup\$ Nice! I was doing similar calculations however when I was polling both sensors less than 5ms apart, I started getting I2C status code errors. Any ideas why this was? 5ms should be ample time for both transactions to occur. \$\endgroup\$ Commented Nov 29, 2012 at 21:15
  • 1
    \$\begingroup\$ So you should be using the INT pin on your ITG if you are not already. Look at section 8.4, and set it up so that RAW_RDY_EN is set. If you ask for data more frequently then when that pin becomes active, you will get errors. If that interrupt is happening less frequently than you're expecting, check the other config values for the device, there's a lot of different stuff (look at section 8.2). There is something similar (INT1 and INT2) for the adxl345 that you should figure out and use. You shouldn't be polling at a regular interval, use the provided features of your chips! \$\endgroup\$
    – Kit Scuzz
    Commented Nov 29, 2012 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.