Problems with Digirig and Kenwood TM-V71A serial access

, , ,
1

I have a Kenwood TM-V71A and a recently purchased Digirig with the Kenwood cables (Kenwood TM-V71A cords for Digirig Mobile – digirig). I’m running into conflicts between the use of RTS for PTT signalling and serial communication with the radio.

With both the serial and audio cables connected, any attempt to use rigctl to interact with the radio triggers PTT. I can unplug the audio cable to avoid that issue, but that certainly makes CAT tools like rigctl less useful.

It looks like Kenwood’s MCP-2A software requires RTS/CTS signalling: without proper handshaking it simply won’t communicate with the radio.

I’ve been able to work around the problem with MCP-2A by (a) running MCP-2A in a virtual machine with a serial port connected to a unix socket /tmp/w10-serial-proxy, and then (b) using socat as a proxy to the actual serial port with rts/cts explicitly disabled…

socat -x -v \
  /dev/ttyUSB0,b9600,crtscts=0,raw,echo=0 \
  unix-connect:/tmp/w10-serial-proxy

…That’s enough to get MCP-2A working, but it’s ugly.

To get Kenwood’s firmware update software to run successfully, I had to disconnect the Digirig completely and replace it with a dedicated serial cable.

All of this makes the serial support in the digirig substantially less useful. It looks like the optimal solution is to disconnect the serial connection from the digirig and just use the digirig for audio/ptt, and keep a dedicated serial cable around for CAT control.

Am I missing something obvious here?

Thanks!

2

Hey larsks!

I’m taring out (what’s left of) my hair troubleshooting the same thing here interfacing with my new-to-me FT-847.

The best I’ve found so far is setting --set-conf="rts_state=OFF" when starting up rigctl (or rigctld) and that will make rigctl a tad more useful. The problem however rigctl still asserts the RTS pin for a brief moment on startup. Works, but in the case of your v71, you’ll be throwing a carrier briefly on whatever frequency you happen to be tuned to on the “data” band, which could be could be kerchunking a repeater - not exactly clean.

Additionally, setting --set-conf="serial_handshake=None" is supposed to disable the handshake completely, however I don’t see any effect.

I’m on Debian stable, hamlib version 4.5.4-1+b1 … IMHO … we’ve found a bug in hamlib … The proper result of --set-conf="rts_state=OFF" or --set-conf="serial_handshake=None" should override what rigctl has in it’s local database and preform NO handshaking - period.

Hope this helps.
- 73, Mike KC1MJP

1 Like
3

I’m hitting this issue with more than just rigctl, so I ended up writing an LD_PRELOAD-able library that forces RTS low when the serial port is opened. You can find it at GitHub - larsks/force_rts: An LD_PRELOAD-able library to set RTS low when open()-ing a serial port.. In my .bash_profile I have:

export LD_PRELOAD=$HOME/force_rts/force_rts.so
export FORCE_RTS_DEVICES="/dev/radio:/dev/ttyUSB*"

This overrides the open() system call so that whenever a program calls open() on a matching serial port, we immediately set RTS low. Seems to solve the problem both with rigctl and with some custom software I’ve written.

I haven’t tested it with Wine-based software yet.

1 Like
4

Yep! Definitely not rigctl, I might have been a bit too early to call that into question. Though I did go down a rabbit hole late last night (way too late actually), landing on Linux Kernel syscall web pages.

Looks like POSIX compliance is the issue here. POSIX requires the RTS pin to be asserted when the port opens. So Linux, and other POSIX-compliant Operating Systems, will exhibit the same behavior with our technically non-standard use of the DTR and/or RTS lines. I assume windows does not have this issue unless POSIX compliance is enabled, maybe??. I cannot confirm that however, the only windows box I have is controlled by work lol…

I actually found your github via post elsewhere this morning searching around while waiting other tasks to complete. Just gave it a shot and it seems to work great! I’ll be updating my rigctld script around your library.

Not sure what distro you’re on, but I can confirm your code works on Debian Stable (currently on 12.2). Though this being a POSIX thing, it will likely compile and work on other *NIX OSes as well.

Long Live FOSS!!
73, Mike KC1MJP

5

I have this same issue with the software not keying PTT. I went through and checked the audio settings in control panel/sound and everything seems to be okay there, but I notied Windows made the audio device the default communications devide and I was unable to change that setting after several tries. The Winlink VARA FM setup is correct, because it connects with the DigiRig, but no Tx.