Multiple slaves over 12 Meters, I2C or something else? - Page 1
Forum section: electronics / general

author: Volta500
author_rank: Contributor
timestamp: January 09, 2014, 03:01:43 pm
content: 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?

author: SeanB
author_rank: Super Contributor
timestamp: January 09, 2014, 03:18:43 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: January 09, 2014, 05:37:36 pm
content: RS485 have a look at the elektor bus designIf 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.

author: Maxlor
author_rank: Frequent Contributor
timestamp: January 09, 2014, 05:57:42 pm
content: 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.

author: hans
author_rank: Super Contributor
timestamp: January 10, 2014, 09:38:07 am
content: 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.

author: headroom
author_rank: Newbie
timestamp: January 11, 2014, 05:48:22 pm
content: 12m can be done with I2C. My own LED lightshttp://trippylighting.comuse about 4.5m of CAT5 cable and a PCA9600 I2C buffer in the basic multi point configuration.The LED driver boards I am usinghttp://ledshield.wordpress.comuse 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 boardshttp://trippylighting.files.wordpress.com/2013/10/img_2392_small.jpg

author: headroom
author_rank: Newbie
timestamp: January 11, 2014, 06:31:19 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: January 11, 2014, 07:30:43 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 11, 2014, 07:59:10 pm
content: 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.

author: kripton2035
author_rank: Super Contributor
timestamp: January 11, 2014, 08:01:49 pm
content: 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 ...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 11, 2014, 08:13:18 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 11, 2014, 08:59:13 pm
content: 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.

author: headroom
author_rank: Newbie
timestamp: January 11, 2014, 10:06:29 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 11, 2014, 11:03:02 pm
content: Quote from: nctnico on January 11, 2014, 08:59:13 pmRS485 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.

author: headroom
author_rank: Newbie
timestamp: January 13, 2014, 01:29:52 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 13, 2014, 03:10:53 pm
content: 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.

author: PioB
author_rank: Regular Contributor
timestamp: January 14, 2014, 04:20:16 pm
content: Check out the P82B715.Sent from my GT-I9300 using Tapatalk

author: zapta
author_rank: Super Contributor
timestamp: January 14, 2014, 04:50:30 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 14, 2014, 05:12:38 pm
content: Quote from: nctnico on January 13, 2014, 03:10:53 pmI 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.

author: fcb
author_rank: Super Contributor
timestamp: January 14, 2014, 05:50:15 pm
content: 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?

author: headroom
author_rank: Newbie
timestamp: January 16, 2014, 02:05:17 am
content: 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

author: C
author_rank: Super Contributor
timestamp: January 16, 2014, 03:22:43 am
content: 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 fromhttp://www.merg.org.uk/merg_resources/cbus.phpC

author: Kjelt
author_rank: Super Contributor
timestamp: January 16, 2014, 08:58:10 am
content: 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 drivers2) 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.

author: Psi
author_rank: Super Contributor
timestamp: January 16, 2014, 10:19:46 am
content: 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 somecreativefun protocol coding but did work fine, although i only needed like 9600 baudOf 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2014, 11:39:24 am
content: 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.

author: miceuz
author_rank: Frequent Contributor
timestamp: January 16, 2014, 12:18:10 pm
content: One thing I'm missing in this discussion is the point that CAN bus is a fairly high level protocol. You have lots of stuff already sorted out for you protocol-wise in CAN hardware (addressing, collisions, arbitration, whatnot) - you just use a CAN enabled micro and bam - you are receiving high level messages. Another way would be to use a SPI CAN hardware chip, I've seen Microchip has one to offer. This way you have a micro, SPI CAN translator and CAN hardware transceiver. TI Stellaris Launchpad had an ARM micro with CAN hardware inside, I'm not sure if the new iteration of this board has it. I've written a CAN bus sniffer for Stelaris, didn't post it anywhere yet, ping me if you want it for whatever reason.While RS485 is just a specification of an electrical level of the network. You have to write (or reuse) all high level protocol by yourself. For single master network Modbus can be attractive - robust, industrial use, there are loads of free libraries.I2C stands somewhere in the middle, but as others already noted - it's not meant to be used like this. I'd say it's better to do things properly adhering to world wide accepted standards even if it's just a hobby project. This way you learn a) new stuff b) proper engineering

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2014, 07:02:07 pm
content: Don't let feelings rule your world. Why would NXP make a chip which allows to bridge I2C over 20m at fairly high speeds? Farnell has more than 2000 pieces of the PCA9600 in stock and Digikey over 5000 so it is not a boutique part nobody is using.

author: C
author_rank: Super Contributor
timestamp: January 16, 2014, 07:26:58 pm
content: What may at first look good on paper may not work as well in practice. Very often the paper idea will forget about time as it takes time for a message to propagate down the cable.Using a satellite in a communications link may sound like a real good idea but the really great thing a satellite does it add a big time delay. It takes time to get up to the satellite and still more time to get back down from the satellite and there is nothing you can do to decrease this time delay. The same thing happens on any cable just to a lesser degree.If the idea is a master telling a node when to talk then you have an added a time delay. The smallest you can make this added delay is to put the master in the middle of the cable. Then you have the added delay for poling all the nodes that need to talk. You spend all day poling all the nodes and how ofter does that node with the switch attached need to say "My switch has changed".You could save some time and have one node tell the next to talk. You have just saved a bunch of time but now your master is really called a watch dog making sure the rotating talk keeps happening and you still have time delays. IBM token ring did this.You could do Ethernet like where you just talk when you think the bus is not busy but the nodes at each end have a great time separation so at some point the two will talk and the messages will overlap on the buss and garbage results.The bus puts things together with the added fun of a time delay being thrown in the process.Can bus via it's priority based sense on startup has a chance to have two messages start to happen at the same time and one survive the happening. When this fails and it will at times it has bits that will tell the other nodes that the message got clobbered. If you look at Can buss there is a way for a node to say "the message with an ID of ___ got clobbered here" and also a way to say "that last message got clobbered" when even the ID part was damaged.CAN's message ID with priority and short message lengths is great when you need to process events. This does not prevent longer messages from happening it just adds overhead.Think of this One,a node receives a Ethernet packet on one of it's interfaces. It could easily chop that Ethernet packet into the smaller packets and send it over can bus. A second node might be transmitting music via can bus packets. You have many nodes with switches and of course you have the important stuff like fire.Those Ethernet packets can easily push the bus to max. That music could take a large part of the bandwidth on the buss. But if you have the message ID's priority set correctly that fire message would over ride the switch message which could over ride the music message which could over ride the Ethernet packets. It still works.There are pic's and avr's with built in CAN controllers. But is it worth the high cost of using them? You might save a dollar or two per node at the cost of limited space and processing power for the future. Some nodes could really use the added processing power that an ARM micro adds. Also with ARM you can easily have both CAN and something using a RS485 buss. Actually you could have many of both. So I often wonder at the idea of starting off building something that will be limited at the start just to try to save a few dollars and then spend even more then you saved by adding a crippled add on to add in what the few dollars added at the start already had to start with.So looking at the OP's over all project. Right now I would probably start with a BeagleBone Black, Just this one board adds the display to a TV or Computer monitor. An Ethernet connection so that all the computers on the network could access it and/or have a web status page. If this Ethernet network connection did not have Ethernet wireless and it's wanted, you have the option to cheaply add this via USB. And saving the best part for last, two Controller Area Network Ports (CAN) & Six UARTs along with a bunch of other interfaces.For most or all the rest of the nodes I would use an ARM base as you have so very many choices. The current TI Stellaris Launchpad has 2 CAN controllers and 8 USARTs. ST has it's discover boards and some of them will have CAN controllers.With these as a starting foundation to develop from Why go to PIC or AVR?With ARM if you want to add a small graphics screen you have the power and space to do so. With the small PIC's and AVR's with can controllers you are probably in juggle mode or fancy complicated programming to get it to work. Yes for very simple nodes these could make some sense, but if you need more power then these can offer for a node then they are probably a poor choice to use even in the limited spots.MiceuzWith all the chips that have a built in CAN controller using a SPI CAN hardware chip would be my very last choice. I would most likely add a second mpu with a can controller before that choice. This is adding an extra layer of complications for what I see as no good reason. It would be much cheaper and you have more to work with with an ARM chip.nctnico,The short answer is that they think they can sell it and break even or make money. It does not have to make sense or any of the many other things you might think, it's just the money.Some one sold pet rocks and made a killing just because enough someones would buy them. Does this make sense?For the PCA9600 it's probably a case of it's cheaper to add that expensive chip then to redesign what it's connected to at one or both ends and then add the programing needed. Even in this limited case I would guess that it would not be used in the future unless this case was a really strong case for it continued use.Just my thoughtsC

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2014, 07:45:33 pm
content: Quote from: C on January 16, 2014, 07:26:58 pmThe flaw in your reasoning is that if a chip doesn't sell Farnell and Digikey won't carry it let alone stock pile large quantities. Besides that we all have I2C over a (long) wire in our home: VGA, DVI and HDMI. Despite all the technical marvels of CAN, ethernet and RS485 I2C is plain, simple, robust (glitch filtering!) and cheap. You don't even need a microcontroller at the endpoint.

author: zapta
author_rank: Super Contributor
timestamp: January 16, 2014, 08:20:49 pm
content: OP, your requirements seems to fit the linbus very well. One bus master, N slaves (each can listen to all the others), moderate speed (up to 20K), noisy environment, inexpensive nodes, inexpensive wiring (three wires, 12V + signal) simple protocol, no collisions, guaranteed latency, and good vendor support.Microchip has transceivers, tools (analyzer/generator), app notes and even integrated packages with transceiver, LDO and microcontroller.http://ww1.microchip.com/downloads/en/DeviceDoc/41673A.pdf