I have a strange one here that I’m hoping someone can help me out with. My Linux laptops get WSJT-X hamlib error messages when I attempt to control my Yaesu FT817 with my new Digirig. I tested the same WSJT-X build number on my Windows 11 workstation and everything works as advertised. Troubleshooting further on the Linux laptops I noticed that if I disconnect the Digirig “audio” cable which is plugged into the FT817’s data port with the serial CAT still plugged in, both vanilla rigctrl and rigctl-wsjtx work correctly. If I plug both CAT and DATA cables back into the Digirig serial and audio cables respectively hamlib tools stop working correctly and the FT817 sometimes even goes into “PTT” tx mode and gets stuck. Problem tracks the same on 9600 or 38400 baud. Tested it with two Linux laptops with same results.
Anyone got any ideas? I usually have much easier serial /dev/ttyUSB0 experience working on Linux with Arduinos, Rpi, and other MCU. One idea I have is that there is some kind of difference in the serial port timeouts between the two OS.
Thanks in advance.
Does this happen while you don’t transmit?
Thanks for the reply.
Yes. The radio is idling in RX. Initially I was troubleshooting along the lines of this being some kind of grounding issue or EMI between the Digirig, cables, and the FT817. I pull back from this once I noticed the Windows machine operated without error.
Last night I was able to get the Linux laptops to work FT8 using WSJT-X more reliably by disabling the rig CAT control, just using the PTT set to RTS on /dev/ttyUSB0 and manually tuning the radio. If I unplug the data/audio cable from the Digirig and I can re-enable hamlib rig control and change radio settings correctly.
I might hook up a scope and signal analyzer this weekend to see if I can find some more clues as to what is going on.
If issue only manifests during the transmit then it is related to RFI. You can confirm that by trying TX with zero power and/or into a dummy load. Please refer to the corresponding section of the troubleshooting guide for possible solutions.
Update for this post. I finally got a chance to spend some time troubleshooting this issue. Rebuilding the data cable fixed it.
It appears to have been caused by the problems with the Yaesu data cable Mini DIN6 pin 3 PTT wire. I had received a bad data cable in my initial delivery. It had a problem with RX Audio pin 5 not being connected. K0TX promptly replaced it with a new cable. I thought the new cable was working properly but I would get the CAT problems about 1/3 times on transmission. All DIN6 pins and TRRS sleeve contacts Ohm tested successfully.
Since I still had the bad data cable I decided to pick up a short DIN6 patch cable from a local computer parts supplier and see if I could rebuild a working cable without the pin 3 PTT connected. Clipping the TRRS end off the bad data cable and continuity testing showed it good. The same test on its DIN6 end failed. I then took the working TRRS end and spliced it into the half of the new DIN6 patch cable. Plugging it all back into the DigiRig and FT817, all is working as advertised.
I still have the replacement cable. Since its continuity tests good, I suspect there might be something up with RFI between the FT817’s data PTT port pin and the DigiRig’s audio (data) TRRS port.
Hope this helps someone else. I am now using my Linux laptop, DigiRig, and FT817 without any special deviations from what other Hams have posted on the internet. Love the small form factor of the DigiRig.
Thanks for the update. Glad to hear you found a solution.
Yeah, sounds like RFI issue if the cable continuity checks out bit results are different between the stock and homebrew cables. Just a different length can be a factor depending on the band you are operating. I would still suggest looking at improving SWR and RFI mitigation so more power gets on the air and less of it warms up the shack.