Understanding data transmission rates over copper wire

Question

I've been researching the different ways to connect sensors to an Arduino, and i2c seems to be a popular method. I've read that it's only reliable at short distances (a few metres, at most), with a data rate of 400 or 100kbps. I'm having a hard time understanding why the limits of this protocol are so low in comparison to other data transmissions over copper, such as gigabit Ethernet. I've seen reasons like capacitance, voltage drop, and resistance given, but isn't Ethernet over cat5/6 subject to all those same issues? Basically, I want to know why pulsing some voltage down some copper wire doesn't yield more consistent results (bandwidth, distance) when comparing these different methodologies.

Answer 1

Shannon's Theorem sets the ultimate limit of information bandwidth on a cable. Here's some more info about that: https://www.gaussianwaves.com/2008/04/channel-capacity/

tl; dr version: the Shannon-Hartley Equation:

• \$ C = B \; log_2 \left( 1 + \frac{S}{N}\right) \$

Where \$B\$ is bandwidth in Hz, \$\frac{S}{N}\$ is the signal-to-noise ratio.

I2C obviously isn't anywhere near the Shannon limit for a cable. Instead, it is a lightweight protocol with intentionally-slow timing (100/400 kbit/s) using an open-collector bus to make it easy to implement for a network of small devices with modest I/O and control needs. The slow operation specified by I2C avoids most signal integrity issues.

There are faster variants of I2C that use 1 Mbit and 3.2 Mbit/s rates. These require more attention to layout and termination than normal I2C and of course have tighter, more demanding timing.

Moving up the food chain Shannon-wise, Gbit Ethernet uses multiple techniques to achieve its throughput:

• Differential signalling
• Multiple pairs (4)
• Multi-level signalling, called PAM-5
• Preemphasis / Deemphasis
• Adaptive Equalization

These techniques take a lot of silicon, including a fast, large mixed-signal ADC/DAC block to talk to the cable and some fairly heavy signal processing to manage it. Add to this, the much more-complex software stack to drive it. This makes Ethernet as an on-chip block a bit much for a low-end microcontroller (some of which opt to use an external PHY instead). Its maturity however places it well within the reach of larger Systems-on-Chip.

How close are we getting to the Shannon limit, anyway? More here: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf

Answer 2

There's more to transmission than just the copper cable. Have you seen the hardware behind ethernet? Probably not, because it's extremely difficult to find any base-level circuitry for what is actually going on since the guts are always hidden away in an IC. The closest I have ever found is the magnetics required for ethernet, which are apparently not optional. That's just a hint of what's going on physically with ethernet hardware.

Think about it this way: Air is a medium. Why is the type of information that can be conveyed when dogs talk to each other so much less than when humans talk to each other? Why does sending some pressure waves through the air not yield more consistent results in the communication between these two types of animals?

Just some of the limiting factors for I2C (and many other protocols) are:

1. open-collector drive
2. no impedance matching
3. no balanced transmission
4. no error checking
5. simple encoding scheme
6. relatively high voltage levels (if your voltage step doesn't have to be as large you can transmit faster because your dV/dT doesn't have to be as high for higher speeds)
7. no isolation
8. unipolar voltages (ethernet transmits at +/- 2.5V which probably helps somehow)
9. The slave's transmission is clocked by the master so basically the clock has to do a round trip faster than the data signal

All of these are good for making things simple. Not so good for high data rates or long distance transmission.

There's also probably some other voodoo going on in the hardware that I don't know about.

Answer 3

A few simple rules of thumb: There is no such thing as ground. All wires are antennas. All wires are transmission lines. There is always noise.

If a wire is short compared to the signal rise time, then you get to ignore transmission line impedance mismatches and reflections (unlike Ethernet, which requires complex terminations and pulse shaping). If the wire is long, then induced voltages on the wire and ground differentials are more likely to make your digital signal levels at the far end indeterminate or incorrect. But Ethernet uses twisted pair differential signaling, greatly reducing the induced noise and ground reference problems. The Ethernet receiver also uses more sensitive analog inputs rather than typical digital inputs, thus allowing more line loss. Add to that Ethernet's coding and error correction to overcome the statistics of noise, and you can more reliably go faster and farther.

Answer 4

I2C is an open drain bus, it is actively pulled low, but the pull up (at least for the normal 100kHz, 400kHz variants) are passive resistors.

Because of this there is a limit on how quickly the thing can work based on how quickly the pull up resistors can charge the bus capacitance, you can sometimes get some more speed by lowering the pull up values but that then means the nodes need to sink more current to get a logic low.... Or you can go the other way, slow down the bus to allow the use of higher value pull up resistors for lower power dissipation (see for example PM bus).

It is instructive to fire up a scope and note that the falling edge on I2C is MUCH sharper then the rising one.

For the intended use, basically temperature sensors and small configuration devices within a single board (or at most a single chassis) this turns out to pretty much hit the sweet spot between implementation complexity, low pin count and simple hardware. The design intent was not "Fast, long distance data links", and for all that I find SPI to be generally easier to deal with, I2C fits its intended use case really quite well.

Once distances increase then something else becomes a better fit, but on a board with modest eeprom/temperature/device configuration interfaces, it does reasonably well (Worth noting that the PHY management interface looks a LOT like I2C).

Answer 5

The different results are because the driver circuit is different for each technology.

100kHz I2C typically uses a pullup resistor to put the signal at a high level, and open-drain drivers to put the signal at a low level.

The pullup resistors are typically several kilo-ohms. The longer a cable gets the more capacitance it will have. The time it takes the line to transition from 0 to 1 will be proportional to the total capacitance on the line and the pullup resistor value. Somewhere in the range of about T = 2*R*C would be about right.

For example if you had a 10 foot cable that had 20pF per foot of capacitance and you used a 10K pullup resistor then it would take T = 2 * 20pF/ft * 10 ft * 10K = 3.6us to transition from low to high.

In this case you obviously you couldn't have any one bits following a zero bit that were less than 3.6us wide, so your transmission rate would be limited to 277kHz.

In a real I2C system the I2C specification further mandates setup and hold times around data and clock transitions. Those times are either hundreds of nanoseconds or microseconds. The timing was made very slow on purpose so that the devices could be implemented cheaply (pennies), and consume very little power (milliwatts).

Ethernet on the other hand can run faster despite cable capacitance because it doesn't use a pullup resistor. It actively drives either high or low into the cable. The driver is low impedance and it can charge up any line capacitance very quickly. Of course that all comes a price. Ethernet typically consumes hundreds of mW of power, and costs at least a few dollars per port to implement.

Could a setup similar to I2C run faster, sure, just change the 10K pullup to 100 ohms and now your rise time into 10ft of cable drops from 3.6us to 36ns. You could then probably run at around 10MHz without too many problems (other than the fact that regular I2C chips can't talk that fast).