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 mathrmV- 1 mathrmV) / 20 mathrmmA=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.

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.

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.

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.