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.
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.
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?
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.
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/
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.
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.
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.
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.
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.
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.
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.
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.
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?
@ 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.
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
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.
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.
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?
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.
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.
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.
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?
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?
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.