In my current project, I need to communicate between a microcontroller and some sensors over I2C. One of them is a temperature sensor, it needs to be placed at approximatively 2 meters far from the microcontroller. I cannot choose another protocol (the sensor is on a module with given connector/pins/protocol).

Do you think it is possible to communicate in this configuration? What information should I look up to ensure it can or can't be possible? Do you have some advice?

It is my first time communicating with IC outside the PCB.


I2C is not designed to be used over long distances but I know of several applications where it is actually used over a distance of about 2 meters. I also know of one case where they had issues with that and it was eventuelly fixed by fixing ground loops I believe.

To be sure that it will function, you should use an I2C bus extender like the P82B715.

However, the datasheet of the PB2B715 says the following in section 8.2:

For typical twisted pair or flat cables, as used for telephony or Ethernet (Cat5e) wiring, that capacitance is around 50 pF to 70 pF / meter so the cable could, in theory, be up to 50 m long. From practical experience, 30 m has proven a safe cable length to be driven in this simple way, up to 100 kHz, with the values shown. Longer distances and higher speeds are possible but require more careful design.

So the experts (NXP is the former Philips, the inventor of I2C) say that 30 meter has been proven a doable distance. My experience says 2 meters is a doable distance, and experiences that were reported back to me indicate that more heavily loaded I2C buses without any extender are also possible.

The key points to working I2C buses on long distances are:

  • Using a low capacitance cable (twisted-pair/Ethernet);
  • Limiting the bus speed;
  • Having pull-ups that are correctly sized.

Pullup calculation

Texas Instruments has a good application note (SLVA689) about pull-up calculation .

  • The lower bound of the pullup (minimum value) is determined by the current the weakest peripheral on the bus can pull, and the maximum voltage that represents 0 for any peripheral. So if 1V is still 0, your VCC is max 3V6 and your weakest device can only pull 20mA, your resistance is determined by the voltage loss over the resistor and the current pulled by that device: \$(3.6\ \mathrm{V}- 1\ \mathrm{V})\ /\ 20\ \mathrm{mA}=130\ \Omega\$ .
  • The upper bound is determined by the maximum rise time: your maximum I2C frequency is directly related to that, but there is also an upper limit defined by the protocol. The upper limit is \$R_{max}=t_r/(0.8473 * C_b)\$ . Where \$t_r\$ is the maximum rise time and \$C_b\$ is the bus capacitance. So if \$C_b\$ is 400pF, and the bus is operating in standard mode (\$t_r\$=1ms), then you'll find \$R_{max}=2950\ \Omega\$ . TI's application note has graphs so that you can find appropriate values quickly.
  • Of course the value for the pullup is the equivalent value of all pullups in parallel combined. You may have a pullup on the master end, the slave end, and any other slave/master on the bus.
  • The more you are "at the limit", the more you also need to account for "parasitics" such as the voltage drop in the cable.
  • \$\begingroup\$ Having pull-ups that are correctly sized? How to determine the value and power rating? \$\endgroup\$ Oct 2 '19 at 14:24
  • \$\begingroup\$ As Nick B commented on another answer, be wary of the possibility of the bus extender chip or whatever else heating the temp sensor by a couple degrees. \$\endgroup\$ Oct 3 '19 at 7:39

You are generally limited by 400 pF maximum bus capacitance.

It should work fine if you lower your frequency to something like 1 kHz and provide power supply decoupling next to the sensor.

If you need something more robust then you can use differential I2C converters on both ends like PCA9615.

  • \$\begingroup\$ I dimly recall some sensors having a minimum I2C frequency (not sure why). \$\endgroup\$
    – Michael
    Oct 1 '19 at 19:05

You can, but it is not recommended.

Different buses for different purposes

I2C, like SPI, is designed for communication within a board or group of boards (think Raspberry Pi and its hats or arduino and its shields). It can work over longer distances (see other answers) but should not be used in those cases, simply because that's not what it was designed, optimised and qualified for.

The risk you take is that you may not be able to add more sensors in the future, or that your system will not work everywhere, or will fail under certain circumstances.

What you should be looking for is a field bus, something like 1-wire, CAN, RS-485, ethernet, etc.

Wireless systems like bluetooth or zigbee could also be an option.


As noted by @filo, I2C is generally limited by the bus capacitance. However, there are ways to work around this:

  1. Use a bus extender. The P82B96 or PCA9600 would both be good options in your case.
  2. If you need higher speeds or extremely long cables, you can use a differential I2C transceiver like the PCA9600. However, this will make your circuit considerably more complicated, and you need an IC at both ends of the cable.

Take a look at AN10658 and AN11084 from NXP for more information.

  • 1
    \$\begingroup\$ This will work ok with a bus extender, as several others have said. Something not immediately obvious to watch for is that the bus extender at the sensor end can dissipate enough heat to raise the temperature sensors reading by a couple degrees if the sensor and bus extender are close together. \$\endgroup\$
    – Nick B
    Oct 2 '19 at 17:45

I like the answers of filo and Caleb.

Another option is using one or multiple DS28E17 1-Wire-to-I2C Master Bridges at the individual sensors and wire up the bus as Onewire. This is good for >100m buses and well suited to low-throughput sensor array applications as distributed temperature and battery management.

  • \$\begingroup\$ Interesting thought, though it may introduce additional software overhead if the master does not have a 1-Wire interface. \$\endgroup\$ Oct 1 '19 at 7:29
  • \$\begingroup\$ It mostly an option if you have a Linux host, as it has the full driver stack for this stunt. On a Raspberry Pi, you just have to connect GPIO4 to the 1W input of the DS28E17 through those 100m of wire (plus GND of course), edit config.txt and you are done. It's fully transparent, looks like a local I²C. Just slower. \$\endgroup\$
    – Janka
    Oct 1 '19 at 10:20
  • \$\begingroup\$ Thanks. I was really surprised that 1-Wire can do that sort of distance. I guess it makes sense, since resistors are smaller. \$\endgroup\$
    – domen
    Oct 1 '19 at 16:06
  • \$\begingroup\$ Onewire does not rely on rising edge timing but instead, all bit timing is done in relation to the falling edge, which is actively driven. That's why it is less susceptible to high capacitive loading. A few nF are ok. \$\endgroup\$
    – Janka
    Oct 1 '19 at 18:13

Adafruit now (2021) sells the "LTC4311 I2C Extender / Active Terminator". It works by monitoring the SCL and SDA lines and then injecting current during the positive transitions to help overcome capacitive line loads and sharpen the waveform. I've not implemented any yet myself, but the description says they've been able to read sensor data at 100kHz over 100m of Cat5 cable, and 400kHz at a few meters.


You only need one of these near the head end of the bus, with no other wiring modifications. Seems like this could be a much simpler and cheaper off-the-shelf solution than other options like RS-485 or the PCA9615-based extenders that SparkFun offers.



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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