# Maximum I2C Bus Length?

What is the maximum length of cable that could be used to connect two I2C devices (I2C master-> I2C slave)?

Yes, I know that I2C is really designed for intra-board communication. I have been tasked with a "design goal" of using a common I2C bus for multiple I2C slaves to support a demo.

For purposes of clarity, let's assume the standard I2C bus rate of 100 kHz.

• The max length comes I to play with the capacitance introduced by the length. Too much capacitance and it could affect your speed. So as always, this depends. – Gustavo Litovsky Apr 11 '14 at 20:38
• @GustavoLitovsky You are correct about capacitance. It also depends on the type of cables being used (shielded vs non-shielded). I'm most interested in a general guideline. – Nate Apr 11 '14 at 20:44
• @Nate Guideline: maximum net bus capacitance of 400pF. (Somewhat related to the question: Memoirs of an overgrown I2C bus.) – Nick Alexeev Apr 11 '14 at 21:15
• I2C = Inter-Integrated Circuit bus. It's not designed for long distances between boxes, and certainly not at 400kHz. – Spehro Pefhany Apr 13 '14 at 20:18
• Just wanted to throw in some personal experience aside from calculations. I have done a demo going from a dev board to an I2C to USB converter with an unshielded wire about 3ft. Didn't look pretty, but it worked 90% of the time. – mcmiln Feb 3 '16 at 18:03

For fast mode, and resistor pullup, capacitance should be less than 200pF, according to this NXP document I2C-bus specification and user manual.

With current source pullups you can go to 400pF, but not with resistors.

If your wire is 20pF/30cm and you have another 50pF of stray and input capacitance, you're limited to 2.25m of cable length. Different assumptions will lead to different numbers.

The insane sounding lengths like 10,25, and 100m are perfectly possible, and I use the method often (with UART not I2C, but the method stands) when I need to put stuff together quickly. It's not exactly the best way, though.

The key is to know your input voltage threshold. Make sure the voltage drop in the ground lead is well below this, or else a transmitter at a high ground potential will not be able to pull the voltage low enough. Lack of tolerance for ground offsets IMHO is the biggest reason to use RS485 or can transceivers (I2C over CAN is mentioned in a few application notes).

Ideally, all devices will have their own wall wart and battery and no power will be sent over the ground wire between devices.

But, lets take CAT5 for example. CAT5 can't be higher than 52pf/m, or it isn't CAT5.

100m of 52pf cable has a capacitance of 5200pf or 5.2nf.

5.2n times 20kohms (pullup) gives a time constant of about 104 microseconds. That limits speed to about 10kHz or so.

Using 2.2kohm pullups, you could probably get to 100kHz.

I have heard that devices should have a resistor on SDL and SCK, because of the big capacitive load they are driving, of something like 180 or 200 ohms.

But honestly, I2C is not at all the way to go for long distances. CAN transceivers or RS485 used with normal UART is a robust solution with very good fault protection, ESD resistance, speed, distance, etc, at a cost of a dollar a chip or so, ground offsets don't matter nearly as much so you are free to carry power along with data.

The only downside is that a can transceiver can reach 70ma transmitting and 1 or 2ma just listening, so I2C or direct TTL UART might be useful in extreme low power situations, but consider how much time you actually spend sending.

I work for a company making USB sensors. Most of them are based on I2C sensor chips, those devices can be split in two, so you can install the CPU part in one place and the sensor part in another. We conducted quite a lot of tests on the I2C connection between the device CPU and the I2C sensors. At 100 kHz, with a good error recovery protocol, 25m can be easily reached using basic wires. We were even able to reach 100m once with CAT5 cable.

• It sounds like you're talking about USB cable length. The OP is asking about cabling raw I2C. This is an entirely different subject. If I'm incorrect, edit your answer and I will remove my downvote. – DoxyLover Apr 12 '14 at 5:25
• 25m is quite a lot even for a usb... – Vladimir Cravero Apr 12 '14 at 6:23
• No, I'm really talking about the I2C connection between the device CPU and the I2C sensor chips, not the USB connection between the host and the CPU. Here is an example: yoctopuce.com/EN/products/yocto-meteo/doc/… – martinm Apr 13 '14 at 5:43
• If you wanted to use twisted pair for I2C and power, which pair would you twist together? (SDA, SCL), (VCC, GND) or (SDA, GND), (SCL, VCC) ? – Cano64 Feb 12 '15 at 15:23
• Ideally, you don't use twisted pair at all. Twisted pair is useful for balanced signals. If you don't have any other cable, twist signal with ground. If you really only have four wires, think about how much power the remote end consumes – you may end with a higher-than-tolerable ground offset – before committing to using only one wire for GND. I usually use old Cat5 cable (not higher! the double shield adds capacity you don't need) with one pair ground, one pair +5V, and SDA+GND and SCL+GND pairs. – Matthias Urlichs May 24 '17 at 16:19

Something like NXP's P82B96 could be used to change the voltage levels on the bus, allowing much longer distances.

The datasheet contains examples for I2C cable lengths of 3m, 25m, 100m and 250m.

There are other chips that have similar functionality.

• The problem with the NXP chip is that you end up requiring twice as many wires. Any other ideas? the bidirectional ICs I've found don't go above +5V. – Matthias Urlichs May 24 '17 at 16:32

IIC is a synchronous protocol, and as such, it can be run arbitrarily slowly to meet system requirements with respect to distance and noise.

There are many examples of using IIC over a cable, all the way from ACCESS.bus back in the 1990s to how it is used today to retrieve EDID information from video displays.

• Another example is the Wii Nunchuck, that connected to the Wii Remote via I²C using a 4 foot shielded cable. – tcrosley Apr 11 '14 at 23:46