No "SPLIT" option for radio control and loss of radio

Split operation is meant to stay on during band changes as that is the best way to operate.
What version of JTDX are you running.
And it won't change the split frequency until you transmit.

Mike W9MDB

Rig split is considered the best as it has less delay involved than Fake It.
Either of those modes prevent problems with bandpass and potential harmonics.
I'm the maintainer of Hamlib and a contributor to WSJTX and JTDX.
Split should be getting polled...I'm pretty sure JTDX does that.
JTDX should(?) be setting split mode and USB/Data mode on every transmit.
So if you turn split off on the rig JTDX should force it back on next transmission.

Mike,
I tried this out and discovered that JTDX does NOT clear the split (nor apparently check the state of) the split mode. But what it DOES do is set both VFO_A and VFO_B to the same frequency. This is functionally the same thing. I haven't tried all the combinations of mode changes to/from FT-8 to see if this always works correctly, but setting separate mode with the same frequency in both VFOs is perfectly fine (other than when you change bands and try to operate your radio in a non-digital mode, the rig will still be set to SPLIT with VFO B left on the last FT8 frequency). So I guess much like pure analog operation, it is my responsibility to turn off split when I change bands/modes from FT8.
Regards & 73,
Dean W8ZF

For this test, a call was entered into DX Call and GenMsgs was clicked.
The behavior is different when a CQ is sent (JTDX places the receive offset on the transmit offset)

According to my VFO readout in Commander, JTDX is NOT programming the offset per the table you listed. Am I missing something?

Thanks & 73!
Dean W8ZF

Your table is correct -- not sure what I was thinking when I wrote mine.
VFOB should change whenever you change offset in the 500Hz increments -- can you verify it does that?
Then...does VFOB change again when you transmit?
Please use the latest hamlib from here: n0nb.users.sourceforge.net/
Please place this file as described below
www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0

C:\Users\[username]\AppData\Local\WSJT-X
The WSJT-X_Rigcontrol.log file will be in the same location

For Linux put it in
~/.config
The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X

For MacOS put it in
/Users/[username]/Library/Preferences

Restart WSJT-X and duplicate the problem.
Shut down WSJT-X

Then send me the WSJT-X_RigControl.log file
Mike W9MDB

Hi Mike,

Thanks for your quick reply! I've just completed a whole bunch of testing and writing down of results, but I'll spare you the detail and give you the Reader's Digest version.

The short answer to your second questions is yes. VFO-B and the corresponding JTDX display changes on every transmission, down or up, by the number of 500 Hz increments dictated by the Tx audio frequency setting in JTDX. However, they do not revert back to the previously set frequency when switching back to Rx mode. Instead, the changes accumulate; every transmission moves it further and further away.

Your first question is more complicated to answer. Yes VFO-B changes in increments of 500 Hz. But, not in the way that it should. If I start out with my VFO-B on 50313.00, and move JTDX Tx audio anywhere between 1500 and 1999, there is no change to VFO-B; so far so good. If I then set JTDX Tx to 2028, the VFO-B display increases by 500 Hz to 50313.50, as expected. But if I then set it to 2561, VFO-B and JTDX displays jump up by 1000 more Hz to 50314.50, which is 500 Hz higher than expected.

If I then try to move JTDX's Tx audio frequency back down to say 2072 Hz, the VFO-B display jumps up (yes up, not down) again by another 500 Hz to 50315.00. If I then move Tx further down to 1615 Hz, the VFO-B and JTDX displays stay at 50315.00.

In the other direction, beginning from 50313.00, setting Tx to 1340 drops VFO-B to 50312.50, as expected. Then setting Tx to 853 drops the VFO-B and JTDX displays by a further 1000 Hz to 50311.50, again 500 Hz further than expected. Next, setting Tx to 396 drops the VFO-B and JTDX displays to 50310.00, whereas it should be 50311.50.

Another test, again beginning at 50313.00 with Tx and Rx audio in between 1500 and 1999. If I now jump directly to Tx at 385 Hz, VFO-B and JTDX display correctly at 50311.50. BUT, if I then move the Tx to somewhere else in the 0-499 Hz range, say 314 Hz, the displayed frequency again drops by 1500 Hz to 50310.00. It should not have changed at all.

Keep in mind too that all this is happening in so-called "simplex" mode, i.e. tranceiver Split has not been activated.

I've not yet done much about the remainder of your post other than to check my current hamlib version (4.5-git.20220502 amd64), and look for the WSJT-X_RigControl.log file, which I can't find. I'll keep looking,

73, Bill

No, my version is 4.5. The version your link points to is 4.6, which appears to be the latest beta version according to the description at the top of the page.

If I follow the Wiki link at the top of that page, it takes me to the latest stable version, which is 4.5.2, so mine is a bit (but not horribly) behind. And it works with WSJT-X without issue.

I'll have a go at upgrading to 4.5.2 tomorrow to see if it makes any difference, but I'm kinda reluctant to become a beta tester for hamlib 4.6 given my lack of experience in such things. I don't wanna break anything else :-)