I’ve been using my TS870 for FT8/FT4 for the past few weeks, no problems at all. Come to try today, my transmits are starting late at about 8 seconds every time. Previously, it was moreso around 4-5 seconds into a cycle, which was a bit more acceptable. My computer’s clock is synced, i’ve got WSJT-X set up as follows:
/dev/tty/USB0 (digirig)
57600 baud
8 data/1 stop bits
no handshake
RTS PTT (/dev/tty/USB0)
Rig split operation
This works, but consistently will have 8 seconds of delay. I also was able to get it working with 8 seconds of delay via the same settings listed as above, but instead of no handshake and RTS PTT, I utilized hardware handshake and CAT ptt. I am aware of the other post indicating that a ts870 may require a separate adapter for the RS232 cable, but I have been using the one available for purchase on the digirig store, the DB9 set, and as mentioned previously it was working alright before.
I have no clue what could be causing this delay, besides maybe the RTS/CTS cable issue. Anyone out there got any ideas?
If using PTT by RST the radio is keyed up via the hardware line and there should be no CAT retry related issues. You can check if radio responds immediately to the hardware PTT line by shorting sleeve to ring2 on Digirig’s end of the cable as demonstrated here:
Upon shorting the 2nd ring, the radio keys up immediately, as expected. Also, WSJT-X has no fails on the CAT test. The PTT test, though, still takes several seconds before it actually activates the PTT on the radio, and before the button goes red in WSJT-X. This is a screenshot of my current settings in the actual software as well.
Not necessarily related, but Data/Pkt may be a better option.
Do you have a PC to try the same there to see if the delay follows the interface or stays with the computer?
I can try another laptop, my actual desktop is about 100ft away on the other side of the house. Does data/pkt work on the 870? I thought it didnt have a dedicated mode for that?
Upon plugging my headset into the digirig’s audio out, I can also tell that the delay comes in at 8 seconds there as well, where the tone doesnt actually start playing for until that period completes.
Thank you for the additional info. Interesting that the delay affects both COM port (PTT) and the sound card (audio) even though they are two separate devices downstream from an internal hub.
Right now I’m using an unshielded anker cable, but I’ve wrapped it around a toroid and put a few snap on ferrites on it, as it was previously experiencing RFI. I’ve also ordered the short usbc to usbc cable, and am currently awaiting the arrival of that.
Quick update: I snapped a few ferrites on a different shorter cable (still unshielded), and briefly experienced a shorter delay, for it just to slowly approach that 8 second mark again.
Another odd discovery, dropping my baud rate from 57600 to 9600 has dropped the delay to 3 seconds, for whatever reason.
Update to discovery: It is also now oscillating between 3 and 8 seconds. It also seems to drop the delay by a significant margin every time I change a setting?
The CAT control should not be a factor with PTT set to RTS. In fact you can set rig in the list to “none” and disconnect the serial cable altogether. The audio and PTT should still work.
I turned rig to none, and just like that PTT is working instantly with no delay whatsoever. Thank you so much for all your help!
Now, is there any way I can have WSJT-X still controlling the rig’s frequencies, so I don’t have to manually set them, or will I have to set them myself, because of CAT having its troubles?
73
That should persist with the CAT back on unless you select fake split which will attempt to change the VFO on the radio prior to keying it up. This shouldn’t be the case with rig or none options.
So, basically, I have to turn CAT on to change bands/change my tx/rx frequency, unless I set them with the dial myself, is what I’m understanding? I never used fake split anyways, it seemed to cause an even higher delay when I had CAT turned on.
Yes, CAT is an optional convenience feature allowing you to do some transceiver initialization and set VFO from the computer. Sounds like the delay is caused by the retries in the serial communication. You can try running CAT with omnirig or flrig for faster retries.
So, I wasn’t able to get flrig to properly work. It would always fail on the init, but if I tried to change the frequency through flrig the command would properly send and show up on the transceiver? This doesn’t allow me to properly switch over to using flrig, though, as it isn’t actually creating a link that I can hook into WSJT-X, due to it not initializing properly.
It always errors out with transceiver not responding, and if RTS/CTS is enabled the PTT goes on and wont go out until I either reboot the rig, or start a new init with RTS/CTS off.
Unfortunately I wasn’t able to get OmniRig to open, and FLRig just gives me an error of transceiver not responding. Though, I have recently been messing around in rigctl, and have noticed that whenever I try to run a set command (set PTT for example), it always attempts to run through the command, will succesfully complete, but the transceiver will not actually update it’s state. Here’s a max verbose log from rigctl, showing the attempt to set PTT to RX (it opens in TX for some inexplicable reason?)
