Wireless bridging for Modbus/RS485 devices

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