2
\$\begingroup\$

I'm planning on interfacing with some sensor devices via I2C over a long bus, with devices chained every 2m or so, up to 16m in total. I've seen other questions here referring to this from the "which protocol should I use?" angle, but I'm more interested in the actual wiring.

My main requirements are:

  • The cabling must be something that a non-technical person can acquire from a general retailer like Amazon or eBay. Preferably something obvious and well-known like USB, CAT5, or S-Video.
  • Connectors should be as cheap as possible - I'm trying to make the individual sensor boards as low-cost as possible.
  • Maximum stability, if possible.
  • Trying to avoid adding extra parts, so cases where I need things like differential line drivers should be avoided if possible.

The devices will probably run on 5V logic.

Is there an ideal cabling type for this kind of thing?

\$\endgroup\$
10
  • 2
    \$\begingroup\$ 2m isn't so bad, but I wonder if you can get I2C buffer chips on each device which will separate the chain into just 2m chunks with full driver buffering at each step? \$\endgroup\$
    – KyranF
    Commented Mar 4, 2015 at 17:35
  • 1
    \$\begingroup\$ and in this situation i'd use CAT5 ethernet or telephone wire \$\endgroup\$
    – KyranF
    Commented Mar 4, 2015 at 17:36
  • \$\begingroup\$ Your choice of I2C has consequences. If I wanted this to be realy low-cost I would first look at cheaply available cables/connectors, then at a cheaply implementable protocol. CAt5 wiring including connectors is chepa, but I would not choose I2C an optimal cheap/reliable protocol for such distances. \$\endgroup\$ Commented Mar 4, 2015 at 18:09
  • 1
    \$\begingroup\$ @WoutervanOoijen Unfortunately my only two choices for the sensor are I2C and SPI, and the latter would require 13 wires due to the long-range. Translating to alternative protocols is a pain due to requiring additional components, increasing the cost per board. \$\endgroup\$
    – Polynomial
    Commented Mar 4, 2015 at 18:28
  • 1
    \$\begingroup\$ @polynomial What are you trying to sense that only I2C and SPI are available, and how do you know that a uC on each board is more expensive than other solations when you don't yet know the other solutions? For instance, a small uC is cheaper than am I2C buffer. In systems design you should not make 'small' choices first: get the overall picture for all alternatives, then you can decide. \$\endgroup\$ Commented Mar 4, 2015 at 19:43

2 Answers 2

2
\$\begingroup\$

I2C is in some ways a very neat protocol, but its design purpose is to interconnect devices on a single board. Even beyond issues of signalling levels, there are some protocol issues as well which may pose problems when using it for multi-board communications.

For example, suppose that two slave devices are connected that would both allow a master to read an arbitrary number of bytes, and which may return zero for an arbitrary number of those bytes. If while one device is sending data to the master a second device mistakenly interprets part of the data as a "START" sequence followed by its read address, it would be possible that for every clock cycle thereafter at least one of the devices would be wanting to output a "0" data bit. Such a scenario would make it impossible for the master to ever regain control of the bus. While it's possible to design single-board communications such that stray pulses "just won't happen", that's often not feasible when connecting many devices. One may try to minimize the likelihood of stray pulses occurring, but should not expect to avoid them totally. Having a sensor reading get corrupted once a month because of a stray pulse may be acceptable, but having the system lock up once a month would likely be less so.

If you're using a single-master setup, I would suggest that it may be worthwhile to use separate wires for SDA out to the slaves and SDA return. If the slaves are using handshaking, it may be worthwhile to do likewise for SCK. The master's output could then be driven actively high and low (rather than being actively driven low and passively pulled high). If the connectors had designated "in" and "out" sides, each board in the chain could "AND" the return from the previous device with the pin state of its own device, and output active high-and-low in the return direction as well. Such a design would likely require use of a bit-bang master rather than a hardware master, but given that software-master implementations can often manage better error recovery than hardware masters that shouldn't be much of a limitation.

In addition to the improved robustness resulting from active-high/active-low drive, using separate output/return wires for SDA will avoid the possibility of one slave device interfering with the master's attempts to get another device to shut up, since even if all but one slave device wanted to output low on SDA, the master would have no problem generating a low-to-high transition on the SDA pin of the last remaining slave.

If you don't want to use the extra wires to separate SDA out from SDA return, it would be possible to wire the slaves so that their pull-down strength on SDA was limited, and wire the master so that it could safely overpower the slaves. That would allow clean recovery in case of slave malfunction, but would not offer the signal-cleanliness advantages of using separate wires. Further, it would only work well if handshaking is not used. Robust I2C operation requires that transitions on SCK and SDA be separated by a time in excess of the worst case transmission skew. If the master is in sole control of SCK, it can ensure that. Slaves which use handshaking, however, may asynchronously generate events on SCK and SDA, with no way for the master to control their separation.

\$\endgroup\$
3
  • \$\begingroup\$ My preferred choice to avoid such a lock-up would be to have the master remove the power periodically or maybe upon detection of such a problem, or even at the start of each mesurement cycle. \$\endgroup\$ Commented Mar 4, 2015 at 19:45
  • \$\begingroup\$ @WoutervanOoijen: The suitability of such an approach may depend upon the nature of the sensors and what they're reporting. A rotation sensor, for example, may be expected to report the total distance a shaft has rotated; powering down such a sensor would make it lose any counts that occurred while it was off. Further, while non-handshake I2C can be made robust in a multi-drop configuration by having the master control relative SDA/SCK timing, most processor-controlled I2C slave implementations would require handshaking. \$\endgroup\$
    – supercat
    Commented Mar 4, 2015 at 19:55
  • \$\begingroup\$ Accepting this because it prompted me to read into the timing graphs and other solutions for long-distance buses. In the end it was possible to drop the bus speed to 50kHz or so and get a couple of meters reliably over USB cables as long as I had bidirectional logic level translators at each device to ensure that voltage drop didn't become a problem. In a later project I used bidirectional LVDS buffer ICs for better signal integrity, using CAT5 to carry the differential pairs. This can also be applied to SPI. \$\endgroup\$
    – Polynomial
    Commented May 11, 2017 at 10:11
1
\$\begingroup\$

Slide 68, page 25 from AN10216:

Sheet68

Although it's perhaps not ideal, this is what's recommended by Philips (my version of the document is from March 2003). Twisted-pair telephone cable.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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