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

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. New contributor risingtiger is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. • You are correct about the resistor on the receiver side as a current to voltage converter so it can be easily read by the MCU's ADC. I don't know about the transmitter side but I would use an op-amp instead of a MOSFET (or an op-amp that uses an external transistor as a power-amp so that the op-amp can handle the regulation without needing to dissipate the heat itself). I wouldn't try to run I2C or SPI over a few feet although you can and people have. RS-422 or RS-485 is what I would use. – DKNguyen Jan 13 at 1:49 • It would help us if you tell us a bit more about your application. What sort of sensor, or what are you going to measure? How much power do the sensors consume? How are the sensors arranged (star, line, grid)? Is it one signal per node? (Are you certain that it will remain one signal per node? ;) – Nick Alexeev Jan 13 at 3:00 • As DKNguyen suggests, have you considered running SPI over RS-422 (or RS-485 half duplex)? – Jeremy Jan 13 at 13:16 • You mention a thermistor as an example. If you actually need to measure temperature, you can probably get away with running twisted pair from the thermistor directly back to the uC board, rather than digitizing at the sensor. Temperature changes pretty slowly, meaning it's pretty easy to average in software to remove noise. This solution is, of course, less valid for any faster changing analog signal. – Selvek 2 days ago • If you really want to implement an analog solution for a remote sensor, be sure to take cost of cables into account. You might marry yourself to a solution only to find that you need a magic cable to make it work right. – Scott Seidman yesterday ## 10 Answers 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. • Interesting! The P82B96 seems a viable solution. Adding the complexity of MCUs along with powering them and the conversions necessary to communicate over rs422 is excessive: more cost; more components to break; more code to maintain and more PCBs to create. What kind of power source does the P82B96 require? – risingtiger Jan 13 at 5:47 "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. • RS-422 is a practical ways to transmit over long hauls. But, this project requires keeping costs/complexities low. It may not seem to be a big deal to just throw on an extra microcontroller per sensor, but that creeps up the complexity: more code; more PCB boards to manufacture; more components to break; and more things to maintain. But, if there is an inexpensive, simple off the shelf RS-422/485 component that will simply convert an analog signal into digital and transmit that out across the line, that may work. Still, added complexity, but a complexity that can mostly be externalized. – risingtiger 2 days ago 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. New contributor Paul is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. • +1 There's a reason most car electronics uses CAN for the modules to talk to each other, instead of something like RS-232 or RS-485. It's simply a better system, and way more reliable. For historical reasons there are other systems used for OBD such as ISO-9141 ("K-line") and J1939, but for modules to talk to each other, CAN is basically the only game in town these days. – Graham Jan 14 at 10:40 • While J1939 didn't originally mention CAN it almost certainly implies CAN these days. You may have been searching for J1850. But yea, CAN is a strong protocol. To the credit of the idea of home automation there's a contingent of industrial automation using CAN such as CANOpen. If it's good enough for them... – foreverska 2 days ago • CAN is indeed impressive. But it does require having a microcontroller on the sensor end, or so I assume. Are there any viable components on the market that can take an analog signal in and transmute that into a CAN signal out over the wire? The point here, is that I'm trying to stay away from extra complexity, cost and code. But if there's a simple, inexpensive CAN converter on the market that is fairly plug and play then it might be the way to go. – risingtiger 2 days ago • @foreverska Ah, my mistake - been a couple of years since I worked on it, and the numbers got mixed up in my head. :) – Graham 2 days ago • @risingtiger They exist for varying definitions of cheap. AnalogX (Autosport Labs) is$100 apparently. For $150-200 you can probably source a Beckhoff or WAGO CANOpen Bus Coupler + Analog module from Ebay. – foreverska 2 days ago 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. • 4-20mA devices are not legacy devices - they are bread and butter in the industrial world and the shelves are packed full of brand new devices of all sorts that use 4-20mA analog output. – J... 2 days ago • @J..., cstanto said legacy system, not legacy devices. Of course there are modern devices designed to interface with legacy systems, and vice versa. But if one were to design a system from the ground up today, I doubt that communication protocol would be a top choice. – Nate S. 2 days ago • @NateS. And you'd be wrong. It is very much a top choice, even today. – J... 2 days ago • @J Yes, I understand that new devices are still being designed and sold with 4-20mA loops, I spent 5 years working for a firm that did just that, but a large chunk of that popularity is because theyre being fitted into systems that dont have more modern digital comms capabilities. We would always recommend CAN/RS232/RS485 variants of our instruments and sensors over 4-20mA variants unless the customer was dead set against them and knew how to acquire data from a 4-20, as it allowed more sophisticated control and diagnostic capabilities. cont... – cstanto yesterday • ...With "industry 4.0" and the increasing push towards smart sensors 4-20mA loops are only going to get pushed out of the market over time for all but niche applications. – cstanto yesterday 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

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

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

• I've used similar solutions as you outlined in previous projects. But those projects had a much larger budget per install. This particular project requires costs to be very small and maintenance very minimal. But, yes, Ethernet is quite awesome in its wide application. – risingtiger 2 days ago

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.

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.

New contributor
Gwyn is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
• Do you know of any good resources for learning the current loop methods? – risingtiger 2 days ago
• @risingtiger. I do not have my copy to hand right now, but there must be something in 'The Art of Electronics' by Horowitz and Hill. It is my go-to book for everything electronic ever since I picked up a second hand copy as a student.... – Gwyn 2 days ago

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.

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.