Return to Answer

The simple rules:

• Two-wire half-duplex
• One master (PC) many slaves (sensors)
• If more than 20 slaves, think about a) collisions and b) bus loading
• Power from central
• No local connection at the sensor end
• If you need it, use opto-isolators or relays
• Whatever your protocol, it must have a checksum
• Use it like UDP not TCP
• Run it absolutely as slowly as you can
• At 9600 you'll probably never ever have any problems
• Over 20 metres, pay attention to termination
• If you're outside or underwater or big power nearby, still good but do more homework
• If you need fast (say 1Mbit/sec), still good but do more homework
• If you need isolated, still good but do more homework
• If you need hundreds of nodes, still good but do more homework

I've kept away from anything radio-based except where absolutely impossible to run wires. There's just no knowing when some interference machine will arrive: too often it's something like press or police walkie-talkies on grand opening of my event.

A further advantage of this approach is that it puts all important compatibility issues in the protocol on the RS-485 line. If in future you can't get the same sensor or CPU, get a different one and recreate.

And if you have need to interface to something you want isolated, it's easy to get an isolated driver such as the one from Digilent (albeit much more expensive, about £17.00). But without any redesign at all of the basic system, nor recoding. I used to use ethernet with POE, but change after having to do a lot of rugged environments (exterior, underwater, near big industrial machines). There's no switch to maintain, no POE voltages. And no arms race of 10BaseT, 100BaseT, 1000BaseT.

• Texas Instruments RS-485 Design Guide PDF
• Texas Instruments AN 1057 Ten Ways to Bulletproof RS-485 Interfaces PDF

RS-485 for Cost-Sensitive Sensor/Output Communications

Don't use radio I've kept away from anything radio-based except where absolutely impossible to run wires. There's just no knowing when some interference machine will arrive: too often it's something like press or police walkie-talkies on grand opening of my event.

Don't use ethernet I used to use ethernet with POE, but changed after having to do a lot of rugged environments (exterior, underwater, near big industrial machines). There's no switch to maintain, no POE voltages. And no arms race of 10BaseT, 100BaseT, 1000BaseT.

Don't use board-type buses Once I had a system (built by others) which was SPI at 2 metres: it just about worked but when we needed to move it to 3 metres ... it never worked. In then end I replaced it with RS-485 as described here.

CAN is great but it solves a difficult problem and so there is a lot of complexity. Serial and RS-485 is absolutely ubiquitous and that will save you time over and over again.

The Simple Rules

• Two-wire half-duplex (never four-wire)
• Either a) One master (PC) many slaves (sensors) or b) One speaker and possibly many listeners
• If more than about a dozen slaves, think about a) collisions and b) bus loading
• Power from central
• No local connection at the sensor end
• If you need it, use opto-isolators or relays
• Whatever your protocol, it must have a checksum
• Use it like UDP not TCP
• Run it absolutely as slowly as you can
• At 9600 you'll probably never ever have any problems
• Over 20 metres, pay attention to termination
• If you're outside or underwater or big power nearby, still good but do more homework
• If you need fast (say 1Mbit/sec), still good but do more homework
• If you need isolated, still good but do more homework
• If you need hundreds of nodes, still good but do more homework

Costs

Futureproof

A further advantage of this approach is that it puts all important compatibility issues in the protocol on the RS-485 line. If in future you can't get the same sensor or CPU, get a different one and recreate. If you use 75176-pinout driver chips you will always be able to get replacements.

And if you have need to interface to something you want isolated, it's easy to get an isolated driver such as the one from Digilent (albeit much more expensive, about £17.00). But without any redesign at all of the basic system, nor recoding.

References

• Texas Instruments RS-485 Design Guide PDF
• Texas Instruments AN 1057 Ten Ways to Bulletproof RS-485 Interfaces PDF
• Bob Perrin, "The Art and Science of RS-485", Circuit Cellar, July 1999. PDF

Specifics

• "Two-wire half-duplex" actually means three wires: a twisted pair for the signal and a ground, which is often the DC power ground if the systems are driven from the same power.
• You will see enormous contention about whether you need a shield, but Perrin says you don't unless you have exotic circumstances
• In half-duplex, the output the driver is enabled during transmission.
• On a PC you typically enable the driver with RTS of your RS-232 output. The Linux kernel has an ioctl(8) call for enabling this on serial lines TIOCSRS485 doc
• On a microcontroller you use an IO line for Driver-Enable DE. You can always listen (connect Receive-Enable /RE to ground) or more commonly join DE and /RE and drive from the same IO pin. You might conceivably use an IO pin and drive /RE but I've never seen it.
• There are lots and lots of variant driver chips, but chose one in a 75176 package as it's the most common
• It's a great idea to use 8-pin DIL packages and a socket for the driver so that when someone wires it up wrongly you can replace the blown driver; also you can use more robust driver chips if desired, or low-EMI versions with lower slewing rates.

RS-485 is cheap and simple and easy to debug. It works over short distances or long. You choose your speed and set up a simple protocol (easy for software engineers) and it will work forever. I often run it at 9600 or even slower. If you have suitable LEDs, you can understand breakages without any tools.

And if you have need to interface to something you want isolated, it's easy to get an isolated driver such as the one from Digilent (albeit much more expensive, about £17.00). But without any redesign at all of the basic system, nor recoding.

I changed to this kind of connection after using ethernet with POE and having to do a lot of rugged environments (exterior, underwater, near big industrial machines). There's no switch to maintain, no POE voltages. And no arms race of 10BaseT, 100BaseT, 1000BaseT.

RS-485 is cheap and simple and easy to debug if you follow some simple rules. It works over short distances or long. You choose your speed and set up a simple protocol (easy for software engineers) and it will work forever. I often run it at 9600 or even slower. If you have suitable LEDs, you can understand breakages without any tools. It's sufficiently simple I got a "physical computing" class at a New York art school to get a network going in a single afternoon, based on a format very similar to syslog (RFC 3164) plus a CRC-32.

The simple rules:

• Two-wire half-duplex
• One master (PC) many slaves (sensors)
• If more than 20 slaves, think about a) collisions and b) bus loading
• Power from central
• No local connection at the sensor end
• If you need it, use opto-isolators or relays
• Whatever your protocol, it must have a checksum
• Use it like UDP not TCP
• Run it absolutely as slowly as you can
• At 9600 you'll probably never ever have any problems
• Over 20 metres, pay attention to termination
• If you're outside or underwater or big power nearby, still good but do more homework
• If you need fast (say 1Mbit/sec), still good but do more homework
• If you need isolated, still good but do more homework
• If you need hundreds of nodes, still good but do more homework

And if you have need to interface to something you want isolated, it's easy to get an isolated driver such as the one from Digilent (albeit much more expensive, about £17.00). But without any redesign at all of the basic system, nor recoding. I used to use ethernet with POE, but change after having to do a lot of rugged environments (exterior, underwater, near big industrial machines). There's no switch to maintain, no POE voltages. And no arms race of 10BaseT, 100BaseT, 1000BaseT.

For proper reading about RS-485, start with these and follow through the references.

• Texas Instruments RS-485 Design Guide PDF
• Texas Instruments AN 1057 Ten Ways to Bulletproof RS-485 Interfaces PDF

I share your reluctance to put a whole CPU per sensor, however ...

I can recommend the following, which is how I now do these kinds of sensor/output devices:

• Local very small Arduino-alike CPU per sensor position
• RS-485 driver
• Local very small switched-mode PSU
• Power centrally
• Connect over CAT-5 or power+data pair cable

This means that you can keep all your per-sensor electronics very small, which simplifies everything (less noise, less to go wrong). The software for speaking to the sensor is dedicated -- no multiprocessing or interleaving of functions, it's got a whole CPU. If there's just one sensor I put RS-485 adapter on the receiving computer; more usually I have an Atmega device with RS-485 and ethernet and convert to and from UDP packets. Then the server -- or servers, so easy to make redundant -- can do the work wherever is convenient.

RS-485 is cheap and simple and easy to debug. It works over short distances or long. You choose your speed and set up a simple protocol (easy for software engineers) and it will work forever. I often run it at 9600 or even slower. If you have suitable LEDs, you can understand breakages without any tools.

Costs are low, below $10.00/unit -- most depends on housing and connectors. Following are 10-off prices from Digikey or Ebay.

For a one-off or experimental board I use boards from China:

• TTL to RS-485 converters from Ebay (£0.90)
• Arduino "Pro Micro" or similar (with reset button!) (£1.80)

For dedicated boards I prefer individual chips:

• 75176-pinout chip £0.70 + socket if space
• ATTiny22 or similar £0.50-1.50

The 75176-pinout is a standard for RS-485 drivers, which means you can use exotic drivers if you need to (eg with higher ESD protection).

In either case, I feed 12VDC or 24VDC for power alongside a twisted pair for the signal. On each unit a Recom R-78E5.0-0.5 power supply (£1.99/unit). These devices are great. Putting a tiny PSU next to each unit made all power and noise problems disappear.

A further advantage of this approach is that it puts all important compatibility issues in the protocol on the RS-485 line. If in future you can't get the same sensor or CPU, get a different one and recreate.

And if you have need to interface to something you want isolated, it's easy to get an isolated driver such as the one from Digilent (albeit much more expensive, about £17.00). But without any redesign at all of the basic system, nor recoding.

I changed to this kind of connection after using ethernet with POE and having to do a lot of rugged environments (exterior, underwater, near big industrial machines). There's no switch to maintain, no POE voltages. And no arms race of 10BaseT, 100BaseT, 1000BaseT.

I share your reluctance to put a whole CPU per sensor, however ...

I can recommend the following, which is how I now do these kinds of sensor/output devices:

• Local very small Arduino-alike CPU per sensor position
• RS-485 driver
• Local very small switched-mode PSU
• Power centrally
• Connect over CAT-5 or power+data pair cable

This means that you can keep all your per-sensor electronics very small, which simplifies everything (less noise, less to go wrong). The software for speaking to the sensor is dedicated -- no multiprocessing or interleaving of functions, it's got a whole CPU. If there's just one sensor I put RS-485 adapter on the receiving computer; more usually I have an Atmega device with RS-485 and ethernet and convert to and from UDP packets. Then the server -- or servers, so easy to make redundant -- can do the work wherever is convenient.

RS-485 is cheap and simple and easy to debug. It works over short distances or long. You choose your speed and set up a simple protocol (easy for software engineers) and it will work forever. I often run it at 9600 or even slower. If you have suitable LEDs, you can understand breakages without any tools.

I've kept away from anything radio-based except where absolutely impossible to run wires. There's just no knowing when some interference machine will arrive: too often it's something like press or police walkie-talkies on grand opening of my event.

Costs are low, below $10.00/unit -- most depends on housing and connectors. Following are 10-off prices from Digikey or Ebay.

For a one-off or experimental board I use boards from China:

• TTL to RS-485 converters from Ebay (£0.90)
• Arduino "Pro Micro" or similar (with reset button!) (£1.80)

For dedicated boards I prefer individual chips:

• 75176-pinout chip £0.70 + socket if space
• ATTiny22 or similar £0.50-1.50

The 75176-pinout is a standard for RS-485 drivers, which means you can use exotic drivers if you need to (eg with higher ESD protection).

In either case, I feed 12VDC or 24VDC for power alongside a twisted pair for the signal. Over CAT-5 works fine, or power + data cable. On each unit a Recom R-78E5.0-0.5 power supply (£1.99/unit). These devices are great. Putting a tiny PSU next to each unit made all power and noise problems disappear.

A further advantage of this approach is that it puts all important compatibility issues in the protocol on the RS-485 line. If in future you can't get the same sensor or CPU, get a different one and recreate.

And if you have need to interface to something you want isolated, it's easy to get an isolated driver such as the one from Digilent (albeit much more expensive, about £17.00). But without any redesign at all of the basic system, nor recoding.

I changed to this kind of connection after using ethernet with POE and having to do a lot of rugged environments (exterior, underwater, near big industrial machines). There's no switch to maintain, no POE voltages. And no arms race of 10BaseT, 100BaseT, 1000BaseT.