# I2C Communication Speed across Sensors

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.

• 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? Commented Nov 28, 2012 at 7:43
• They are I2C error codes. Yes Im interested in the shortest interval between the polls. Commented Nov 29, 2012 at 21:08

$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.