Sending I2C reliabily over Cat5 cables

Question

I am considering implmenting an home automation system around my Raspberry Pi but I found the price and space requirement of inserting a Pi every place some control is required too much but the Cat5e cables required for this design is already installed during renovation. I have some PCF8574's, PCF8591's and SSRs lying around so is it possible to drive them using Cat5e cables?

All my Cat5e cables are already wired with TIA/EIA 568B pinout. They are part of my structural cabling and are not shielded, so higher line voltage is required. I am thinking sending power and I2C lines over the cable, with this pinout:

Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +12V
Pin 5 (Pair 3): +12V
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): GND

The power pin arrangement is same as 100BASE-TX PoE wiring so power rating will be the same too, and using of bidirectional differential signaling is found in 1000BASE-T which requires Cat5e.

Original I2C SCL and SDA lines are derived into two bidirectional differential pairs at TTL levels (the open-drain is not kept on the wire, but restored in the line termination/level shifting device that I am designing)

Any suggestion on that? Also, which chip should I use to convert I2C lines to the differential signalling? Please suggest chips with DIP through-hole option to me. I do not know how to handle SMT stuff.

EDIT

I found this chip, SN65LBC180, is it a good choice? How to wire it into a bidirectional unit? How to shift level (it is a BiCMOS part requiring TTL level but Pi drives at 3.3v CMOS levels) and make it open-drain-compatible?

EDIT 2

Commenters suggested RS-485 which appeared acceptable to me, but still the two differential pairs are required to be bidirectional and only two bidirectional differential pairs only. I am repurposing existing Ethernet cables.

EDIT 3

Since someone brought it up, I cannot use CAN. There is no way I can fit CAN onto RPi without sacrificing anything (SPI is occupied by a touchscreen, so no SPI to CAN converter)

I am aware of the limitation of I2C PHY so I am essentially trying to fit 1000BASE-T PHY to it - bidirectional differential signaling for SCL and SDA signals, but on top of that runs I2C protocol.

EDIT 4

A new chip came to me: NXP P82B96 which splits I2C into 4 unidirectional lines, which in turn can be used to feed into SN65LBC180 through opto-isolation (Pi-side only) to form a 8-pin long-distance-ready signaling. Now I just need to figure out how to get power through the wire, or how to determine if the bus is sending and make the pairs bidirectional.

EDIT 5

From the suggestions of answers, I think I need to change the power pinout a little:

Pin 1 (Pair 1): SCL+
Pin 2 (Pair 1): SCL-
Pin 3 (Pair 2): SDA+
Pin 4 (Pair 3): +5V
Pin 5 (Pair 3): GND
Pin 6 (Pair 2): SDA-
Pin 7 (Pair 4): GND
Pin 8 (Pair 4): +12V

I2C differential signaling voltage is TTL. The +5V over pair 3 comes from the Pi, unbuffered but fused. The +12V over pair 4 may not be present is only used to drive some high-power devices. If needed the device may use its own power supply and leave both rails hanging unconnected or supply its own higher voltage but use the 5V rail.

SCRATCH THAT

Pinout is still my original design, which is 802.1af compatible.

Answer 1

Trying to do with with IIC is a bad idea. IIC is really meant for communication between chips on a single board. Since the maximum required current to pull a line low is limited, the lines are relatively high impedance (a few kΩ). This means they can pick up noise easily, which is a serious issue when running in unshielded cable in the walls possibly right next AC power wires.

I would use CAN for this. CAN uses a single twisted pair pulled together with only 60 Ω at any one point, and the signal is differential. That means most of the inevitable common mode noise that will be picked up due to capacitive coupling can be cancelled by receivers. CAN running at 500 kbits/s can cover something the size of a ordinary house.

Many microcontrollers are available today with CAN built in. You usually need a separate physical tranceiver chip (like the common MCP2551), but the lowest few layers of the protocol are implemented in silicon in the CAN peripheral. The firmware interacts with the CAN bus at the level of sending and receiving complete packets. The collision detection and retry, checksum generation, details of the bus packet signalling, received checksum validation, and clock drift adjustment are all handled for you.

Don't fall for RS-485. That's a relic from a bygone era. It also uses a single differential signal like CAN, so also has good noise immunity. However, people usually fall for RS-485 because it looks "simpler". This is only because they don't look at the whole system. First, it's not really any less complex electrically. You will still need some kind of transciever to drive and receive the differential signal. Whether you have a RS-485 transceiver connected to the microcontroller's UART, or a MCP2551 connected to the CAN peripheral is pretty much irrelevant in terms of cost and hardware complexity. The big difference is that RS-485 leaves you at the raw byte level (via the UART). This means to implement any meaningful and robust system, you have to invent your own protocol to handle collision detection, decide how to handle retries, packetization, checksum generation and checking, flow control, etc. You can use a single master architecture, but getting the details right is a lot more tricky than people think that haven't analyzed all of them carefully. With CAN you just send and receive packets, and the hardware takes care of the details.

Answer 2

I2C is not the way to go. CAN trancievers cost a dollar each, and you can use them as uart trancieves and write your own protocol so you dont need a can compatible micro of you dont want to use the full can stack.

I always feel a little uncomfortable when I see cat5 conductors run in paralel for more current. It bugs me because if one conductor breaks the other will carry full system current. The cat5 current ratings are very conservative so the odds of a fire are fairly low but I just dont like the possibility.

The safe way to do it is to have a polyfuse on both power rails and join the grounds at the supply, and connect each device to one and only one set of power/ground. That way if one wire fails, the devices using that line lose power instead of one line being forced to carry the power of two.

A lot of people like to put power and ground in both twisted pairs for EMI reasons instead of having one power pair and one ground pair. If you have two power/ground pairs the power line will be closer to ground, and the fields will cancel out, reducing any transmitted or recieved radio waves from the power lines. Unnecessary, but nice if there is lots of electrical noise humming about.

12V in my opinion is too low for power distribution when 24v is still reasonably safe and much more efficient.

Answer 3

If the automation is simply turning things around the house on and off, I would simplify this by:

• Keeping all the "brains" in one place. Use I2C I/O expanders if needed, but keep them all with the raspberry pi. You'll also need appropriate hardware to make sure you aren't trying to get too much current from the pi's GPIO pins.
• Use the ethernet cables to simply drive relays. You can build your own board, or get panel mountable 120/240V solid state relays that will mount in an electrical box. The wires in Cat5 ethernet cables can handle up to 50V at 320mA each, which is more than enough to drive a relay. In fact, you could drive 7 relays from a single cable (plus one wire for ground). Or leave one wire for an unswitch 12V output, so you can install a manual switch as well. If they are really long runs, you may have to account for voltage drop, but you can get relays that will switch at 3-32V. 12V should be more than enough, even with voltage drop.
• You will also want to consult local building codes for advice about mixing high and low voltage cabling in the same box.
• Simple switches can also be done through the ethernet cables, again up to 7 per cable, and simply wired to the pi's inputs. Voltage drop may be a concern for really long cables.
• You may also want to use optoisolators to protect the pi from damage.
• For the few devices that need more than a relay (like a control panel) use the ethernet cables as actual ethernet. It shouldn't be a huge expense if there aren't many of these devices. They could either be another pi, or a microcontroller with ethernet.

Answer 4

^{simulate this circuit – Schematic created using CircuitLab}

EUREKA! Figured it out! (untested, will test it out this weekend)

The interface chips are NXP P82B96 I2C buffer/splitter and 2 TI SN65HVD251P CAN bus interface chips. Essentially, I am running I2C on CAN PHY.

P82B96 understands I2C protocol and handles bus arbitration for me, and gives me separate Tx and Rx pins that can be tied together. I feed those into SN65HVD251P CAN transceiver and it gives me the bidirectional differential pair to send over wires.

Power pins comes directly, unbuffered from my Pi's 5V rail. (I will not use 12V signaling voltage and power for a while)

Answer 5

Regardless of the merits of IIC at the chip level, your proposed implementation is going to be very difficult. The problem is bus arbitration. Although multiple units can be paralleled using, for instance, RS485, the big question will be:

How does any unit know whether it can take control of the bus in order to send data?

In IIC, with open drain signal lines, bidirectional transfer is easy - but with tristate busses you need some way to ensure that only one unit attempts to drive the bus at a time. This will be tricky. You can do it, particularly if you establish a single master and require that all the slaves have rigid timing constraints on sending data, and that they only send data if requested by the master, but this will require considerable effort on your part in designing the interface boards for the master and the slaves.

As for physical drivers/receivers, RS485 will do you fine, and there are lots of interface chips available. Just Google.

Answer 6

I don't know if you're interested in a premade solution as opposed building your own circuit, but I thought I'd point out that Pololu sells these I²C Long Distance Differential Extender boards made by SJTbits, which seem to do pretty much exactly what you're looking for. (Full disclosure: I work for Pololu.)

Even if you don't want to use it directly, maybe looking at the circuit it uses might give you some ideas. You can see the schematic in the datasheet; it uses an NXP PCA9600D buffer, TI AM26LS31CDR differential line driver, and TI AM26LS32ACDR differential line receiver.

Answer 7

I know this is a bit old and a solution seems to have been settled on somewhere amongst the replies, but I had this suggestion to offer. There are devices like the PCA9614/5/6 from NXP that I'm looking at right now as a solution for a more robust long distance I2C bus (PCA9614 2-channel multipoint Fast-mode Plus differential I2C-bus buffer). Esentially it's true that it's becoming something other than true I2C, but at the ends of the bus it's invisible to the devices. This particular family translates the signals into 2 bidirectional differential pairs, and there are also similar devices as have been already mentioned in the comments, that translate to 4 unidirectional differential pairs. Translating to just 2 pairs allows you to use CAT cable and still have 2 pairs for power/ground.

Answer 8

Thumbs up! I'm currently trying to solve pretty much the same problem. I'm also trying to use I2C over cat5 for home automation with my custom pinout. The reason is cost, I want it be very cost effective and I2C components still at least 5 times cheaper than even attiny13 uC (AFAIU uC is required for CAN and RS485).

1) Currently I am just in a process of trial for the first part of a system and now I'm succeed with 15m long cable with 5V and dirrect SCL&SDA connection! I use PCF8574 and 2 relays to trigger my room lights. Pinout is

1
2 INT
3 +5V
4 SCL
5 SDA
6 GND
7
8

2) I do understand that it will not afford a couple more relays or an extra 10 meters... A voltage drop is significant (from 5.5 to 4.7). So for the voltage drop problem I'm going to put 12V on a line instead and add 5V voltage regulators on boards to keep fine voltage everywhere regardless of entire line drop. I'll put additional power supplies during the future lines anyway.

3) The signal itself can be improved using P82B96 or cheap P82B715 without splitting to differential lines. An NXP itself uses Cat5 in some presentations but I can't find their pinout. An important part here is that they clearly use signal lines in different pairs... e.g. one pair is GND+SDA the other is VCC+SCL.

4) Another interesting point - this buffers can simply raise an amplitude up to 12V to increase noise resistance. So, I'll probably try to put 12V on on a signal lines too and that should allow to put a pullups dirrectly from 12V wire... But that will force me put something like P82B96 on each device.

As you may noticed, I also use separate interrupt line... Master is currently on arduino board connected to PC. The primary master software will be on a 24x7 PC anyway, so arduino just translates signal and handles interrupt. I can send specific configuration for onboard interrupt handling e.g. to handle convenient switch toggle via interrupt... That allows me forget about any delays when toggling light manually. Interrupt handling is additional advantage of i2c.

So my idea is that I2C is simple enough to be applicable in <=100m city apartment cabling. Instead of going to differential signal I hope I'll able to reduce extra frequency instead.

I like your idea to put both 5V and 12V since this reduces need in regulators and reduces cost... the whole idea of multi-wire bus it to reduce cost of endpoints, I'll also consider this for new pinout :)