Best practice in transmitting sensor analog signal over longer distances (approx. 100') -- in cost sensitive products for microcontrollers

Question

I'm looking for best practices for transmitting an analog sensor signal over long distances to a microcontroller such as the Arduino running at 3.3v or 5v. Keeping costs low is imperative.

SPI and I2C is very common in Arduino land, but it seems there just isn't much of a solution when sensors need to be more than several feet away from the microcontroller. But perhaps I2C or SPI will work with the right components and wiring. Any ideas?

4-20 mA current loops seems like a solid solution since current doesn't drop along distances as long as the supplied power stays consistently above the demand. But 4-20 mA systems of sensors, transmitters and receivers seem to be mainstays in the industrial world and virtually absent in low cost embedded systems.

A classic need is detecting temperature through a resistive based thermistor. Are their inexpensive transmitters that can be coupled with a thermistor to transmit a 4-20 mA current loop signal? And then an inexpensive receiver on the microcontroller side? I would think something like a MOSFET on the transmitter side would work, coupled with a resister on the embedded side.

Alas, being a software engineer, electronics is still a bit fuzzy to me.

UPDATE: Should have specified more. 30' - 150' distances through potentially electrically noisy environments. I can go VERY low on bit rate: 10Khz. Even 1Khz if such a thing is viable. Putting in a low pass filter and/or software filters is not a big deal. I would like to be less than $10 per sensor (not including housing). But I would also like to stay away from a custom PCB board at the sensor if possible.

Answer 1

The other solution can be I2C — there are extenders, allowing to create buses up to 100m (300ft). One of them is NXP P82B96. It is very useful in amateur constructions, because it is not expensive and exists in an easy-to-mount DIP-8 case too. Additionally it allows to translate logic levels to higher voltages (for example 12V). You can find some application notes on NXP pages, for example: https://www.nxp.com/docs/en/application-note/AN10658.pdf

There is also a possibility to build an opto-isolated bus using P82B96: https://www.nxp.com/docs/en/application-note/AN10364.pdf

Another possibility is P82B715, but it is probably less useful because the maximum bus length is about 50m (150ft) and there are some other limitations. There is this appnote: https://www.nxp.com/docs/en/data-sheet/P82B715.pdf

Using I2C is a very effective solution, because there are many cheap interface chips on the market (ADC, DAC, IO, temperature sensors etc.) so, from the sensor side of view, there is no need to use an MCU (and to create dedicated software for this MCU).

Personally, I built my home automation system using this solution (P82B96 with opto-isolation) and I can confirm that it works very well and is stable and reliable.

Answer 2

"Best practice" and "inexpensive" are both subject to opinion.

In all cases, I'd put a really inexpensive little processor at the sensor, and have it talk digital. The 1950-1975 way to do it would be 4-40mA, or have the remote send a PWM or frequency-modulated signal.

• Up to six feet or so, power the remote sensor from +5V (or +3.3V) and run ground-referenced asynchronous serial (UART pins) straight from the sensor to the "main" processor.
• Up to sixty feet or so, power the remote sensor from whatever, and regenerate it at the remote. I'd probably give it +12V for overhead, and use a switching regulator "down there", but you can use a linear regulator. Use RS-422 with the remote set to just send, or use RS-485 in half-duplex, with some sort of a protocol so that remotes only speak when spoken to.

Answer 3

I've had excellent results transmitting sensor data using the Controller Area Network (CAN). I have a 16-bit microcontroller with a built-in CAN that interfaces through SPI to a 24-bit A/D converter. This microcontroller samples every 20 ms and sends the data out through CAN to another microcontroller (32-bit) located 50 meters away. CAN has some advanced error-checking that older systems may not. It uses a differential pair so it's pretty well immune to noise. Microchip makes the MCP2515 which will interface CAN through SPI.

Answer 4

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

RS-485 for Cost-Sensitive Sensor/Output Communications

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 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.

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

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.

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

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
• 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.

Answer 5

4-20mA loop will require some complex drive electronics and a higher supply voltage (the drive amplifiers ive used before were 18V). While it is still commonly used in industrial systems to this day and does have benefits, it is really more of a legacy system as far as most applications are concerned, and mostly used in retrofitting sensors to older daq systems that pre-date the widespread digital communications available today.

The most straightforward solution would be adding a RS-422 or RS-485 driver to your circuit. These standards are very common in the industrial sensors industry. Most ICs come with a suggested circuit in their datasheet too, so you can implement them without too much pain.

Answer 6

If you have a suitable micro at each end, and your micro can handle the processing required, Ethernet is a very good solution for long-distance comms. Cat5 Ethernet cables are available in almost any length you want, and their extensive use in all kinds of applications means you can get ruggedised versions too. Hint: The cables used to connect sound and lighting desks for stage applications are very good indeed - if your PC can't connect to the internet for an hour or so then no big deal, but if you lose sound and lighting for AC/DC playing a stadium then you have a huge bill on your hands!

This is easiest if the micros at each end run a "normal" OS. Windows or Linux will work, commercial OSes such as Wind River will play nicely too, and I'm sure there are others. Windows wouldn't be my first choice, but Linux is getting pretty good at real-time processing these days. With an OS in place, you can simply use IP ports to send your data.

You might think this sounds flaky, or too good to be true - but that's exactly how SpaceX connect electronics in their rockets.

The only wires between the stage and each engine are an Ethernet cable and a power cable.

If they can make it work to get a rocket into space, I suspect it'll work for your application too. :)

Answer 7

I like TimWescott's answer the best, but another option is to look at a professional microphone for live sound and studio work. They often run hundreds of feet through noisy lighting and AC power environments, before being amplified to a useable level by the rest of the electronics:

^{simulate this circuit – Schematic created using CircuitLab}

The mic capsule itself is electrically floating, not connected to the grounded metal case, and the two signal wires are subtracted from each other and the difference passed on as the intended signal.

So whatever noise gets through the grounded shield of the cable and onto both wires, gets cancelled at the receiver. Twisting them puts them as close to the same position as possible so that the same amount of noise gets to both, and keeping their impedances equal allows them to accept it to the same extent.

---

If you also need power at the mic end, and don't want to mess with batteries, you can use "Phantom Power":

^{simulate this circuit}

R1,2,5,6 allow the AC audio signal to still exist on the same wires, and the high source voltage is to get a useful amount of power through them anyway.

C1,2,3,4 block that DC from the audio components.

R3,4 reestablish the average DC level, having been blocked by the caps.

D1,2,3,4 clamp the maximum and minimum voltage to protect against the spikes caused by switching the power on or off, connecting a cable with it on, etc.

R7 keeps the active driver stable into a long (capacitive) cable.

R8 matches R7 to keep the impedances equal, and shows that the signal doesn't have to appear on both wires. Only a difference of some kind is needed, and equal impedance.

Answer 8

If you are looking to keep it simple and not convert to digital format then current sensing is a cheap and practical way to go.

This does not have to be a 4-20mA system. You are free to choose the currents according to the distances, power supply available and how electrically noisy your environment is. Another advantage is that you only need 2-conductor cable, so anything (even mains cable) will do.

Here is an example that I have used with a cable of about 40m. The LM35 outputs a voltage proprtional to temperature, used to drive a current through R2. R1 is used to increase the lower limit of measurable temperatures. Choose R_sense to suit your supply voltage and microcontroller inputs.

^{simulate this circuit – Schematic created using CircuitLab}

Just make sure that the minimum voltage across the supply of the LM35 is respected in your use-case. There is more information in the datasheet for the LM35 about how to choose the resistor values.

Answer 9

I don't know what your exact constraints are, but rather than bring the signal to the board, I would bring the board to the signal, and then carry the resulting data over Ethernet (or even Wi-Fi, if the environment is suitable for this).

A cheap ESP8266 or ESP32 board next to the sensor would probably do.

If you have an issue with getting power to the board, you can use Power over Ethernet (PoE) to power them, with cheap injectors and splitters at either end.

There are even boards with PoE built-in, like Olimex's ESP32-POE-ISO or the wESP32 available on Crowd Supply.

Answer 10

I would build and oscillator whose frequency depends on the thermistor. Its output could be transformer coupled to block common mode noise. A demodulator could be made whose output depends only on frequency, and not at all on amplitude. The rest is just a nasty calibration problem.