If you’re reading these pages, odds are good that you’ve worked with I²C devices before. You might even be the proud owner of a couple dozen sensors pre-loaded on breakout boards, ready for breadboarding with their pins exposed. With vendors like Sparkfun and Adafruit popping I²C devices onto cute breakout boards, it’s tempting to finish off a project with the same hookup wires we started it with. It’s also easy to start thinking we could even make those wires longer — long enough to wire down my forearm, my robot chassis, or some other container for remote sensing. (Guilty!) In fact, with all the build logs publishing marvelous sensor “Christmas-trees” sprawling out of a breadboard, it’s easy to forget that I²C signals were never meant to run down any length of cable to begin with!
As I learned quickly at my first job, for industry-grade (and pretty much any other rugged) projects out there, running unprotected SPI or I²C signals down any form of lengthy cable introduces the chance for all sorts of glitches along the way.
I thought I’d take this week to break down that misconception of running I²C over cables, and then give a couple examples on “how to do it right.”
Heads-up: if you’re just diving into I²C, let our very own [Elliot] take you on a crash course.
Ok, so maybe I routed a couple feet of cable carrying I²C through my robot chassis to talk to my sensors. What’s the big deal? Once we start running signals over cables, there’s a host of assumptions that start to break down. Let’s take a quick tour of the two biggest challenges that are all too eager to bite us: bus capacitance and EMI.
Stretching out our Bus Capacitance
First, there’s the capacitance of those long wires. Remember, capacitors are just “two conductors, separated by an insulator.” Sound suspicious? If we look at our cable topology, a signal wire and a ground wire form exactly that–an unwanted capacitor! The longer our cable grows, the bigger this capacitor grows.
OK, so now that we know there’s a capacitor in our system, what, exactly, is it doing to our signal? In the ideal world, or at least when our conductors were short, we could expect a pretty short delay between the time our signal takes to exit one device and enter the next. In fact, it’s so short we can pretty much forget about our bus capacitance altogether. However, as that wire distance grows in size, that parasitic cap takes our nice clean signal and starts attenuating it.
Why is this happening? Let’s look at the bus architecture. I²C implements open drain configuration, which means each device has a MOSFET on it’s input, enabling it to pull the entire bus down to “logic 0.”
Assuming we’re running our I²C bus over a long cable, let’s now add our parasitic bus capacitor into our diagram.
With a little re-jiggering, let’s just examine one device and now model its transistor as a switch.
Behold! A wild lowpass filter has appeared!
When any device releases our SDA or SCL line from low to high, modeled above as a switch opening, we can’t just change the value of the bus instantaneously. Why? We must first pass our signal through this low pass filter, or, in more conventional terms, charge up this parasitic capacitor. The result? The received signal emerges not in that pristine, staccato square wave that we all know and love, but a diluted representation of the original, as if staggering back home from a rough night at the pub.
Fun Fact: Bus capacitance primarily affects rise time, not fall time, since the N-channel MOSFET which closes to create a “logic 0” signal is essentially creating a short to ground, bypassing the capacitor altogether.
With a stretched signal running over long wires, we need to start worrying about keeping that rise time sufficiently low for our receiving device(s) to read incoming signals correctly. Rise time is the amount of time for the voltage to reach a valid “logic 1” threshold level before it’s read. For I²C, the spec dictates 1000 nanoseconds for standard mode (100 kHz) and 300 nanoseconds for fast mode (400 kHz). If we stretch our rise time any farther, we’ll risk sending over bits that don’t get recognized as either a “logic 0” or a “logic 1.”
Fortunately for us, we have a slight amount of control over this rise time; we control it by changing the value of our pullup resistors. First things first, though: let’s clarify how pullup values influence the I²C bus. Earlier, I mentioned the stray capacitance coming from those looong wires running from master to slave device.
A stronger (fewer Ohms) pullup resistor decreases the rise time of our signals by increasing the allowed current that can flow through either signal line, which, in turn, charges our parasitic capacitor faster.
OK, so just how far can we go? Just how small of a resistor can we spec? If we want a snappy rise time, why not just go with a 100 ohm resistor–or something smaller? Unfortunately, with a stronger pullup, the amount of current that any one of our bus devices needs to sink will also increase. Let’s have a look at that diagram again.
Notice how N-channel MOSFETs are baked into each device? These FETs are responsible for actually driving the bus low, which, in turn, changes the bus values to either “logic 1” or “logic 0.” Since those MOSFETs are internal to each device, they’re limited by just how much current they can sink through the corresponding device without damaging it. Fortunately, the I²C spec actually dictates the maximum sink current; it’s a puny three milliamps. Hence, with only 3 mA, the strongest value pullup resistor gets very quickly limited to the low kiloohm range at best.
If you actually have an application where you’re operating somewhere in the range of these limits, you’re in luck! TI has put together the necessary equations to calculate bus pullup resistor values in one application note. Nevertheless, keep one thing in mind: the range where we can play this trick of reducing bus capacitance with stronger pullups only goes so far. Most people don’t care–and rightfully so, since most people don’t run I²C down a long cable in the first place to such an extent where bus capacitance actually matters.
Our problems with running I²C down a long cable don’t stop with bus capacitance. There’s one more foe that’s arguably far more nefarious.
We can thank the smartphone industry for gifting us with some pretty killer MEMs sensors, most of which speak I²C. With sensors like ST’s VL6180 time-of-flight sensor (Sparkfun Breakout) and Bosch’s BNO055 IMU, it’s tempting to cram these sensors into the corners of our robot chassis over long wires. Hold up, though. Robot platforms smell of moving parts, and moving parts smell like motors–which are huge sources of electromagnetic interference!
So, what exactly does EMI do to harm our system? EMI can induce voltage spikes on long cables. Remember: every long wire is, at heart, a good ol’ antenna, susceptible to picking up nearby electromagnetic waves. In a classic analog AM radio, changes in the amplitude picked up by this antenna would convert to audible sound. A digital system, however, doesn’t interpret continuous waveform amplitudes. It only interprets two threshold amplitudes which translate to a binary 0 or 1. While EMI might take on an analog form, we start to see problems when those unwanted EMI-induced voltage spikes cross those thresholds of the digital domain. The consequences? For our I²C bus, these induced voltages can translate to unwanted bit-flipping. Fancier protocols have error-correcting codes designed to handle occasional bit flipping and request a retransmission. Alas, I²C has no such thing.
Solutions for Long Runs
Bus capacitance and EMI are the two most common issues when we decide it’s time to run our I²C and SPI devices over long distances. Luckily, there’s a chorus of off-the-shelf solutions that are ready to handle these scenarios. Let’s take a tour of what’s on-hand.
For short cable runs, the easiest way to mitigate the noise risk would be to simply run the native SDA and SCL signals over a shielded cable. By far, this solution requires the least effort because, cablewise, it’s merely a facelift. Note that this solution only mitigates noise, and does nothing to solve the issue of bus capacitance. For that, you’ll still need to spec an appropriate pullup resistor.
Using shielded cable properly means we’ll need to ground the shield at one end. A shielded cable with the shield left ungrounded is merely dressed for the occasion, but it’s completely useless. A shielded cable with the shield grounded at both ends is now a ground loop (aka: antenna), which is almost as bad as leaving the cable unshielded to begin with. The rule from here-on-out: ground the shield at one end and one end only.
To make life easy for us, manufacturers usually add a naked extra wire, called the drain wire (seen on the left), which is electrically connected to the shield. Simply ground this wire at one end, and we’re done!
For long cable runs, some dedicated ICs can buffer the I²C signal, enabling the signals to run down a pair of wires with a much higher capacitance than what’s typically allowed on the I²C bus. The PCA9605 enables devices to run at the maximum allowable bus capacitance (400 pF) of the I²C spec. The PCA9605 takes that limit even further, allowing up to 4000 pF on the cable side.
The P82B96 does that, and a bit more. In addition to allowing a higher bus capacitance, it also enables the bus to run at a boosted voltage, making it even more noise immune. What’s more, the P82B96 can even be optoisolated, enabling interaction between devices on dissimilar power supplies. The datasheet boasts carrying an I²C signal across cables for up to 20-meter cables. Furthermore, by dropping additional P82B96 devices downstream along the cable, the signal can be boosted and regenerated to travel even farther.
Keep in mind that systems with P82B96 chips will come in pairs, as shown above. This pairing is necessary to take the boosted I²C signal from one chip and re-encode as conventional I²C with a bus voltage that’s sane enough for our remaining I²C devices.
Differential Bus Buffers
While some bus buffers simply boost the voltages of the I²C bus, others re-encode it as a differential signal. The PCA9615 does just that. It encodes the SDA and SCL lines into two split differential pairs. Differential pairs are one step short of magic. By sending equal-and-opposite signals over two wires spaced closely together, we make the signal far more noise immune than simply by boosting the voltage. (More on differential signals and the PCA9615 in an upcoming post!)
Of all the solutions so far, this one’s my personal fave. Not only do we get all of the noise immunity benefits of differential signals, we also don’t sacrifice the main benefit of I²C: that it is a shared bus and, hence, only a small number of wires. On that note, this chip also supports a multidrop configuration, making it a true off-board extension of the protocol.
In the diagram above, the large bounding boxes reflect multiple PCBs–each of which is connected at arbitrary points along the same cable. By far, my best bet at taking this diagram and turning it into real components was to start with ribbon cable and simply crimp connectors along the cable like so. (Those cable lengths, however, can span a few meters without any problems.)
With typical bus buffers, sending a boosted signal across a ribbon cable would still introduce the possibility of EMI in the noisiest environments. With a differential signal, that’s no issue, provided that each pair is closely spaced together on the cable.
As opposed to the prior solutions, each node that connects to this setup has the same topology, just one PCA9615 per drop. There’s one exception, though. The final drop needs to have termination resistors that complete the differential pair topology.
Years ago, running high speed signals over long wires may have been a huge headache. Nowadays, there are boatloads of ICs ready to give us a jump start in this realm. Those drop-in solutions may have have been the toils of our predecessors, so I cited the main application notes at the bottom of this article. Nowadays, in my mind, running I²C over long cables is a solved problem. If we follow the recommended guidelines, we’ll be well on our way to implementing an out-of-the-box solution that “just works.”
Join us in the coming weeks as we look into specific implementations that tackle these problems in gritty detail. Until then, cheers!