7

I am planning to use an I2C sensor connected to a junction box, which is connected to a control device. The control device and junction box are connected via I2C as well (same I2C wires as for the sensor). The distance between the control device and the junction box is 1m and the sensor cable going from the junction box to the sensor is about 70cm.

I will be using the lowest I2C speed and shielded cables in this application. Are there any other measures we can add to the junction box, for instance, to improve I2C communication over longer distances?

psmears
  • 704
  • 4
  • 7
user14665305
  • 341
  • 1
  • 7
  • Maybe the answers to Reduce noise on 2m I2C bus using motorcycle power can help you. – ocrdu Feb 27 '24 at 08:34
  • 4
    I first read 70m but it's 70cm. A total of less than 2 meters? For an I2C bus, I will not consider that as "long". – Justme Feb 27 '24 at 08:47
  • This answer may help you understand why slave to master responses is the problem when extending cable. – Andy aka Feb 27 '24 at 09:18
  • 1
    https://electronics.stackexchange.com/questions/106265/maximum-i2c-bus-length – Daniël van den Berg Feb 27 '24 at 16:39
  • "...and shielded cables..." do you know the capacitance per meter of the cables you plan to use? I2C is limited by the total capacitance of the bus, to answer your question this information is needed. – Vladimir Cravero Feb 28 '24 at 11:08
  • If the remote sensor is powered over the same cable as the Comms then I assume you have 4 wires in the cable plus the shield. Chances are you have conducted emissions in this cable which then radiate...possibly some of that noise is on the actual i2c wires but the power +/- pair are also good candidates for noise. Consider a common mode choke at the power source on the power pair. Consider also adding low pass filters to the clock and data lines that will allow the rising edge to pass but block higher frequency. Needs careful RC choice (R can be i2c pullup). – Robin Iddon Feb 29 '24 at 08:45
  • And of course make sure your junction box and sensor don't cause power noise in the other direction. Assume high inductance cabling and go mad with the decoupling when the power lands on junction box and then again at sensor. Also for the low pass consider whether a ferrite in each of clock and data can help. I would leave room for one and fit 0r if not required. And finally be careful what you connect the shield too. I would definitely not connect it to power negative at both ends. I cannot say what I would connect it to in your design. You don't want it to be a signal return path! – Robin Iddon Feb 29 '24 at 08:57

6 Answers6

8

The I2C bus length is less than 2 meters in total, 70cm plus 1 meter.

You likely have longer HDMI/DVI/VGA cables in your home or office with I2C running fine between devices for more than 2 meters at up to 100 kHz.

If otherwise the host or the device ends are designed properly, it does not need anything special in the junction box in the middle to work any better. It really makes no difference if you split the I2C bus into two 1 meter sections with some I2C buffer IC.

For only 2 meters, there should be no need to use expensive chips for differential I2C, or switching to RS-485 or CAN buses either.

Justme
  • 147,557
  • 4
  • 113
  • 291
  • In the previous version of the product, we had 100cm as a total length of I2C cable. It was working fine, however we had issues with EMC immunity testing (radiated emissions were causing problems on the I2C comms). This was the reason why I am considering a shielded cable. Any thoughts on it from an EMI compliance perspective? – user14665305 Feb 28 '24 at 17:52
  • @user14665305 Like I said, if done properly, it should work. I don't know how good or bad design you already have, so what you have already done correctly as per the best practices, and what has been made against the best practices and needs improvement. If already done correctly, adding 70cm of shielded cable and a junction box should not matter. But if you say you already have EMC problems with 1m cable, you can start a new question about reviewing your current design. – Justme Feb 28 '24 at 18:02
3

Fitst of all, IIC or I2C stand for Inter-Integrated circuit which means it should be used over short distance.

The reasons behind this are.

  1. Open drain output produce slow slew rate over long wire.
  2. Non-differential signal prone to EMI noise.

To communication over long distance can can consider another protocol that designed for this task like RS485.

However, if it really the case you can use I2C buffer that provide differential signal like this product. Sparkfun QWIIC Bus

M lab
  • 1,404
  • 6
  • 29
  • 3
    Do you really think 2m of I2C is really so long you need RS-485, which allows for 1000m bus, or differential I2C buffers? If so, can you say how long I2C you consider long? – Justme Feb 27 '24 at 08:50
  • @Justme It also depended on EMI of environment. In my project, I2C OLED with 30 CM wire near AC motor can not operate reliably. – M lab Feb 27 '24 at 11:58
  • Of course EMI matters. Here, shielded cable is used. If otherwise designed properly, the junction box in the middle of a 2m bus should not be an issue. If it does not work, then the junction box was not the problem to begin with. Both ends of the cable must be well designed, and if they are not, the junction box will not make it work no matter what tricks it might use. And for example people use 1-Wire sensors over much longer buses, and they are also open-drain and non-differential. – Justme Feb 27 '24 at 12:15
3

Will be using the lowest I2C speed

The I²C spec doesn't define a minimum speed but what you should worry about is the rise time of the pulses regardless of the communication speed. Your system will run at standard mode (up to 100 kbps) so the rise times should not be higher than 1000 ns = 1 μs. Check here for details.

The pull-up resistors you'll use with SDA and SCL lines, and the cable capacitance will determine the rise time. 1 kΩ pull-up and 500 pF cable capacitance give a rise time of ~1 μs, for example (approximately \$2.2 RC\$ to reach 90% of the target voltage).

... and shielded cables in this application.

I'm not sure if a shielded cable may help here as the shielded cables tend to have higher capacitance. One may think about using lower pull-up resistor in case of a distorted/corrupted signals or communication but it's limited by the end devices' drive strength/capability.

So, maybe you should consider more long-distance-friendly communication protocols such as CAN or 485.

Rohat Kılıç
  • 33,940
  • 3
  • 29
  • 85
  • 2
    Do you really think 2m of I2C is really so long you need CAN or RS-485 transceivers? If so, can you say how long I2C you consider long? Also, I2C has no lower clock limit - but the actual chips might have, for example I2C-based SMBus sensors have minimum clock frequency. – Justme Feb 27 '24 at 08:56
  • @Justme can you say how long I2C you consider long? depends on the cable capacitance. HDMI and VGA cables which inherently carry I2C signals have only a few tens of picofarads per foot which allows you to carry 100 kbps I2C over 2 metres. I2C has no lower clock limit - but the actual chips might have how does this relate to my answer? I didn't say the opposite. What matters is the rise time. – Rohat Kılıç Feb 27 '24 at 09:50
  • HDMI allows for up to max 800pF total, max 50pF for each device and max 700pF for cable. Compliance tests require the device to work with a total of 750pF capacitance. Generally, you would not worry about cable capacitance on a 2 meter I2C bus. I would also not worry about the rise time. There are other things to be more worried about on a 2 meter I2C bus. In practice, if the clock is slow enough, does it really matter if rise time is more than 1000ns? Because some sensors are not even I2C compliant, only compatible. – Justme Feb 27 '24 at 10:58
  • @Justme: Some devices, given a sufficiently slowly rising edge, might perceive it as two edges if a bit of noise causes the signal to briefly fall just below the switching threshold immediately after it had risen above it. Some devices resolve this by having separate circuitry to detect the start and end of rising and falling edges, performing different actions on each. This is a bit different from using a Schmidt trigger, in that any metastability that might be induced if a signal "barely" crosses a threshold will be resolved by the signal solidly crossing it. As a simple example... – supercat Feb 27 '24 at 18:09
  • ...a device might transition from "have just sent bit 3" to "ready to send bit 4" any time the clock is above the upper threshold (staying in that state no matter how many times the signal crosses that threshold), and from "ready to send bit 4" to "have just sent bit 4" any time the signal is below the bottom threshold. If the signal barely touches the bottom threshold before rising slightly, the device may sit in a wobbly state between "ready to send bit 4" to "have just sent bit 4", but if the clock goes stably low it would progress solidly into the latter state. – supercat Feb 27 '24 at 18:12
  • @supercat You may be right. Standard Mode deviced are not required to have Schmitt triggers, but Fast Mode and beyond require Schmitt triggers. However, they all require a noise margin. Yet, I2C specs have a chapter how to operate above maximum allowed bus capacitance, which hints that if you don't intend to run at maximum speed, you can reduce speed and allow for slower rise and fall times. The limits for rise and fall times must be met, if you intend to run at fastest speed, to guarantee that the wire stays at high and low levels for long enough. – Justme Feb 27 '24 at 18:20
  • @Justme: I forgot to mention another reason for the rise/fall times: if two devices both look for a single threshold to detect the falling edge of SCL, and a device that changes its SDA from high to low in response has a higher SCL threshold than the device, that other device might perceive a start condition. If a master device can determine when a signal has risen or fallen enough that all slaves will perceive its new state, it may be able to adapt its speed to the actual rise and fall times of a network, – supercat Feb 27 '24 at 18:31
2

You can, but it is not recommended.

I2C is designed for communication within the board.

If you want to run I2C over long distance you need to use minimum clock frequency and also you can use I2C-bus extender like P82B715.

Hari
  • 2,207
  • 14
  • 29
  • 5
    Do you really think 2m of I2C is really so long you need differential I2C buffers? If so, can you say how long I2C you consider long? – Justme Feb 27 '24 at 08:51
1

With reasonable cables you should be fine

At the company I work for, the calibration for our nanopositioning actuators is held in an I2C EEPROM inside the connector shell. The idea is that when you swap out actuators, the calibration for the new actuator comes along with it, giving us full interchangeability without needing recalibration. This is a big selling point for field replacement of actuators when they inevitably fail after some time.

For most systems, the actuator plugs directly into the controller box. For a number of systems though, there's a significant cable run between the controller box and the actuator. To avoid dismantling the customer's system, we need to use a permanently-installed extension cable from the controller to the actuator's location - and then the actuator (with the I2C EEPROM) plugs into the end of that. These extension cables can be up to 5m long. And my firmware runs I2C down that at the "standard" I2C rate of 100kbps.

We've never had a problem with it. So long as the cable is intact and the connector is properly mated, it all just works. We're using some fairly nice low-capacitance cable, but I don't imagine 70cm will be a problem unless you're using something particularly horrible cable-wise. I would recommend looking at cable termination, of course, but that should be something you'd do as a matter of course for any comms link.

Basically, unless you really screw something up, you're probably fine.

Graham
  • 6,150
  • 13
  • 20
0

A length of 170cm is not all that long at all for I²C, but the concern with I²C is capacitance of the cable. The higher the capacitance, the higher the rise-time: the pull-up and the cable capacitance form a RC filter, which limits the available bandwidth. This is well explained in other answers, so I won't explain it all again.

This means that to reach a given bus speed, say 100kHz, so must either reduce cable capacitance or decrease the pull-up resistor. This is however a limit to how low you can reduce the PU, because low value requires increasingly large currents. I²C devices can typically handle >10mA just fine, but some devices may only be able to drain 5mA or so.

For HDMI cables, you will figure out that it is marginally possible to meet the target of 700pF with 2.2k resistor at 100kHz, because your PCB and devices also add some capacitance. You can buy HDMI companion chips that will provide high-speed TVS, 5V reverse supply blocking and more importantly an edge-rate accelerator for the I²C bus.

The edge-rate accelerator is basically a small circuit that checks the bus voltage. When the accelerator senses a rising voltage, it will enable a push-pull driver that will kick-in to drive the line hard. Likewise, a falling bus voltage will trigger that output to drive it low. You can buy such ICs standalone if you are concerned for your design. You can use LTC1694 or any other similar IC. There is a nice screenshot in the linked datasheet that explains it all on the first page.

The nice thing about those ICs is that you can add them in parallel to the bus. Therefore, you can add the footprint and add/remove them as needed when qualifying your design.

It is best to add them at both ends of the cable if you have a very long cable because the inductance of the cable would induce asymmetric performance, but for 1.7m, that shouldn't be much of an issue.

Mishyoshi
  • 1,710
  • 8
  • 11
  • I don't see your calculations, but with 700pF and 2k2 pull-up, rise time is 1300ns, which is outside I2C specs. However, the 700pF is allocated for cable itself, so there could be up to 800pF. And 2k2 ohms pull-ups are also outside HDMI requirements, so they are hopefully not used anyway. I bet less than 2 meters of cable will be close to any I2C limits for capacitance. – Justme Feb 28 '24 at 15:44
  • @justme I know that 2.2k is outside I2C spec, but thank you for clarifying this for other readers! My point was that even considering this, you can barely make this work without some help (edge-acceleration)... – Mishyoshi Feb 28 '24 at 15:48
  • I think this is very doable without special tricks like edge acceleration, i.e. well within specs. You say it's barely doable, which I interpret to mean it is so near limit of not working so it almost can't be done. – Justme Feb 28 '24 at 15:51
  • @Justme I've experienced many displays not working well probably because they are not 100% compliant with HDMI spec. My company doesn't have the resources to handle customers complaints due to cheap crappy cables, non compliant displays and what not. There is not a lot of margin on HDMI spec when you consider source and sink added capacitance, environment noise (heavy industrial) and it is simpler to put that chip and make the whole thing work all the time, YMMV. Anyway, the HDMI example is not all that relevant to the fact that such chips do exist and is a potential solution for the OP. – Mishyoshi Feb 28 '24 at 16:13
  • My experience from designing HDMI devices, their incompatibility issues have almost never been caused by poor communication on the HDMI DDC bus due to too much capacitance, or too slow rise/fall times. Also, you can make a perfectly compliant device electrically, but they may still be 100% incompatible with each other for other reasons how their hardware or software or chipsets work together as a whole. – Justme Feb 28 '24 at 16:37
  • Slow transitions from capacitance are bad for throughput but good for EMI/EMC. One problem with I2C is that the edges are asymmetric: the falling edges may be fast with high frequency harmonics at the same time the rising edges are problematically slow. A bit of series resistance (perhaps 5% of the value of the pull-up resistor) can help filter out harmonics from the falling edges. – Ben Voigt Feb 28 '24 at 19:05