USB RS232 relay – can’t read response in Linux

[Joe England]

Hi All.

I’ve scoured the Internet for a solution to this but can’t find anything.

I have one of these, https://www.kmtronic.com/usb-relays.html/usb-relay-controller-one-channel-pcb.html, and am trying to get it to report its status, open or closed.

The funny thing is that it works with CuteCom but not when I try to operate it via the command line. It will switch on and off, in response to echo -e "\xff\x01\x01" > /dev/ttyUSB0 and echo -e "\xff\x01\x00" > /dev/ttyUSB0, respectively. But, when I send it echo -e "\xff\x01\x03" > /dev/ttyUSB0 which is supposed to cause it to return its status, i.e. different byte sequences for off or on, it doesn’t. Or, more accurately, the second terminal that I have running in the background with cat -v /dev/ttyUSB0 doesn’t show anything.

As I say, it does work with CuteCom but I need a non graphical solution as I am running it on a Raspberry Pi via SSH. Also, it seems to be transmitting in response to the status request, echo -e "\xff\x01\x03" > /dev/ttyUSB0, because the “RX” LED on the board flickers, which it only does in response to this command, but my terminal just isn’t seeing it (the byte sequence returned doesn’t map to ASCII but I should be getting some garbage at least).

Also, the manufacturer has a shell script on their website, “usbrelaystatus.sh” at https://info.kmtronic.com/kmtronic-usb-one-relay-linux-test-script.html, which is basically doing the same thing except, rather than a second terminal, it has a background process running cat, sending the output to a temporary file which it then reads but that isn’t working either, the file is coming back empty.

I have noticed that, when CuteCom is running, if I try to send a command to the device via the terminal then it throws an error “bash: /dev/ttyUSB0: Device or resource busy”. In contrast, it won’t throw that error while I’m running the C program that I wrote to try to grab the response.

The device is a couple of years old (ironically, I bought it because I thought that RS232 would be easier to work with than HID) so presumably it worked then. It is doing it, or rather not doing it, on both my Ubuntu laptop and my Raspbian RPi so I’m wondering whether it’s been caused by a kernel update.

Any ideas?

[Adrian Godwin]

The second cat will try to read a whole line of input before it prints anything. The response doesn't include a line-end so it waits forever. You need to set it to raw mode with a limited wait time, minimum line length and repetitive reads. Shell script can work for streamed data but isn't so good for short query-response commands. You're probably better off with custom code (if you're comfortable with C or Python etc) or with something designed for interacting with terminals like tcl.

The busy error is because cutecom has opened the device exclusively and your code hasn't.

--
You received this message because you are subscribed to the Google Groups "London Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to london-hack-sp...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/london-hack-space/97c637eb-7070-4c45-9d59-c8507ae6b541%40googlegroups.com.

[Rowan Hoggarth]

This is the normal behaviour: cat is waiting for a line feed so is not printing anything. There probably is a way to disable this but don't know it off hand. Alternatively access the serial port from your favourite programming environment, you'll probably find this kind of thing is easier to play with without all the unwanted default terminal behaviour IMHO.

Only one process can have the port device open for writing, this is where the errors you mention come from, the terminal program opens the device for writing even if you only intended to peek at what was coming back.

If you have written a c program to read the response and can't see it, it's possible that you have used a function like sprintf or similar to parse the incoming stream? Possibly also waiting for a new line..? Post a code snippet and we might spot the issue?

Hope this helps,

R

--

[Joe England]

Super thanks to Adrian!

His PM prompted me to check that the port was set to ‘raw’.

Being a bit shaky on the foundations of Unix/Linux (I am currently working my way through The Design of the Unix Operating System by Bach) I Googled it and found https://acassis.wordpress.com/2016/01/22/configuring-linuxs-serial-port-to-raw-mode/

I followed the steps given there to set up my second, monitor, terminal as follows:

$ sudo stty -F /dev/ttyUSB0 raw

$ sudo stty -F /dev/ttyUSB0 -echo -echoe -echok

$ sudo stty -F /dev/ttyUSB0 9600

$ cat /dev/ttyUSB0 | hexdump -v -e '/1 "%02X "' -e '/1 "%c\n"'

...and it works!

I only really want to be able to check the status for debugging so I’ll work up a shell script based on this.

Thanks to both of you for your responses.

To unsubscribe from this group and stop receiving emails from it, send an email to london-h...@googlegroups.com.