I've got some Amateur Radio projects in the pipeline that will require the ability to turn off the radio remotely in the event of a fault developing. This needs to be out-of-band and accessible to more than one "closedown-operator" so if the main operator isn't available, someone else can shut the station down.
The projects all require a computer of some sort, so I had an idea that I could use a USB serial relay to switch the power to the radios off, assuming they'd be easy to use and compatible with both standard form factor PCs as well as SBCs like Raspberry Pis.
I quickly realised this wouldn't be ideal as the situation might arise where the computer has crashed and left the radio transmitting, and it wouldn't be possible to switch off the relay, so I needed an alternative. As it happens I was also planning on including a Mikrotik router in these builds as they've gained the nickname "The Swiss Army Knife of Routers" and allow you to quickly setup tunnels and VPNs which are useful for remote access. Some models also have a USB port, and basic support for USB serial adapters, so I bought a few from AliExpress to test them out.
I started off testing the un-named model. which I was really hoping would work as it's got a sensible USB B port, and 4 usable mounting holes. Unfortunately it was a non-starter as it shows up as a HID (Human Interface Devices) which Mikrotik has no support for. Schucks.
Next up, the LCUS-1 which is based on the CH340G. It successfully showed up as a serial device which was a good sign. After looking around online it turned out the best way to send commands over serial to the device was to abuse the ppp-client interface, by adding a ppp-client that uses the serial device, but is otherwise disabled:
And success, the relay clicked on. Note that at-chat is expecting to a response back, hence the reply timeout error, but that can be ignored.
Okay, now to turn it off. Its the same process again but this time the command is 0xA0 0x01 0x00 0xA1. And... nothing. No click, no action from the relay. Oh dear.
So I moved onto the LCUS-2, also CH340 based with the same process, and same command for the channel 1 relay. And the behaviour was exactly the same. I could turn the relay on, but I couldn't turn it off.
Before going any further I thought I should try the relays out on an actual computer. To send the command its just a case of sending it like so, which turned the relay off as expected:
At this stage it became clear I'd have to figure out what the Mikrotik was actually sending over serial, so I found a pair of CH340 USB serial modules and connected them to each other with Rx and Tx swapped. I stuck one into the Mikrotik and the other into a PC and created a crude Python script to print the data received over serial as Hex.
So, I plugged things in and ran the ON command and it appeared as expected, with a CR character tacked on the end. But as you can see, the second OFF command was truncated, with the 0x00 and everything after it missing.
I tried a few different permutations including 0x00 and the behaviour was always the same, the 0x00 and everything after it wasn't being sent. I thought it might be a bug, but someone on the Mikrotik Forum pointed out it's a Null Terminator which is why it was being sent.
As at-chat is the only way of sending commands to serial devices from the Mikrotik itself, it seems I'm out of luck, and any serial adapter using these commands will also fail. Note I had the same behaviour on RouterOS 6.48 and 7.8, so it's not just a case of upgrading either.
So, overall this experiment was a failure which is a great shame as this would have been a very useful feature indeed.
No comments:
Post a Comment