Wireless bridging for Modbus/RS485 devices

[5U4GB]

I've got a bunch of low-end devices that talk via RS485 that I'd like to hook up via something less hairy than long cable runs, and Aliexpress/eBay have a bunch of what look like RS485 <-> ISM-band <-> RS485 bridges, e.g. this DIN-rail mount unit.  Has anyone used something like this before?  As with a lot of these things information is pretty minimal, I'm looking for something that acts purely as a bridge, so I can have the master on one side and a chain of slave devices on the other without needing to run a long cable between the two groups.

[woofy]

To buy, no idea.
To build yourself:
I would use a few ESP32's. Hook them up to an RS485 driver such as the st485, and use ESP-NOW to talk to the slave modules from the master. ESP-NOW is limited to 250 bytes/packet which should be plenty for most real world modbus frames.

[RoGeorge]

RS-485 is very sturdy in industrial environments, RF might not be that great with noises and can also be sniffed remotely, or subjected to MITM attacks.  Where/what for is the RF link?

Since you mention a DIN rail, sometimes DIN rails are sited inside metallic cabinets.  A metal box might shield the RF link.  What distance of wire is to be replaced? 

[5U4GB]

It's a whole range of different situations, not one particular application, with an accompanying whole range of obstacles like having to tear open walls to get access, or the only access route is around 30m long inside in a cable tray containing 3-phase AC power cables, or through an area with lots of machinery and things that get moved around where it's not obvious where you could safely run a cable, or from one building to the next, and lots more.  Having a way of teleporting Modbus comms from point A to point B would get rid of a lot of headaches.

In terms of build vs. buy, we build the things being signalled via Modbus, developing and keeping all of that running is enough pain for now ("we want to display every parameter in the system all at the same time on this big panel, you can read all that out via Modbus can't you?") without also designing and building industrial-grade wireless bridging stuff.

[Doctorandus_P]

Adding some RF connection to a Modbus installation may wel create bigger headaches then it solves. From occasional packet loss due to interference, to completely loosing connection once a month for a few hours, to deliberate snooping and/or sabotage.

Therefore, the easy (and safest) answer is to simply state that RF connections simply do not belong in an industrial environment. With exceptions for when there is no other choice at all.

But if you want to go that way. I recommend at least high quality 2 way modules with good antenna's heavy CRC checksums and encryption. I guess there are commercial sources for such things, but as with anything industrial, it's not going to be at "consumer" price points.
 
Edit:
A quite simple search for: modbus rf radio
quickly finds links like:

https://www.modemlabs.com/product/modemlabs-868mhz-modbus-radio-modem-rtu-i-o/

https://www.accuenergy.com/products/acumesh-wireless-modbus-rtu-transceiver/

[Kim Christensen]

I know you asked for wireless, but, you could use a pair of fiber media converters if you're worried about the high power electrics and interference.
Not endorsing or recommending these particular ones. Just showing you what I mean.

EDIT: Or if it's a building that already has telephone lines run to every room, you could steal a couple of pairs and join the two rooms. Then use two back to back modems to send your data.

[zilp]

Others have already said it, but: Don't.

RF is prone to interference, from noise to intentional sabotage, either of which is a pain to debug, especially when it's intermittent, plus it absolutely requires cryptographic authentication (no, not CRCs, cryptographically secure hash functions or AEAD constructions, CRCs have no place here) and possibly encryption to prevent sabotage beyond a simple DoS. And with ready-made solutions I would generally expect the cryptography to be crap, most people who build such stuff just have no idea what they are doing.

For the problems that you describe, ethernet is probably a better solution. While that also requires cables, obviously, the big advantage is that you don't need a separate cable between the two endpoints, and ethernet infrastructure often already exists anyway, especially between buildings, so you can just push your RS485 messages through the existing network, and all you need is a cable from either endpoint to the closest ethernet switch, with no need to worry about how the packets get moved through the core network--chances are that they'll be forwarded through some 10 Gb/s fiber backbone between buildings, completely transparently to you. And if you are dealing with extremely noisy environments, you can also easily use fiber links there.

[Siwastaja]

I don't like all the naysaying when we don't know about details.

Not all MODBUS traffic is latency critical, or critical at all. Maybe you want a status output every minute or so. Maybe you can write a networking layer which uses frequency hopping and retransmissions and finally gets the packet through. Of course with ISM you never have guarantees, but we still pretty much rely on WiFi and Bluetooth stuff in our daily lives.

[peter-h]

Nothing beats wire for reliability.

Modbus has a "max 3.5 char period gap" in the spec. Admittedly a lot of Modbus devices fail to implement this, which works in your favour (mostly).

To run Modbus over some network you have to either use such devices throughout (difficult; who will tell you their boxes are noncompliant?) or ensure the "bridge" device implements Modbus over IP or some such which, usually, is implemented as putting a whole Modbus packet into a single MTU, or buffering the data until a whole valid packet has been received and then send it on.

But a radio modem is probably not running IP anyway.

With chinese boxes you never know what they did, so good luck

Yes; wifi and bluetooth are everywhere but they (especially BT) are monumentally flakey unless you stick to high volume consumer scenarios where some Big Name (e.g. Samsung) spent thousands of hours making sure the stuff works with everything people may want to connect to it.

[H.O]

FWIW:
I have some similar radios, bought for the exact same reason.
In my application (non critical logging application) they do work but it was not the wireless "cable replacement" I was hoping for. There's quite a delay between the data enetering one radio and coming out at the other end. This did not work at all in my application where the poll-rate on the bus is 1Hz.

Fortunately for me only a few nodes needed to be polled at 1Hz and I could keep those hardwired and use a SEPARATE "bus" for the ones at the other end of the radio, this "wireless bus" is polled once every minute. It has been working fine like that for several years now. I do see the occational missed response from the node(s) on the "wireless bus" but have not looked into if it's an issue with the radio, the node(s), interference or what. Next poll it's fine again.

I'm sure there are different types of radios and the ones I have is not the same as in the OPs link but they had things like "wireless RS485" in the feature discription. I'll look up the specific type if needed.

[peter-h]

The words "chinese", "radio" and "compliance" are mutually exclusive

If it works, be grateful.

The above post shows one problem. No reason for such gaps at all. But to be fair, there is no spec on how this is to be done.

[5U4GB]

Not all MODBUS traffic is latency critical, or critical at all. Maybe you want a status output every minute or so.

That's essentially what this is, it's powering a sort of dashboard system that's meant to provide an overview of what's going on in a facility (specs are still subject to change).  I think it updates once a minute or so, and if a reading is lost it just displays the existing one until some failure timeout expires, whereupon it says "no data".  It's not even remotely latency critical, security critical, or any other type of critical, the only thing that's a bit critical is that large amounts of effort to run physical connections probably won't fly.

[5U4GB]

Yes; wifi and bluetooth are everywhere but they (especially BT) are monumentally flakey unless you stick to high volume consumer scenarios where some Big Name (e.g. Samsung) spent thousands of hours making sure the stuff works with everything people may want to connect to it.

These, or ones very similar, claim to be LoRa, which is both pretty good for dealing with interference and has decent enough security, but as mentioned previously it's not really an issue in this case.

[5U4GB]

FWIW:
I have some similar radios, bought for the exact same reason.

Thanks!  So just to check, you can have multiple slave devices hanging off a single radio rather than one radio per device?

[H.O]

@ 5U4GB
Yes. In my particular case I have 4 nodes connected to the RS485 bus on the "remote" radio.
My radios are manufactured by EByte, specific model is E32-DTU-433L20 but, again, I would not recommend these for any "normal" MODBUS network with "continous" trafic.

[Siwastaja]

You'd need to implement a configurable MODBUS master on that bridge, so that no raw serial (with all the timing issues) would be exposed through the bridge.

Basically, over the air, the configuration protocol how you tell "Every X seconds, read N modbus registers starting at address Y", and then a protocol to transfer these values over the air. Add buffering of messages, frequency hopping, retransmissions etc. and there it is. I have done something very similar on nRF52 and it works very solidly. But packet loss in range of 90% or so is completely normal on these ISM bands. With frequency hopping and long enough buffer for resends it's not an issue. Of course you can have a total blackout of the complete band, but then WiFi and all bluetooth stuff completely stops working, too, yet people rely on them. WiFi specifically is complete opposite of "robustness", it doesn't even have frequency hopping, the whole thing is just based on endless retrying.

[5U4GB]

@ 5U4GB
Yes. In my particular case I have 4 nodes connected to the RS485 bus on the "remote" radio.
My radios are manufactured by EByte, specific model is E32-DTU-433L20 but, again, I would not recommend these for any "normal" MODBUS network with "continous" trafic.

Great, thanks!  I'd looked at some of those, they're now CDEByte (not to be confused with ABCByte I assume), they seem to do mostly LoRa/BT/WiFi/Zigbee radio modules which they then package into an enclosure with a DC/DC converter and some input protection elements on the RS485 port, see the first product image in this listing for internal details.   It claims to use an SX1278 for the radio portion so it's genuine LoRa and not mystery meat radio signalling like, for example, this one.

[zilp]

Of course you can have a total blackout of the complete band, but then WiFi and all bluetooth stuff completely stops working, too, yet people rely on them.

But people don't. Not in a comparable way. When my laptop's WiFi connection gets unusable, I can walk around to find a spot with less interference, or I can just plug it into an ethernet port. When my phone's WiFi connection gets unusable, I can switch to the mobile network on regulated bands to get more reliable connectivity. WiFi is a convenience, but it's not something I *rely* on, in the way that some industrial gear would rely, i.e., be dependent, on ISM communication if there is no alternative more reliable connection that can be activated in a heartbeat when needed (and if you had that, there probably wouldn't be any need for RF at all, as mobility usually isn't a useful feature).

WiFi specifically is complete opposite of "robustness", it doesn't even have frequency hopping, the whole thing is just based on endless retrying.

Really, it isn't, though. WiFi uses adaptive coding rates and modulation schemes to maximize throughput while minimizing channel errors, it uses spread spectrum modulation to reduce the impact of narrow-bandwidth interference (so, that's effectively a better version of frequency hopping), and it uses forward error correction to hide minor interference. And then, it uses retries on top of all that to further improve reliability.

[zilp]

It's not even remotely latency critical, security critical, or any other type of critical,

So, it wouldn't matter if it always showed incorrect values?

[nctnico]

It's not even remotely latency critical, security critical, or any other type of critical,

So, it wouldn't matter if it always showed incorrect values?

I agree. In my experience some people can become very upset when things work intermittently. I recall getting a remark about 2 LEDs blinking in & out of sync every now and then. Imagine some kind of instrumentation panel with random update intervals. In reality nobody looks at such panels unless there is a problem and a random update interval is not going to help instill confidence in the proper operation of the system. I have a few more horror stories about unmet expectations of customers.

[5U4GB]

It's not even remotely latency critical, security critical, or any other type of critical,

So, it wouldn't matter if it always showed incorrect values?

Sure, and it would also matter if it exploded violently throwing shrapnel in all directions.  However I'm assuming neither of those will happen, at worst it'll show a no-data-available error, but whether that happens and how bad it is remains to be seen once we do a trial run.

[zilp]

Sure, and it would also matter if it exploded violently throwing shrapnel in all directions.  However I'm assuming neither of those will happen, at worst it'll show a no-data-available error, but whether that happens and how bad it is remains to be seen once we do a trial run.

You can not determine security properties with a trial run.

[Siwastaja]

Data integrity is trivial to solve with a CRC. Chances are it is difficult to impossible to actually receive corrupted data, as any existing code (or even HW peripherals such as the RADIO peripheral in nRF52) already implements CRC. If by incorrect "old" is meant, then that is trivial to deal with a timeout and "N/A" display and becomes a nuisance only.

It sure is possible to make mistakes when handling CRCs or missing data, but the fact that in a wireless network you see a lot of missing data means you are likely to test that piece of code much sooner. On the other hand, if you assume that RS485 is robust and modbus polling infallible, you are guaranteed to fail one day.

So:

You can not determine security properties with a trial run.

Did you post to a wrong thread? I fail to see any connection to what we are discussing. Totally orthogonal. Do you have anything to say?

[zilp]

Data integrity is trivial to solve with a CRC.

No, it isn't. There is a reason why TLS uses HMAC and AEAD costructions and not CRCs.

You can not determine security properties with a trial run.

Did you post to a wrong thread?

No, I didn't.

I fail to see any connection to what we are discussing. Totally orthogonal.

Then look harder?

Do you have anything to say?

Do you have anything to ask?

[5U4GB]

You can not determine security properties with a trial run.

What do security properties have to do with this?  The intent is to determine whether the setup can reliably, or at least semi-reliably, retrieve Modbus telemetry for display on a dashboard.  As someone else has pointed out, I think you may be posting to the wrong thread.  Or perhaps replying to messages that no-one else can see.

[zilp]

You can not determine security properties with a trial run.

What do security properties have to do with this?  The intent is to determine whether the setup can reliably,

Security is one factor that determines reliability. If an untrusted party can change the display due to lack of security, then the display is not reliable.

[5U4GB]

For anyone else finding this thread, someone PM'd me to mention that you can also get Modbus RTU to TCP over WiFi modules which address the problem in a slightly different manner, made by Shanghai High-Flying Electronics so not the usual no-name stuff.  Never tried one but he was quite happy with them.

[zilp]

For anyone else finding this thread, someone PM'd me to mention that you can also get Modbus RTU to TCP over WiFi modules which address the problem in a slightly different manner, made by Shanghai High-Flying Electronics so not the usual no-name stuff.  Never tried one but he was quite happy with them.

For security reasons, it's probably better to use an adapter to TCP over (wired) ethernet and a separate WiFi bridge, as the wireless part is very exposed, but also a standard (consumer) product that's easy to swap out if vulnerabilities are discovered, be it in the particular product, or in the respective WiFi standard.

[5U4GB]

So I've now got a test setup running with the DIN-rail-mount devices I linked to in my first post, the whole thing worked on the first go, it's a transparent wireless extender for modbus RTU signalling.  Given that nothing ever works straight out of the box I'm still waiting for the roof to fall in or a plague of frogs or something to turn up.

They're also pretty useful for testing purposes before you spend a lot of time running wire, you can easily check everything's working as expected first.

[Georgy.Moshkin]

edit: mine was Ethernet, not wireless. Problem with bridging through MCU peripheral ports is that inter-byte timings are lost, and some equipment/software just shows communication errors. Plus no need to know baud rate or invent some auto-baud workarounds.

I worked on Ethernet serial bridge project in 2022, STM32H7B0+W5500 and ended up with gpio input capture approach. Instead of using MCU serial port, perform capture of GPIO RX high/low state timings using DMA and "replay" them at TX. I think it can be compressed and sent over radio channel. MCU is powerful enough to run AES in software to protect the channel if needed

[5U4GB]

So you couldn't just use the STM32H7x USARTs at the other end to reconstruct the original signal?  Or am I misunderstanding something?

[Georgy.Moshkin]

I didn't used H7 usarts for two reasons. First is that inter-byte delays are lost after data is received to MCU's internal buffer, and then sent away. Second is that STM32 H7 was isolated from 7 output ports by 7 digital I2C isolators (only SDA an SCL).  Each port has it's own small MCU with single usart enabled. Serialization/de-serialization is to pass 8 signals of DB9 through single isolator. At first, I decided to do this to optimize cost, but it turned out that cost savings was negligible. But I still decided to go this route, because single line I2C isolator was never out of stock! And it kind of protected my design from copying, because PCB layout was useless without serializer firmware (which is readout protected). I haven't finished many parts, e.g. serializer/de-serializer on smaller MCU, only debug output of i2c serialized stream to usart. Bought old gprs external modem to test RI/CTS/RTS/etc signals. Around 100 meters of Ethernet cable to test w5500 connection. This is what was affordable. Also I examined one-star comments on Amazon for all kind of serial hubs, serial servers, serial boosters and 4/8-port usb to serial adapters. Found some interesting keyword trends, e.g. "485 over Ethernet" searches spike during beginning stage of covid19, and it was still a growing trend last time I've checked, but I couldn't figure out why is that (used mangools.com for my research).

To sum up, I think that best approach to build serial bridge is to make something very similar to logic analyzer, which buffers recorded waveforms through some channel (Ethernet, wireless) and then reconstructs this meandered waveform on the other end. It solves problems with baud rate changing products, products that rely on inter-byte timings, or have some hardcoded delays or algorithms that do not work if inter-byte timings are altered. If commercial serial bridge product will use some automatic baudrate, or change inter-byte timings, it will fail or work unstable with many hardware/software products.

[5U4GB]

I really don't know enough about low-level modbus details to be familiar with the issue you're describing, I know there are certain parameters you need to keep to for things to work but as long as both sides of the bridge keep within those bounds, even if the output side isn't an exact copy of the input side timing-wise, why would this be a problem?

[Georgy.Moshkin]

First time I experienced related problem around 10 years ago. There was a MOXA Ethernet to serial bridge, and sensor with a serial interface connected to it. Sensor configuration utility kept showing "Device not found" message. I was not so experienced then and did not found the problem. I had access to utility's source code (written in Delphi, I was pretty good with it), and was able to test that bytes are actually coming by outputting values to Delphi's "form1" caption, but couldn't fix "not found" error and was told that client is not going to buy the product. Second time it was a fiber optics to 232 bridge connected to camera with serial interface. When I clicked on GUI buttons quickly enough, I was able to garble video stream with random color pixels, and after few seconds camera froze and required reboot by power cycling. Maybe some memory was overwritten by serial data. It was very difficult to achieve the same failure with direct serial connection. To be fair,  in both cases problem is not with a serial bridge. But it doesn't matter, even if I prove that problem is caused by buggy software or some serial buffer overflow in firmware. I don't want to investigate what's wrong with those serial "servers", hubs and bridges, maybe they group bytes in packets, have some auto baudrate algorithms, etc. I just know that if I repeat exact waveform at serial bridge's output, it will work almost if it's a direct connection + some latency.

edit: I've read all those one/two-star comments on Amazon, it kind of scared, I was worried that my product will have similar problems. I couldn't afford to invest time and money into production, fulfillment services, and end up with a lot of refunds. The same about port-to-port isolation. I just knew from experience that some devices are not well designed, and if you plug them in without isolation (7 ports!), sometimes they glitch, can easily damage bridge port, reboot or freeze during static discharge on adjacent device, or during power cord connection, etc..

[5U4GB]

Ah, yeah, I've worked with some Moxa devices, they tend to focus on adding a million features all of them about 75% debugged so not too surprising that there can be problems.

Mind you they also have to work with a bazillion not-quite-to-spec random devices and not-quite-to-spec cable types and runs, so I can see that there'd be some issues that wouldn't be their fault.