|
Post by w8zf on Nov 20, 2022 20:15:18 GMT
I am using an IC-7300 with DX Lab. I have JTDX configured to use this suite for the radio control, and I have DX Lab's Commander running.
Problem: JTDX does not reset the split mode and/or split frequency when changing bands.
How to reproduce: 1. Software/equipment: DXlab, SpotCollector, IC-7300 2. DXlab commander set to IC-7300 and functioning normally. 3. JTDX radio set to "DX Lab Suite Commander" and Split Operation set to "Rig" 4. Tune IC7300 either programmatically or manually to operate VFO_A=10.110, VFO_B=10.113 and "Split" 5. In JTDX, select 30M DXpedition frequency 10.133
At this point, the radio is programmed to VFO_A=10.133 and VFO_B=10.113 and Split is still checked. This will cause my transmit FT-8 signal to be sent on the wrong frequency, and some combinations could potentially result in illegal out-of-band transmissions for FT-8 mode.
Note, clicking on an FT-8 spot in SpotCollector correctly clears the radio Split state.
It seems that this is a bug or omission in JTDX. I propose that it should NOT assume the radio is in transceive mode and should always clear split operation whenever band and mode are selected.
Is there a way to submit a ticket to request the developers to look at this?
Thanks, Dean W8ZF
|
|
|
Post by w9mdb on Nov 20, 2022 21:57:03 GMT
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
|
|
|
Post by w8zf on Nov 20, 2022 23:19:48 GMT
Hi Mike, I'm running JTDX version 2.2.0-rc155.
Respectfully, I don't understand (nor agree) with your statement "that is the best way to operate."
I have written software, I wrote DXbase. I own and use other software, all of which either properly sets the split when they are supposed to, or disable it when there is no input indicating the transceiver should be in split mode. The safe assumption is that without specifically polling the state of the split, you don't know how it is set and you should disable it, or set it according to a explicit instruction to operate in split mode.
Are you one of the developers?
Thanks, Dean
|
|
|
Post by w9mdb on Nov 20, 2022 23:36:56 GMT
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.
|
|
|
Post by w8zf on Nov 21, 2022 0:19:38 GMT
Thanks, Mike! I misunderstood what you meant about split being the best. You meant the best for JTDX, got it. I'll check later or tomorrow to see if JTDX disables or reconfigures the split once it transmits. My recollection is that it does NOT, but I'll verify. Thank you and 73! Dean W8ZF
PS I don't have WireShark configured for USB on my shack PC, but after I confirm the above, I'll take a look at the messages going back and forth to see if the radio is being polled with regards to it's split status.
|
|
|
Post by w8zf on Nov 21, 2022 3:49:40 GMT
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
|
|
|
Post by w9mdb on Nov 21, 2022 4:08:17 GMT
It depends on where your waterfall offset is. If the offset is 1500-1999 then VFOB=VFOA If 1000-1499 then VFOB=VFOA-500 If 500-999 VFOB=VFOA-1000 If 0-499 VFOB=VFOA-1500 If 1500-1999 VFOB=VFOA+500 If 2000-2499 VFOB=VFOA+1000 If 2500-2999 VFOB=VFOA+1500 The frequency on VFOB will be set the 1st time you transmit on band change of if you change the waterfall offset. It is a bit disconcerting to not see VFOB change on band change. Perhaps that should be done to avoid confusion.
|
|
|
Post by w8zf on Nov 21, 2022 16:40:01 GMT
Thanks, Mike. Here's what I am seeing. I understand what is SUPPOSED to happen, but here's what actually happens with my installation. (JTDX is using DXLab's Commander for radio control):
I get a different offset table than you gave above. This was obtained by increasingly moving the TX cursor in the waterfall from bottom to top:
TX Cursor
| VFO_B Offset | 0-499 Hz
| -1500 Hz
| 500-999 Hz
| -1000 Hz
| 1000-1499 Hz
| -500 Hz
| 1500-1999 Hz
| 0 Hz
| 2000-2499 Hz
| +500 Hz
| 2500-2999 Hz
| +1000 Hz
| 3000-
| +1500 Hz
|
Also, while the above offsets are being programmed in VFO_B, IN TRANSMIT MODE, JTDX is not using the offset frequency.
STEP
| ACTION | VFO_A | VFO_B | SPLIT | JTDX F | JTDX TX
| JTDX RX |
| 0
| (Initial Condition)
| 7001.00 | 7003.00 | N | 7001.00 | 300 | 2600 |
| 1
| JTDX band change to 24.915
| 24915.00 | 7003.00 | N | 24.915 | 300 | 2600 |
| 2
| JTDX 1st TX Enable
| 24915.00 | 24915.00 | Y
| 24.915 | 300 | 2500 | JTDX not using -1500 Hz offset!
| 3
| JTDX 1st TX DISable
| 24915.00 | 24913.50 | Y | 24.915 | 300 | 2600 |
| 4
| JTDX 2nd TX Enable
| 24915.00 | 24915.00 | Y
| 24.915 | 300 | 2600 | JTDX not using -1500 Hz offset!
| 5
| JTDX 2nd TX DISable
| 24915.00 | 24913.50 | Y | 24.915 | 300 | 2600 |
|
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
|
|
|
Post by Bill VE3BOK on Dec 30, 2022 2:01:28 GMT
I think my JTDX issue is related so I'll post it to this discussion.
In a nutshell, when the JTDX Radio tab Split Operation is set to Rig, JTDX will not put my rig into split mode.
What it does instead is switch my rig over to VFO B from VFO A, but only uses that single VFO, using the so-called "offset" frequency for both Tx and Rx.
For example, if I'm on 10 metres, with JTDX Tx frequency set to 2251 and Rx set to 645, rig's VFO B and JTDX both display 28.07500 (i.e. +1000 kHz from what should be the Rx frequency) during both the Tx and Rx portions of the cycle. VFO A is inactive and not displayed.
WSJT-X on the other hand works as expected in Rig Split mode, activating the rig's Split feature when starting the program, adjusting the VFO B Tx offset in the correct 500 KHz increments based on the Tx audio frequency setting for a transmission, switching back to VFO A for Rx, and lastly turning off the rig's Split feature when exiting WSJT-X at the end of the day's operating session.
It appears to me, being the simple-minded person that I am, that when JTDX is set to Rig Split mode, it is sending incorrect command(s) to the radio.
JTDX works with no issues using Fake-it mode, but my preference is to take advantage of my rig's dual VFOs by using Rig-split mode, as I am used to in WSJT-X.
I've been through and compared all of the settings between the two programs multiple times and cannot find anything that fixes the problem. Perhaps I'm overlooking something?
My setup is as follows:
Rig: Kenwood TS-590S (not SG) utilizing USB for both rig control and audio JTDX version: 2.2.159 WSJT-X version: 2.5.4 Computer OS: Andy's Ham Radio Linux, version 25, based on Xubuntu 22.04 LTS
Any help is appreciated, and if I should provide more info, please ask.
Thanks in advance, and 73,
|
|
|
Post by w9mdb on Dec 30, 2022 4:22:11 GMT
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
|
|
|
Post by Arvo ES1JA on Dec 30, 2022 11:36:14 GMT
JTDX polls and also sets split mode when rig split is in config or clears split mode when fake_it is in jtdx config. VFO B freq is changed ( when needed ) on starting TX All this is working so with hamlib for supported rigs ( I test ic7100) or with tci connection. Should work also DXlab and HRD, I can't test those, because are win shit only software. Support for those have not changed long time in jtdx.
Arvo ES1JA
|
|
|
Post by Bill VE3BOK on Dec 30, 2022 22:28:45 GMT
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
|
|
|
Post by w9mdb on Dec 30, 2022 22:38:21 GMT
|
|
|
Post by Bill VE3BOK on Dec 31, 2022 4:42:06 GMT
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 :-)
|
|
|
Post by w9mdb on Dec 31, 2022 4:55:06 GMT
You can always back up the libhamlib-4.dll you have and change it back.
|
|