Multiple slaves over 12 Meters, I2C or something else?

[Volta500]

Hello all,
Im working on a hoe automation project, in wich I need to connect about 4 PIC slaves over a maximum distance of 12 meters,. They will be controlling a RGB LED and various inputs, so it must be duplex and have a good data rate. Im planning on using CAT6 Ethernet cable for shielding reasons and to have plenty of conductors. Master will be a powerfull PIC32. Slaves a PIC16 of some description. Most likely a PIC16F1825.

Now my question is, would I2C do the business here, or will there be to much noise on the line so that the last node will only receive garbage? For expansion reasons with the chip select wires I do not want to use SPI, but UART is an option. Although that would give the problem on how to connect multiple slaves on one UART. The most data will be the fading the LEDs, and the slaves rarely transmit something so the chance of a bus collision is small, but it is not a very 'clean' solution.  An other solution would be to use a slave controller with two UART modules, and have every slave transmit everything it recieves. Having a separate line to the master is not an option.

Got any insights on how to solve this cleanly and reliably?

[SeanB]

RS422 would be an option using the UART. Multiple slaves and a master to poll them. Uses the UART and only a bus transceiver on each unit to make it work. Works reliably with noise and will easily handle the range that you want. Just needs a terminator at each end of the line for reliable operation.

[Kjelt]

RS485 have a look at the elektor bus design 
If you would like to make your own life easier, create a protocol with SRC adress, DEST adress (use unique addresses), Command.
Make commands with and without reply and create commands that create, dissolve and address groups to address multiple lamps at once.
Use only one master and let the slaves only answer on masters request commands. Works perfectly in my home for a lighting system.

[Maxlor]

I2C won't work well at that scale. You'll have to use low speeds and small pull-up resistor values to get usable signal flanks. It might just work with shielded cables.

However, I also think that using a differential signal is the best option here. Besides building something with RS485, you might also try CAN bus. In either case you'll be able to use much cheaper and thinner cables than CAT6.

[hans]

The problem with long wires on I2C (also 1-wire) is too great capacitance. The pull-up resistor would need to charge up 'the line'. That takes time, which may be too long for a good edge to be detected.
That means:
- Decrease the value, until your MCU pins can handle no more
- Lower the clock rate/increase duty cycle, so the edges have time to recover.

12 meters may not be long fetched if you severely limit the transmission rate. Maybe at 1kHz it may work fine, but above that it gives problems.

I would look at something like RS485 as its designed for long distance communication in a bus. Have each node an assigned address, and you pretty easily work out a protocol without collisions.
If commands don't require a response, it's even simpler.

CAN is a nice system , as it has accommodations for priority, packet ID's and a good bitrate (250kb/s at reasonable distances), but it's not implemented on a simple PIC16 chip. I think you even need quite a big PIC18 or dsPIC33 to even find onboard CAN modules, which also require a separate CAN transceiver.
Not very practical if you want a minimalistic/low-cost system.

Also it may be useful to have an estimation of how many packets/s you want to send to each node, how many nodes there are, and how many bytes you expect those packets to take.
If you want to update all 12 nodes at 50Hz and require 8 bytes per packet, that's 4800 bytes/s (38400b/s). With a baud rate of 57600 that would just about do that, but wouldn't have much left.

[headroom]

12m can be done with I2C. My own LED lights http://trippylighting.com use about 4.5m of CAT5 cable and a PCA9600 I2C buffer in the basic multi point configuration.
The LED driver boards I am using http://ledshield.wordpress.com use all FM+ capable chips. So only one PCA9600 is needed on the processor side ( Teensy 3, ARM Cortex M4 )If your I2C slaves are only good up to 100KHz or 400KHz I2C bus speed they are likely not FM+ capable and then you'd need a PCA9600 on each slave too. This stuff is very inexpensive though.

I tried to find the limits of my set-up and tested this on 5m of CAT1 cable and only one LED driver board ( so only 3 I2C devices on the bus ) and signals still looked very crisp at 1.5MHz (yes MHz, not KHz).
If your I2C slaves are FM+ capable then the only extra thing that is needed is a small BAT54a Schottky diode. All supplemented with proper pull-up resistors of course.

I don't have any boards on hand right now, but if you're interested I can post the Eagle layouts. I am using standard Ethernet cable with connectors and inexpensive Amphenol  Ethernet Sockets on the connector boards http://trippylighting.files.wordpress.com/2013/10/img_2392_small.jpg

[headroom]

As you are connecting PiC or PiC you'll likely need a PCA9600 on each pic. In TSSOP8 package it costs less than $2 a piece. Schematic and layout are really simple and only a BAT54a Schottky diode a bypass cap an 4 pullup resistors are needed per board and if you choose to do so, one to two Ethernet sockets. And, of course you need a less than 1 square inch PCB. That's max $6 material cost per I2C node.

The system that is hanging on my wall right now works at 100KHz I2C bus frequency over 4.5m of flat CAT5 Ethernet cable without any added electronics. There are 11 I2C devices on the bus. Just plain I2C and proper pull-up resistors, 1.8k in this installation.

[Kjelt]

I2C was designed for on a pcb board. Not for long distances off board.
If you are designing a new system (and not expanding an existing one with legacy) I would never, ever recommend I2C for this pupose.
There are specific protocols and hw for long distance communication, RS485, IP being some.
For light control there are specific long distance systems like DMX/DALI/KNX.

[nctnico]

Even though I2C isn't intended initially for long distances there are several chips to overcome this limit. To me it seems a perfect solution to avoid the overhead from implementing a communication protocol.

[kripton2035]

for such a distance I would use ethernet. enc28j60 are easy to find and cheap and you can go to 100m or so with ethernet.
you can even send orders from the other side of the world ...

[mikeselectricstuff]

I2C no good over that distance. OK you may get it to work but it's just the wrong way to go about it. RS485 or 422 is the easiest and cheapest for high speed over distance, though TTL or RS232 UART will work over that sort of distance at low to medium baudrates.
Ethernet is WAY more complicated and expensive than RS485, which can do 10mbits over 100m and lower rates over longer distances.

[nctnico]

The PCA9600 is specified to work up with distances to 20 meters at 1MHz. I wouldn't call that short or slow. The biggest challenge is to keep ground noise low. That is also an issue with RS485. Although the signals are differential they are still referenced to ground. Unless RS485 is used with isolation transformers but that would need differential coding as well.

[headroom]

I2C is good over the distance and would work for the application the OP posted. My schematics and circuitry follow the Data sheet for the PCA9600 and it works as specified and verified by measurements and proven in an actual application over a 2 1/2 year period of continuous operation without a glitch.

Furthermore the application is very close in aim to the OPs intended application, the fading of RGB LEDs. I woud, assume that as my LED drivers have no own processing power other than a 12-bit PWM chip that the data transfer rate is a good bit higher than needed in the OPs system. 100KHz should be fine!

While it is correct that I2C was not initially developed for such use cases, there is a whole host of literature including detailed data sheets for a variety of I2C buffer chips and application papers available online for everyone to read that explain in detail.

The reason for the existence of these buffer chips is rather obvious. There are a large number of I2C components available, it is easy to implement and if any other peripheral Electronics are needed such as I2C buffers they are inexpensive and readily available. And, of course one does not need to worry about another bus protocol.

The problem with I2C over long distances is due to overall system capacitance and the needed current to discharge that capacitance. The FM+ spec addresses this by allowing 30mA vs. 3mA and 4000pF vs. 400mS. That allows for more devices or longer wires, or more devices.

That of course does not mean that it would not work with RS485. I have no practical experience with RS485 and as such will refrain from statements about it's viability in a given application.

[mikeselectricstuff]

The PCA9600 is specified to work up with distances to 20 meters at 1MHz. I wouldn't call that short or slow. The biggest challenge is to keep ground noise low. That is also an issue with RS485. Although the signals are differential they are still referenced to ground. Unless RS485 is used with isolation transformers but that would need differential coding as well.

RS485 has good resistance to ground noise, and there are several isolated RS485 solutions, including one form AD that includes the isolator and dc/dc in a SO20 package (ADM2582 I think).
For one-way links there are the passive input isolators from NVE - these need no ground reference or isolated supply on the  receive side.
RS485 transceivers are also designed to not drag the bus down if not powered.

 

[headroom]

I've read over the OPs initial post again and educated myself a little bit about RS485. As he is going to connect PIC to PIC, RS485 is better and more robust than I2C.

My system connects a Processor (Arm Cortex M4) directly to I2C chips (LED drivers) that don't have any own processing power to deal with another protocol. So using I2C is a compromise of economics and complexity.

That's not the case on the OPs system where plenty of processing power is available on the slaves and master. Both methods require a little bit of additional hardware to bridge the distance.

[nctnico]

Don't underestimate the complexity of implementing a protocol over RS485 though. Especially with multiple masters (been there, done that). Even with a single master each slave must have processing time to listen to messages and reply to them. And then there are fault conditions like corrupted messages, a slave not replying. I2C and ethernet handle a lot of the complexity in hardware. Just look at the fault conditions and recovery methods of I2C.

[PioB]

Check out the P82B715.

Sent from my GT-I9300 using Tapatalk

[zapta]

You can use linbus with transceivers like ata6663 (there are many others, even from microchip).  It is intended for up to ~20kbaud and 40 meters in noisy environments. It requires only a single wire + ground and power. You can use the actual lin protocol and make up your own.

[mikeselectricstuff]

Don't underestimate the complexity of implementing a protocol over RS485 though. Especially with multiple masters (been there, done that). Even with a single master each slave must have processing time to listen to messages and reply to them. And then there are fault conditions like corrupted messages, a slave not replying. I2C and ethernet handle a lot of the complexity in hardware. Just look at the fault conditions and recovery methods of I2C.

I don't think 485 is any more complex in most cases, and can be simpler. the differential signalling makes the underlying transport  inherently pretty rugged (as long as it's wired correctly - one open line on 485 can be fun to debug) Though I2C has some support for multimaster etc., all that stuff needs to be implemented in firmware. Probably the only differnce is you don't get any explicit collision signal from 485, but that's only an issue on multimaster setups.
Ethernet has a lot more inbuilt stuff, mostly dealt with in hardware but is much more complex and expensive, so not really comparing like with like.
For a unidirectional link, using 422/485 is pretty much a no-brainer. I2C is just not the right tool for the job unless there are some unusual requirements.   

[fcb]

I2C will work over 12M - but you'll have to slow it down alot and watch the grounding.  It isn't ideal.  But you can make a small number of dumb slave units without much work.

CANBUS would work, and it's a nice protocol - but over-engineered somewhat for what you want.

RS485 is brilliant electrical specification, and that's what I would look if it had to be a wired solution.

I guess you are also supplying power down the CAT6 wire?

[headroom]

Slow down from what ?

We established already that on 12m CAT6 you'd have to use an I2C buffer chip such as the PCA9600. Would easily do 12m at 100KHz probably even 400KHz.

Aside from that 485 is likely the better tool for this application.


Sent from my iPad using Tapatalk HD

[C]

While I like RS485 it does bring back thoughts of the bad old days of 10base2 where you had to play by it's it rules. Want to add a new node the network most likely had to come down. Have a problem on that long bus and it could be a lot of pain to find the problem area.

What says that you have to use a CAN buss driver chip on a CAN buss controller. If you look the difference between a CAN buss driver chip and a RS485 driver chip you see two things. The Can buss driver chip has no transmitter enable pin. The CAN buss driver chip uses resistor pull up outputs in place of the RS485's totem pole output. Now the CAN buss resistor pull up can not be as fast as the RS485's totem pole output but there are CAN buss drivers that reach 1 Mb for a distance. Using CAN buss drivers does let you have repeaters and Hubs like on 10baseT so you do not have to have one long buss, you can easily have many shorter buses connected by repeaters or hubs. A CAN buss repeater is nothing more then two back to back CAN buss driver chips. A hub could be just a bunch of repeaters all connected to a short CAN buss section. Granted there are limits to how many of these you can have just like there were limits on 10baseT hubs.
So there are some easy options if you can use a CAN buss driver chip in place of RS485.
Now as this is for home automation where you have different events that can have a different priority it makes more sense to me to use a mpu that has a CAN buss controller built in and gain the rest of the benefits that the CAN buss controller can offer.

Granted you could make RS485 hub like by using one pair out to a device and a second pair back. You can do this also with CAN buss if you want. An RJ31 jack would make this easy.

If there are problems with speed for the RGB led's you could use RS485 for just that part of the problem while using can buss for the rest of the network.

Both will need some software. For CAN bus you might get some ideas from
http://www.merg.org.uk/merg_resources/cbus.php

C

       

[Kjelt]

CAN bus is a good alternative I agree but has some disadvantages why I my self did not go that way:
1) More expensive, external CAN bus drivers are more expensive then RS485 drivers
2) steeper learning curve: you need to study CAN protocols, collissions etc.

I had no use for multi master or collisions.

If you want a MCU with integrated CAN bus driver/peripheral be aware that these MCU's might not be around in the next 10 years, so for a home automation project I always choose components that will be and are available for a long time. Almost all RS485 drivers are made by multiple firms and the 8 pins chips are 90%pincompatible.
But still if you have the time/interest/components CAN looks very nice and would probably do a very good job.

[Psi]

i've had ATTinys working in a 1 master/8 slaves relationship all communicating serially over SPI with differential drivers. 

Total distance was about 160meters with the master in the center, so max 80m between the master and any slave. (Physically it was a master with two 80meter cable runs).
Because of the shift-register style of SPI it required some creative fun protocol coding but did work fine, although i only needed like 9600 baud

Of course I wouldn't recommend it, it was more for lolz.
And because i wanted to use parts i had instead of buying new stuff.

[nctnico]

One of my customers used a voltage/current modulation scheme (like Opentherm) for two way communication over distances up to 200 meters. IIRC they used some kind of NRZ coding. I re-designed the analog part of it to make it more robust though.