Rugged industrial protocol for low power sensor

[davegravy]

I have a linux-based SBC which has I2C, SPI, and a CAN controller (all UART interfaces are consumed already).

I have a remote sensor which has yet to be developed but will have an MCU (tentatively STM32U5). There will be roughly 2m cabling between the two and they will be in a somewhat noisy environment (outdoor urban construction site).

I need to keep power draw to a minimum since I'm reliant on a compact solar panel.

The remote sensor will need to wake the SBC at most once every 10 minutes and send a 50kB payload, so the effective datarate is very low, but the SBC is power-expensive so it's not wise to wake it a long time at a very slow datarate (or many retransmissions due to failed error checking).

I've seen that it's possible to convert I2C and SPI to differential signaling over shielded twisted pair cabling, and effectively extend their reach + noise immunity. The other option I know about is CAN but it sounds like this is generally used in automotive which is a bit less power constrained.

Obviously there's a tradeoff between power consumption and ruggedness, I'm not sure what's a good balance for this. I'd be pretty happy if I could get a solution that's around 10mW average draw (associated with whatever transceivers are needed), does that seem like a reasonable goal?

[moffy]

I would probably go with the CAN, because it is designed for the environments you are using it in. There are probably low power solutions for CAN e.g. https://www.ti.com/lit/ds/symlink/sn65hvd1040.pdf?ts=1719612139579&ref_url=https%253A%252F%252Fduckduckgo.com%252F

[thm_w]

RS485, RS422, or CAN
Receiving doesn't take much power so if you can shut the transmitter off, 10mW average should be easy.

The SBC is not running on solar right? Just the sensor.

https://www.eevblog.com/forum/projects/wired-sensors-around-the-house/
https://www.eevblog.com/forum/projects/what-technology-for-sensors-everywhere-in-the-house/

[nctnico]

SPI over RS485 is an option; I have used that in various designs. If you add checksums on the data so a bad packet can be detected, there is little which can go wrong.

[davegravy]

The SBC is not running on solar right? Just the sensor.

Everything is off solar, but the SBC can deep sleep almost all the time.

[David Hess]

For simplicity and lowest power, I would drive a differential pair with two series terminated CMOS gates, and no termination on the end of the cable.  A comparator or differential line receiver works as a receiver.

Ethernet cable will work, but any shielded differential pair cable would be good.

[T3sl4co1l]

RS422/485 is excellent for noise purposes, yeah.

Logic level is acceptable if you can afford good filtering (maybe not at bitrate) or a shielded cable.

Really, 2m isn't long at all, and if one end or the other is floating (no ground connection), you'll find immunity is quite good.  For detailed reading, see: https://electronics.stackexchange.com/questions/689066/cable-shielding-best-practices/689138#689138

UART saves two channels over SPI, and thus all the power consumption of those channels. (Assuming a basic/naive SPI bus of SCK, MISO, MOSI and CS. Maybe CS is implicit so this would only save one channel.)

Three channels even, if a single channel can be used with a transfer protocol.  For example, you might have the SBC act as client, sensor as server, and SBC requests a transaction, gets sent a buffer load (maybe some hundreds of bytes), checks CRC, acknowledge, sends another load, etc. until the packet is complete.  Each pause and ACK is an opportunity to reset line state, or perhaps request a failed segment (if integrity is important, maybe you have an overall CRC or hash for the packet, or overlapping pairs of sub-packets, etc., so can identify which one(s) are in error).  Line direction is gated by state and timing; either party can simply wait until timeout to reset state and then the client can re-send a request, for example.

Give or take some modulation tricks (can include Manchester encoding, if a bit clock is available from the UART(s)), you might reduce the sensor entirely to two wires, and use coax.  AC signal can be duplexed onto the power line with a decoupling network.  Or maybe you meant the sensor is self-powered in which case nevermind.

Related question: what is the practical minimum wake time for the SBC?  If you could transfer the data instantaneously, how fast could you actually make use of it, and go back to sleep?  It's entirely possible to use a baud rate high enough to transfer everything in a few ms (5Mbps+?), but maybe it's not worthwhile as the minimum wake time is 10s of ms or something.  The tradeoff is, higher baud means less filtering on the line, more RFI susceptibility.

Tim

[Benta]

CAN every time. You'll get up to 1 Mbps, it's differential, error tolerant, and designed to operate in the electrically "dirtiest" environment possible, which is Automotive.
Good transceivers are Infineon, NXP, and...

[Doctorandus_P]

RS485 and CAN are very comparable concerning signal integrity and cable length, and if you already have a CAN bus it's logical to use it.

You can also consider simply removing power from the cable in between measurements. (I assume the cable has both data and power). There are many (but maybe not all) CAN transceivers that are in a high impedance state when they do not have power.

[SiliconWizard]

I second CAN, and CAN FD can get you significantly higher throughput than CAN 2.0, if you need more throughput. Many recent MCUs support CAN FD (at least that's the case with STM32). Not sure your SBC supports CAN FD though. But just a thought.

[davegravy]

I second CAN, and CAN FD can get you significantly higher throughput than CAN 2.0, if you need more throughput. Many recent MCUs support CAN FD (at least that's the case with STM32). Not sure your SBC supports CAN FD though. But just a thought.

SBC supports it, but don't know I really need it (see below)

Related question: what is the practical minimum wake time for the SBC?  If you could transfer the data instantaneously, how fast could you actually make use of it, and go back to sleep?  It's entirely possible to use a baud rate high enough to transfer everything in a few ms (5Mbps+?), but maybe it's not worthwhile as the minimum wake time is 10s of ms or something. 

SBC takes a good ~100ms to wake up and that again to fully return to sleep. That's without any processing and IoT stuff (cellular TxRx), which takes a few seconds. So I think high throughput doesn't buy much.

I've ordered a few of these SN65HVD1040 to try.

I need to power the remote sensor (MCU and CAN transceiver) via the same cable that would carry CAN. Would the sensible arrangement be to use 2 twisted pairs inside a shield:

* tie shield to GND on both ends
* CANH+CANL as the 1st twisted pair
* power on both the 2nd twisted pair conductors

?

Or better to twist power+GND on the 2nd pair?

[nctnico]

AFAIK CAN is pretty power hungry. Especially if you are going to use resistive termination at high speeds. And then you'll have extra software overhead by needing to chop data into several CAN packets and get the sequence right at the receiving end.

All in all I don't think CAN is a good fit. Especially if you need to send more data than fits in a single CAN message. With SPI it is easier to implement a request / response pattern using longer messages. UART would be an even better fit due to the inherent noise filtering. NXP has SPI to UART converter chips like the SC16IS750 for which a Linux driver exists (assuming the SBC runs Linux).

[Doctorandus_P]

Oops. I overlooked the bursts of 50kB of data to send every 10 minutes.

CAN is a nuisance for sending bigger packets. It has a very limited / small frame format.

Neither I2C nor SPI are very suitable for driving cables. Especially I2C is hampered by capacitive loading. SPI can work, but if you have a few meters of cable then you need extra bus drivers to make it reliable.

RS485 combined with the simple UART is a good choice. Depending on the UART's you have, a baudrate of a few Mbit/s is achievable. This keeps the total communication time short and this reduces the average power consumption. Another similar idea is to use the UART, but use CAN transceivers instead of RS485 transceivers. This mostly has an advantage when you have multiple masters on a two wire bus, because the "passive" state of CAN makes it easier to detect bus conflicts reliably.

[T3sl4co1l]

(all UART interfaces are consumed already)

It may be worth seeing if one can be swapped around reflecting priorities here. Or multiplexed (exclusive use with one device at a time).  But perhaps they're all optimally used, and something else is preferred.

Oops. I overlooked the bursts of 50kB of data to send every 10 minutes.

CAN is a nuisance for sending bigger packets. It has a very limited / small frame format.

CAN I *think* is more of a set-of-registers protocol, with similarities to Modbus and other industrial comms -- I haven't worked with it personally (actually a bit surprising at this point, to be fair), but yeah this sort of thing tends to complicate large packets.  You might basically implement a handshaking transfer protocol on top of the transport layer, which is... annoying, but doable.  (For example, client sets "receive ready" register, server sets up new data register values; client polls "data ready" register, then reads out and stores a round; client clears then resets "receive ready" to signal the next round; etc.)  All the delays of polling and processing, plus comms with other things on the bus (maybe not the case here, but happens in general purpose use), and automatic re-sending or whatever error correction, can add up to a lot of variable latency and really cut into the transfer rate.

I recall hearing about some manner of "mailbox" mechanism, which shows up on these sorts of protocols; I forget if CAN has that, or it's one of the expanded types, or, maybe it's literally just doing the above but as a standard network layer rather than ad-hoc.

Neither I2C nor SPI are very suitable for driving cables. Especially I2C is hampered by capacitive loading. SPI can work, but if you have a few meters of cable then you need extra bus drivers to make it reliable.

Don't be so dismissive based on trigger words -- give it a thought first:

There will be roughly 2m cabling between the two

2m is hardly a burden for these protocols, and if baud can be cranked down low, ample filtering can be applied, reaping immunity instead.

As demonstrated in my earlier link, a short pendant connection like this is quite capable in EMI terms, for frequencies below the electrical length of the cable.  And filtering is readily added.

I wouldn't actually mind at all doing I2C here, with the sub-400kbaud rate being easily filtered for the 10MHz+ EMI that's likely to interact with it.  I2C's 50ns glitch removal helps with EFT/ESD (though how much depends on how those transients interact with the bus filtering), and implementing a CRC and block retransmit protocol should address errors.

I2C is kind of the worst case for filtering, as its high-impedance pull-up condition guarantees mismatch with the driven-low (~30Ω) condition, neither case can be optimized for signal quality or noise rejection.  But again, noise largely starts in the 10MHz+ range, and a lowpass cutoff around a few MHz, for either condition, will handle that regardless.

SPI is fine, as the clock can be cranked down nice and low, and logic-level signals used -- filtering is effective as signals are full-wave driven, no open-drain state (except if deasserted between transactions, which really doesn't matter one way or another).

Either option saves greatly on continuous current consumption of a terminated RS-422 bus.

if the SBC wake time is some seconds, a transfer rate under 50kBps seems satisfactory.  That's under 500kbaud UART, 400kHz SPI, ~450kHz I2C (depending on packet length and overhead), etc.

Mind, I'm still being careful with comparisons here:
A RS-422/485 bus doesn't need to be terminated into exactly Zo.
It may be that a faster 422/485 bus (say 10Mbaud) transfers data faster than the current saved by I2C's larger-value pullups; almost trivially so if weak pulls are used instead of termination.
422/485 might simply not be applicable due to higher priority UART allocations, forcing CAN/I2C/SPI.
Perhaps CAN could be lightly-terminated as well; though, I don't know how well that plays with the bus arbitration mechanism.

(Incidentally, CANbus has an I2C equivalent: differential I2C I believe uses the same unipolar-driven-bus scheme, greatly improving immunity.  I don't see it being necessary here, but when you must use I2C over enough distance, it's the preferred way to do it.  Also, just to make it clear -- CAN signaling is essentially based on RS-485, indeed you can drive it with such a transceiver, with data set always-high and toggling enable instead.  So it's no accident that they show up in similar contexts, as far as robustness and immunity.)

Tim

[nctnico]

For 2 meters, UART + TTL levels will work just fine with some filtering & TVS and using receivers with a defined hysteresis. Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

[Doctorandus_P]

2m is hardly a burden for these protocols, and if baud can be cranked down low, ample filtering can be applied, reaping immunity instead.

Sure, it can work, but lowering data rates translates in longer communication times and thus time your uC is running (unless you wake it for each byte). If you use RS485, then you pretty much crank it up to the highest baudrate your UART's can handle without even having to worry much about signal integrity or reliability (as long as you use a twisted wire pair with correct termination resistors).

CAN peripherals inside uC's are among the "advanced" peripherals. You set it up by writing to some registers (including data) then start the peripheral, and the whole packet pops up in the other uC. Because of this you are also limited to how the peripheral works (I believe 8 data bytes per packet).

[Doctorandus_P]

Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

Yes, bus drivers. But what does that get above an 8-pin RS485 IC with built in TVS diodes?

[T3sl4co1l]

Sure, it can work, but lowering data rates translates in longer communication times

I literally just--!?

Look:

if the SBC wake time is some seconds, a transfer rate under 50kBps seems satisfactory.  That's under 500kbaud UART, 400kHz SPI, ~450kHz I2C (depending on packet length and overhead), etc.

SBC takes a good ~100ms to wake up and that again to fully return to sleep. That's without any processing and IoT stuff (cellular TxRx), which takes a few seconds. So I think high throughput doesn't buy much.

I don't know if you stopped reading at the point quoted and shot off a reply, or intentionally misread or (didn't read) my post; or accidentally, by oversight (hey, it happens to me a lot too), but in any case, I want to emphasize that I covered that.

(Or, if you meant to disagree, perhaps by going in a different direction, perhaps you have an objection that is orthogonal to my direction of attack, and didn't feel it necessary to explain how my argument fails while yours succeeds; this occurs all-too-often in conversation, where two people argue as though repeating ones' points would ever make a difference -- points already wholly dismissed by their opponent; but in that case I request a deeper explanation that either reaches a common point where such dismissal can be justified, or at least a heuristic argument prioritizing one over the other.  But, this is a simple enough thing, I don't think such a rhetorical mechanic applies here, and this is just a note for completeness.)

and thus time your uC is running (unless you wake it for each byte)

I have every confidence that the uC consumes approx. 20 times less current than a matched-termination 422/485 link, give or take efforts to optimize power (reduced clock, sleeping, power-down states compatible with peripheral activity).  I also have a strong confidence that the SBC consumes 20+ times more current than the uC; the uC is not the villain here, but neither is the SBC particularly avoidable in terms of activity spent here.  Fast '485 would indeed to well, but I doubt it does better, especially give or take cost.

(The real joke there is, we've spent exponentially more time discussing it than the parts count in production, if I had to guess. )

For 2 meters, UART + TTL levels will work just fine with some filtering & TVS and using receivers with a defined hysteresis. Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

What is an HC inverter gaining you that the HC-esque pin drivers on the MCU and/or SBC don't already provide?  Yes, added clamp diodes, ESD resistor(s), filtering, all assumed standard; but, you don't need any more drive strength (non-bus HC might be weaker anyway..!), inversion doesn't do anything, schmitt trigger is welcome but most MCU ports provide it -- worth making a note, check the datasheet; and, it's not likely to improve repairability or whatever, I would assume in lieu of specifying otherwise that servicing for the unit/system is module-level replacement, maybe board-level, and that's that, so a buffer between MCU and bus doesn't add value that way either.  (Is a good way to go, using sacrificial logic gates, preferably socketed DIP, to protect boards with more important (expensive, bespoke, vintage?) hardware on them, though.  Seems unlikely that's the case here, but not excluding the option.)

So...

Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

Yes, bus drivers. But what does that get above an 8-pin RS485 IC with built in TVS diodes?

...I would gladly reduce the bus interface to a pair of $0.10 clamp diodes instead of $0.60 gates or $0.80 interfaces

Tim

[nctnico]

For 2 meters, UART + TTL levels will work just fine with some filtering & TVS and using receivers with a defined hysteresis. Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

What is an HC inverter gaining you that the HC-esque pin drivers on the MCU and/or SBC don't already provide?  Yes, added clamp diodes, ESD resistor(s), filtering, all assumed standard; but, you don't need any more drive strength (non-bus HC might be weaker anyway..!), inversion doesn't do anything, schmitt trigger is welcome but most MCU ports provide it -- worth making a note, check the datasheet;

74HC14 has schmitt-trigger inputs with defined hysteresis. Very nice when dealing with signals coming from a potentially noisy source. In contrast, microcontroller pins can be allover the place.

Like using a pair of 74HC14 inverters as drivers & receivers combined with a shielded cable.

Yes, bus drivers. But what does that get above an 8-pin RS485 IC with built in TVS diodes?

RS485 drivers vary wildly in ruggedness which greatly depends on price. A couple of logic gates + TVS diodes are likely to consume less power which is also the goal of the OP.

[davegravy]

(The real joke there is, we've spent exponentially more time discussing it than the parts count in production, if I had to guess. )

Especially given that this will be low volume production. I'm happy to spend substantially more on an IC that simplifies development.

I do appreciate the discourse and am learning a lot reading this.

Also, for reference the SBC draws 500mW awake and 100mW asleep, which I gather is reasonaby lean as Linux based SBCs go.

It has 2 UARTs, one is occupied for console TTY (diagnostic use) the other interfaces with a ublox cell module. The cell connection is pretty critical so I don't know that I want to add complexity with multiplexing, although there's no real need to do cell comms in parallel with sensor comms save for shaving a bit of time off total wake duration.

[nctnico]

100mW sleep power sounds high to me. From a Li-ion battery that would be around 25 to 30 mA. Also: how about connecting the cell module to USB and free up a UART?

[davegravy]

100mW sleep power sounds high to me. From a Li-ion battery that would be around 25 to 30 mA. Also: how about connecting the cell module to USB and free up a UART?

Might be an option. The USB host port is occupied by another sensor (which is the main reason I'm using an SBC instead of uC). I don't have any experience with USB but I think this would mean adding a hub? Any idea if this would be more or less dev work than SPI-to-UART converter (e.g SC16IS750)?

[nctnico]

Adding a USB hub chip is easier compared to using an SPI to UART bridge. The USB hub chips work plug & play. And while you are at it, you can use USB-to-UART chips as well.

[PCB.Wiz]

The remote sensor will need to wake the SBC at most once every 10 minutes and send a 50kB payload, so the effective datarate is very low, but the SBC is power-expensive so it's not wise to wake it a long time at a very slow datarate (or many retransmissions due to failed error checking).
...
SBC takes a good ~100ms to wake up and that again to fully return to sleep.

How does it wake up ? Using  a separate wire ?

It has 2 UARTs, one is occupied for console TTY (diagnostic use) the other interfaces with a ublox cell module. The cell connection is pretty critical so I don't know that I want to add complexity with multiplexing, although there's no real need to do cell comms in parallel with sensor comms save for shaving a bit of time off total wake duration.

What BAUD speed can the diagnostic port manage ?
It's not hard to multiplex a TTL-UART, and 2m is not a large distance for any of the links you have.

RS485 can be wired to auto-direction handle (typically a pnp transistor ) and TI even have parts with Auto direction inbuilt.
RS422 needs no direction handling, but needs more conductors in the cable.

You can use CAN transceivers on UARTS too, the main difference from RS485 is an offset threshold and CAN RX usually echoes CAN TX.
The offset effect means CAN hardware has no idle power on the BUS.

Which peripheral is easiest to talk to from Linux ?

[exmadscientist]

CAN is electrically wonderful here but as noted, requires some software work. If you have a software person who gets enthusiastic about this sort of thing, I have seen it work out basically perfectly in godawful-horrible electrical environments. But that person is not me.

Please do not use I2C. Just don't. The issue is not whether you can or cannot filter it. The issue is what happens when one single stray pulse makes it through the filtering, and that is that it usually knocks out the whole bus unless you take heroic measures to keep things in check. (The main issue is that a stray pulse on SCL will get the masters and slaves out of sync. There are, of course, others.) It is possible to deal with this, but if you don't have to, don't. Choose something else.

422/485 is probably what I would choose. 232, real 232, is probably also fine.

If you want to do TTL I would also recommend a cheap Schmitt buffer. (I'd probably start with an LVC17 or similar?) The Schmitt action and ESD immunity provided by a dedicated chip are much better than MCU pins. Seriously, compare the transfer curve of an MCU I/O cell to the dedicated part if you don't believe me. They aren't always that different (MCUs vary a lot!) but they are different. And putting a dedicated chip in there means you're unlikely to be blowing MCU I/O cells, which is always just annoying to deal with. (Did I blow the cell or is it just driving weakly now or is the load high or is... oh, it's only pulling up now, it must be blown.) Better avoided!