Re: [wsjt-devel] VFOs reversing (Edited);
Sam W2JDB -Original Message- From: Sam W2JDB To: mdblac...@yahoo.com ; wsjt-devel@lists.sourceforge.net Sent: Wed, Nov 17, 2021 10:00 am Subject: Re: [wsjt-devel] VFOs reversing Hi Mike, Sorry about side tracking this subject. On the TS590S, Split gets turned on as soon as the receive VFO is not the same as the transmit VFO.So as soon as you set FR1 after you set FT0, split gets turned on. You are absolutely correct about not being able to target the VFO when setting the mode on the TS590S(G).Dumb but true. And far be it from me to tell you how to code this, I was just trying to let you know about the errant behavior that I found. However, you may want to consider the following logic: Test the Split indicator in the IF message. If its on, you can bypass the need to set FR0 and FT1. The reality is that you really don't need to do that anyway if you also follow the logic below. Send the command 'FT' to find the VFO that is going to transmit.Send the TX Frequency to the appropriate VFO. Set FR to the same as FT, then set the mode (MD) and data (DA). Now Set FR to be not equal to FT then set the mode (MD) and data (DA). As per your previous explanations, interleave the 'ID' command as necessary. Now you send the 'TX1' command. I believe that might be a cleaner more efficient process and if the useruses VFO-B to start, this process that will not change that setting. Theywill always receive on the VFO they selected. Again my apologies for sidetracking this topic. 73, Sam W2JDB -Original Message- From: Black Michael To: wsjt-devel@lists.sourceforge.net ; Sam W2JDB Sent: Wed, Nov 17, 2021 8:06 am Subject: Re: [wsjt-devel] VFOs reversing This thread has side tracked.What rig are you running? Is it possible to set a different mode on VFOB? If not we can put some logic in to avoid setting mode on VFOB. Most rigs can set VFOB to a separate mode but older rigs do not have targetable mode. FR1 is not supposed to turn on split on most rigs...it's a VFO change. FT is what turns on split.The FR1 is changing to VFOB to set the mode and to avoid strange rig flashing we do this:split offchange to vfobset mode change to vfoasplit on Mike W9MDB On Tuesday, November 16, 2021, 11:57:10 PM CST, Sam W2JDB via wsjt-devel wrote: Hi Bill and MIke, "and/or If Split is already set in the radio." Please disregard the comment about the current Split status of the rig. I forgot that in the response to the 'IF;' command, that message contains the split indication.My apologies. 73, Sam W2JDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi Mike, Sorry about side tracking this subject. On the TS590S, Split gets turned on as soon as the receive VFO is not the same as the transmit VFO.So as soon as you set FR1 after you set FT0, split gets turned on. You are absolutely correct about not being able to target the VFO when setting the mode on the TS590S(G).Dumb but true. And far be it from me to tell you how to code this, I was just trying to let you know about the errant behavior that I found. However, you may want to consider the following logic: Test the Split indicator in the IF message. If its on, you can bypass the need to set FR0 and FT1. The reality is that you really don't need to do that anyway if you also follow the logic below. Send the command 'FT' to find the VFO that is going to transmit.Set FR to the same as FT, then set the mode (MD) and data (DA). Now Set FR to be not equal to FT then set the mode (MD) and data (DA). As per your previous explanations, interleave the 'ID' command as necessary. Now you send the 'TX1' command. I believe that might be a cleaner more efficient process and if the useruses VFO-B to start, this process that will not change that setting. Theywill always receive on the VFO they selected. Again my apologies for sidetracking this topic. 73, Sam W2JDB -Original Message- From: Black Michael To: wsjt-devel@lists.sourceforge.net ; Sam W2JDB Sent: Wed, Nov 17, 2021 8:06 am Subject: Re: [wsjt-devel] VFOs reversing This thread has side tracked.What rig are you running? Is it possible to set a different mode on VFOB? If not we can put some logic in to avoid setting mode on VFOB. Most rigs can set VFOB to a separate mode but older rigs do not have targetable mode. FR1 is not supposed to turn on split on most rigs...it's a VFO change. FT is what turns on split.The FR1 is changing to VFOB to set the mode and to avoid strange rig flashing we do this:split offchange to vfobset mode change to vfoasplit on Mike W9MDB On Tuesday, November 16, 2021, 11:57:10 PM CST, Sam W2JDB via wsjt-devel wrote: Hi Bill and MIke, "and/or If Split is already set in the radio." Please disregard the comment about the current Split status of the rig. I forgot that in the response to the 'IF;' command, that message contains the split indication.My apologies. 73, Sam W2JDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
This thread has side tracked.What rig are you running? Is it possible to set a different mode on VFOB? If not we can put some logic in to avoid setting mode on VFOB. Most rigs can set VFOB to a separate mode but older rigs do not have targetable mode. FR1 is not supposed to turn on split on most rigs...it's a VFO change. FT is what turns on split.The FR1 is changing to VFOB to set the mode and to avoid strange rig flashing we do this:split offchange to vfobset mode change to vfoasplit on Mike W9MDB On Tuesday, November 16, 2021, 11:57:10 PM CST, Sam W2JDB via wsjt-devel wrote: Hi Bill and MIke, "and/or If Split is already set in the radio." Please disregard the comment about the current Split status of the rig. I forgot that in the response to the 'IF;' command, that message contains the split indication.My apologies. 73, Sam W2JDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi Bill and MIke, "and/or If Split is already set in the radio." Please disregard the comment about the current Split status of the rig. I forgot that in the response to the 'IF;' command, that message contains the split indication.My apologies. 73, Sam W2JDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi Bill,
Yes, Mike clarified the reason for that particular heartbeat in his last
message and thank you for that.
HI Mike: I downloaded the latest DLL and replaced the current one in the bin
folder and the results were the same. The previous test was done with a
replacement DLL that I downloaded on 11/12. In hope to mitigate the behavior
that I noticed with the original DLL that was installed with WSJT-X Ver 2.5.2
on 11/04 with the DLL dated 11/03.
One other point if you gentlemen allow me, I don't see where WSJT-X ascertain
which VFO A or B is current set to being used for RX and TX and/or If Split is
already set in the radio.
// Prepare for TX Cycle
00816 12:23:30:040 : >>: IF;00817 12:23:30:045 : <: IF7074000
-00620020010080;00818 12:23:30:046 : <<: IF7074000
-00620020010080;00819 12:23:30:050 : >>: FB;00820 12:23:30:052 : <:
FB7074500;00821 12:23:30:053 : <<: FB7074500;00822 12:23:30:056 : >>:
FR0;00823 12:23:30:056 : >>: FT1; // Split Turned On 00824
12:23:30:057 : >>: ID;00825 12:23:30:081 : <: ID021;00826 12:23:30:082 : <<:
ID021;00827 12:23:30:099 : >>: FT0; // Split Turned Off00828
12:23:30:099 : >>: ID;00829 12:23:30:099 : <: ID021;00830 12:23:30:099 : <<:
ID021;00831 12:23:30:130 : >>: FR1; // Split Turned On in reverse
00832 12:23:30:130 : >>: ID;00833 12:23:30:137 : <: ID021;00834 12:23:30:137 :
<<: ID021;00835 12:23:30:168 : >>: FT1; // Split Turned Off00836
12:23:30:168 : >>: ID;00837 12:23:30:168 : <: ID021;00838 12:23:30:168 : <<:
ID021;00839 12:23:30:200 : >>: MD;00840 12:23:30:200 : <: MD2;00841
12:23:30:200 : <<: MD2;00842 12:23:30:231 : >>: DA;00843 12:23:30:231 : <:
DA1;00844 12:23:30:231 : <<: DA1;00845 12:23:30:269 : >>: MD2;00846
12:23:30:269 : >>: ID;00847 12:23:30:269 : <: ID021;00848 12:23:30:269 : <<:
ID021;00849 12:23:30:300 : >>: DA1;00850 12:23:30:300 : >>: ID;00851
12:23:30:300 : <: ID021;00852 12:23:30:300 : <<: ID021;00853 12:23:30:331 : >>:
FR0; // Split Turned On - Back to normal 00854 12:23:30:331 : >>:
FT1;00855 12:23:30:331 : >>: ID;00856 12:23:30:353 : <: ID021;00857
12:23:30:353 : <<: ID021;
// Start TX Cycle 00858 12:23:30:385 : >>: TX1;
Sam W2JDB
-Original Message-
From: Bill Somerville via wsjt-devel
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville
Sent: Tue, Nov 16, 2021 10:16 am
Subject: Re: [wsjt-devel] VFOs reversing
Sam,
you have not understood my comments and the reason for the dummy command,
please read my explanation again.
73
Bill
G4WJS.
On 16/11/2021 15:00, Sam W2JDB via wsjt-devel wrote:
Hi Bill,
Any invalid command will result in a '?;' response, even a SET command. i.e.
if you send 'AC000' and the tuner is already in a 'AC000' state in reply to
'AC;' command, you will get a '?;' response. I used that example because I
ran into that problem and it took me a while to figure why/where that was
coming from.
73, Sam W2JDB
-Original Message-
From: Bill Somerville via wsjt-devel
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville
Sent: Tue, Nov 16, 2021 9:26 am
Subject: Re: [wsjt-devel] VFOs reversing
On 16/11/2021 14:07, Sam W2JDB via wsjt-devel wrote:
> I also wondering about the multiple
> 'ID' requests, is that your version of heartbeat ? Just wondering.
Hi Sam,
the Kenwood protocol does not respond to CAT commands that set things,
so there is a problem with reading any invalid response ('?') since we
have no way of knowing how long to wait for a response which may never
come. Hamlib gets around this ambiguity with a simple device, after CAT
commands that do not elicit a reply when they work, a basic command that
does elicit a reply is sent. Then we can read a reply and either get the
command failed reply (and discard the expected reply), or the expected
reply from the second command. This simple technique means that CAT
commands can proceed without any wait time, despite extra traffic being
sent.
Other CAT protocols are more robust and always send either an ACK or
NACK response to all commands, so with them there is no ambiguity.
73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Sam,
you have not understood my comments and the reason for the dummy
command, please read my explanation again.
73
Bill
G4WJS.
On 16/11/2021 15:00, Sam W2JDB via wsjt-devel wrote:
Hi Bill,
Any invalid command will result in a '?;' response, even a SET command.
i.e. if you send 'AC000' and the tuner is already in a 'AC000' state
in reply
to 'AC;' command, you will get a '?;' response. I used that example
because
I ran into that problem and it took me a while to figure why/where
that was
coming from.
73,
Sam W2JDB
-Original Message-
From: Bill Somerville via wsjt-devel
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville
Sent: Tue, Nov 16, 2021 9:26 am
Subject: Re: [wsjt-devel] VFOs reversing
On 16/11/2021 14:07, Sam W2JDB via wsjt-devel wrote:
> I also wondering about the multiple
> 'ID' requests, is that your version of heartbeat ? Just wondering.
Hi Sam,
the Kenwood protocol does not respond to CAT commands that set things,
so there is a problem with reading any invalid response ('?') since we
have no way of knowing how long to wait for a response which may never
come. Hamlib gets around this ambiguity with a simple device, after CAT
commands that do not elicit a reply when they work, a basic command that
does elicit a reply is sent. Then we can read a reply and either get the
command failed reply (and discard the expected reply), or the expected
reply from the second command. This simple technique means that CAT
commands can proceed without any wait time, despite extra traffic being
sent.
Other CAT protocols are more robust and always send either an ACK or
NACK response to all commands, so with them there is no ambiguity.
73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi Bill,
Any invalid command will result in a '?;' response, even a SET command.i.e. if
you send 'AC000' and the tuner is already in a 'AC000' state in reply to 'AC;'
command, you will get a '?;' response. I used that example because I ran into
that problem and it took me a while to figure why/where that was coming from.
73, Sam W2JDB
-Original Message-
From: Bill Somerville via wsjt-devel
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville
Sent: Tue, Nov 16, 2021 9:26 am
Subject: Re: [wsjt-devel] VFOs reversing
On 16/11/2021 14:07, Sam W2JDB via wsjt-devel wrote:
> I also wondering about the multiple
> 'ID' requests, is that your version of heartbeat ? Just wondering.
Hi Sam,
the Kenwood protocol does not respond to CAT commands that set things,
so there is a problem with reading any invalid response ('?') since we
have no way of knowing how long to wait for a response which may never
come. Hamlib gets around this ambiguity with a simple device, after CAT
commands that do not elicit a reply when they work, a basic command that
does elicit a reply is sent. Then we can read a reply and either get the
command failed reply (and discard the expected reply), or the expected
reply from the second command. This simple technique means that CAT
commands can proceed without any wait time, despite extra traffic being
sent.
Other CAT protocols are more robust and always send either an ACK or
NACK response to all commands, so with them there is no ambiguity.
73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
On 16/11/2021 14:07, Sam W2JDB via wsjt-devel wrote:
I also wondering about the multiple
'ID' requests, is that your version of heartbeat ? Just wondering.
Hi Sam,
the Kenwood protocol does not respond to CAT commands that set things,
so there is a problem with reading any invalid response ('?') since we
have no way of knowing how long to wait for a response which may never
come. Hamlib gets around this ambiguity with a simple device, after CAT
commands that do not elicit a reply when they work, a basic command that
does elicit a reply is sent. Then we can read a reply and either get the
command failed reply (and discard the expected reply), or the expected
reply from the second command. This simple technique means that CAT
commands can proceed without any wait time, despite extra traffic being
sent.
Other CAT protocols are more robust and always send either an ACK or
NACK response to all commands, so with them there is no ambiguity.
73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi Mike, Sorry, I forgot to highlight and mention that at the highlighted lines belowwhen Split is turned on again, it is actually in reverse where VFO-B is now receiving and VFO-A is transmitting. This is reverse back to VFO-A Receive and VFO-B Transmit later on. 73, Sam W2JDB -Original Message- From: Sam W2JDB via wsjt-devel To: wsjt-devel@lists.sourceforge.net Cc: Sam W2JDB Sent: Tue, Nov 16, 2021 9:07 am Subject: Re: [wsjt-devel] VFOs reversing Hi Mike, Sorry I got back toyou so late. Life does get in the way. I modified my program so thatI can give you a more detailed view as to I see happening whenSPLIT=RIG. I attached a textfile that will give more more detail but I am displaying a portion below where wsjt-x is preparing for the TX cycle. You will noticethat there are extraneous FT FR commands that force Split to turn offand on before the TX1 command is issued. In the attached text file,there are two TX cycles and the pattern repeats. Hope this helps. Inaddition, I also wondering about the multiple 'ID' requests, is that your version of heartbeat ? Just wondering. 01207 08:25:29:803 :<<: DA1; // Prepare to TXCycle 01208 08:25:30:029 :>>: FB7074500;01209 08:25:30:029 :>>: ID;01210 08:25:30:038 :<: ID021;01211 08:25:30:039 :<<: ID021;01212 08:25:30:043 :>>: FA;01213 08:25:30:046 :<: FA7074000;01214 08:25:30:046 :<<: FA7074000;01215 08:25:30:049 :>>: FR0;01216 08:25:30:049 :>>: FT1;01217 08:25:30:050 :>>: ID;01218 08:25:30:069 :<: ID021;01219 08:25:30:069 :<<: ID021;01220 08:25:30:100 :>>: FT0; // This Causes Split to turn Off01221 08:25:30:100 :>>: ID;01222 08:25:30:100 :<: ID021;01223 08:25:30:100 :<<: ID021;01224 08:25:30:131 :>>: FR1; // This Causes Split to Turn On (In Reverse)01225 08:25:30:131 :>>: ID;01226 08:25:30:131 :<: ID021;01227 08:25:30:131 :<<: ID021;01228 08:25:30:162 :>>: FT1; // This Causes Split to Turn Off 01229 08:25:30:162 :>>: ID;01230 08:25:30:162 :<: ID021;01231 08:25:30:162 :<<: ID021;01232 08:25:30:200 :>>: MD2;01233 08:25:30:200 :>>: ID;01234 08:25:30:200 :<: ID021;01235 08:25:30:200 :<<: ID021;01236 08:25:30:231 :>>: DA1;01237 08:25:30:231 :>>: ID;01238 08:25:30:231 :<: ID021;01239 08:25:30:231 :<<: ID021;01240 08:25:30:262 :>>: FR0; // This Causes split to turn On (Back to Normal)01241 08:25:30:262 :>>: FT1;01242 08:25:30:262 :>>: ID;01243 08:25:30:284 :<: ID021;01244 08:25:30:284 :<<: ID021;01245 08:25:30:315 :>>: FT1;01246 08:25:30:315 :>>: ID;01247 08:25:30:315 :<: ID021;01248 08:25:30:315 :<<: ID021;01249 08:25:30:347 :>>: FR0;01250 08:25:30:347 :>>: FT1;01251 08:25:30:347 :>>: FT1;01252 08:25:30:347 :>>: ID;01253 08:25:30:369 :<: ID021;01254 08:25:30:369 :<<: ID021; // Start TX Cycle 01255 08:25:30:400 :>>: TX1; Sam W2JDB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi Mike, Sorry I got back toyou so late. Life does get in the way. I modified my program so thatI can give you a more detailed view as to I see happening whenSPLIT=RIG. I attached a textfile that will give more more detail but I am displaying a portion below where wsjt-x is preparing for the TX cycle. You will noticethat there are extraneous FT FR commands that force Split to turn offand on before the TX1 command is issued. In the attached text file,there are two TX cycles and the pattern repeats. Hope this helps. Inaddition, I also wondering about the multiple 'ID' requests, is that your version of heartbeat ? Just wondering. 01207 08:25:29:803 :<<: DA1; // Prepare to TXCycle 01208 08:25:30:029 :>>: FB7074500;01209 08:25:30:029 :>>: ID;01210 08:25:30:038 :<: ID021;01211 08:25:30:039 :<<: ID021;01212 08:25:30:043 :>>: FA;01213 08:25:30:046 :<: FA7074000;01214 08:25:30:046 :<<: FA7074000;01215 08:25:30:049 :>>: FR0;01216 08:25:30:049 :>>: FT1;01217 08:25:30:050 :>>: ID;01218 08:25:30:069 :<: ID021;01219 08:25:30:069 :<<: ID021;01220 08:25:30:100 :>>: FT0; // This Causes Split to turn Off01221 08:25:30:100 :>>: ID;01222 08:25:30:100 :<: ID021;01223 08:25:30:100 :<<: ID021;01224 08:25:30:131 :>>: FR1; // This Causes Split to Turn On 01225 08:25:30:131 :>>: ID;01226 08:25:30:131 :<: ID021;01227 08:25:30:131 :<<: ID021;01228 08:25:30:162 :>>: FT1; // This Causes Split to Turn Off 01229 08:25:30:162 :>>: ID;01230 08:25:30:162 :<: ID021;01231 08:25:30:162 :<<: ID021;01232 08:25:30:200 :>>: MD2;01233 08:25:30:200 :>>: ID;01234 08:25:30:200 :<: ID021;01235 08:25:30:200 :<<: ID021;01236 08:25:30:231 :>>: DA1;01237 08:25:30:231 :>>: ID;01238 08:25:30:231 :<: ID021;01239 08:25:30:231 :<<: ID021;01240 08:25:30:262 :>>: FR0; // This Causes split to turn On01241 08:25:30:262 :>>: FT1;01242 08:25:30:262 :>>: ID;01243 08:25:30:284 :<: ID021;01244 08:25:30:284 :<<: ID021;01245 08:25:30:315 :>>: FT1;01246 08:25:30:315 :>>: ID;01247 08:25:30:315 :<: ID021;01248 08:25:30:315 :<<: ID021;01249 08:25:30:347 :>>: FR0;01250 08:25:30:347 :>>: FT1;01251 08:25:30:347 :>>: FT1;01252 08:25:30:347 :>>: ID;01253 08:25:30:369 :<: ID021;01254 08:25:30:369 :<<: ID021; // Start TX Cycle 01255 08:25:30:400 :>>: TX1; Sam W2JDB <: Response from TS590S : >>: Command sent to TS590S from WSJT-X <<: Response from TS590S back to WSJT-X Multiple PS1 repsonses that are not set back to WSJT-X are my programs heartbeats commands to/from the rig. 6 08:23:53:880 : <: PS1; 8 08:23:54:250 : <: IF7074000 -0062002080; 00010 08:23:54:613 : <: FA7074000; 00012 08:23:54:967 : <: FB7074500; 00014 08:23:55:331 : <: FR0; 00016 08:23:55:687 : <: FT0; 00018 08:23:56:055 : <: AI0; 00021 08:23:58:762 : <: PC005; 00023 08:23:58:925 : <: SM0; 00025 08:23:59:294 : <: DA1; 00027 08:23:59:379 : <: AC000; 00031 08:23:59:463 : <: FR1; 00032 08:23:59:495 : <: FT1; 00034 08:23:59:541 : <: MD2; 00036 08:23:59:626 : <: DA1; 00040 08:23:59:726 : <: FR0; 00041 08:23:59:764 : <: FT0; 00043 08:23:59:795 : <: AN200; 00045 08:23:59:880 : <: ML000; 00047 08:23:59:965 : <: NR1; 00049 08:24:00:043 : <: RL04; 00051 08:24:00:143 : <: NR2; 00053 08:24:00:212 : <: RL01; 00055 08:24:00:297 : <: NR1; 00057 08:24:00:481 : <: EX0532; 00059 08:24:00:598 : <: EX0542; 00061 08:24:00:798 : <: EX0317; 00063 08:24:00:913 : <: EX0307; // WSJT-X starts here == 00066 08:24:08:884 : <: PS1; 00069 08:24:20:204 : >>: ID; 00070 08:24:20:204 : <: ID021; 00071 08:24:20:204 : <<: ID021; 00072 08:24:20:242 : >>: PS; 00073 08:24:20:242 : <: PS1; 00074 08:24:20:242 : <<: PS1; 00075 08:24:20:273 : >>: FV; 00076 08:24:20:273 : <: FV2.03; 00077 08:24:20:273 : <<: FV2.03; 00078 08:24:20:305 : >>: AI; 00079 08:24:20:305 : <: AI2; 00080 08:24:20:305 : <<: AI2; 00081 08:24:20:342 : >>: AI0; 00082 08:24:20:342 : >>: ID; 00083 08:24:20:342 : <: ID021; 00084 08:24:20:342 : <<: ID021; 00085 08:24:20:374 : >>: IF; 00086 08:24:20:374 : <: IF7074000 -0062002080; 00087 08:24:20:374 : <<: IF7074000 -0062002080; 00088 08:24:20:405 : >>: MD; 00089 08:24:20:405 : <: MD2; 00090 08:24:20:405 : <<: MD2; 00091 08:24:20:443 : >>: DA; 00092 08:24:20:443 : <: DA1; 00093 08:24:20:443 : <<: DA1; 00094 08:24:20:474 : >>: FA; 00095 08:24:20:474 : <: FA7074000; 00096 08:24:20:474 : <<: FA7074000; 00097 08:24:20:505 : >>: FA7074055; 00098 08:24:20:505 : >>: ID; 00099 08:24:20:505 : <: ID021; 00100 08:24:20:505 : <<: ID021; 00101 08:24:20:543 : >>: FA; 00102 08:24:20:543 : <: FA7074055; 00103 08:24:20:543 : <<: FA7074055; 00104 08:24:20:574 : >>: FA7074000; 00105 08:24:20:574 : >>: ID; 00106 08:24:20:574 : <: ID021; 00107 08:24:20:574 : <<: ID021; 00108 08:24:20:605 : >>: IF; 00109 08:24:20:605 : <: IF7074000 -0062002080; 00110 08:24:20:605 : <<: IF7074000 -0062002080; 00111 08:24:20:643 : >>: MD; 00112 08:24:20:643 : <: MD2; 00113
Re: [wsjt-devel] VFOs reversing
Hi Bill, Thank you forpointing me to the Hamlib documentation, and yes, I do understand thatthe Hamlib library removes the requirements of knowing the exactcommands needed to control any rig that Hamlib supports. While I have onlydone a cursory read through, I believe I did find the function calls that WSJT-X might be calling when "Split=Rig" is specified as it changesfrom RX to TX with the possibility of the need to change the TX offset. In any event, Icertainly was not trying to tell you to re-engineer your code, just apotential workaround based on my experience of writing my own code totrack/control various rigs with different capabilities. My apologies if it was taken the wrongway. As always, thank youagain for all your previous help and support. 73, Sam W2JDB -Original Message- From: Bill Somerville via wsjt-devel To: wsjt-devel@lists.sourceforge.net Cc: Bill Somerville Sent: Sat, Nov 13, 2021 5:11 am Subject: Re: [wsjt-devel] VFOs reversing Sam, WADR before you suggest re-engineering the way WSJT-X controls rigs via Hamlib I think you should take some time to review the Hamlib library API. Note that the client API does not require client applications to know what rig is being controlled or to issue low level CAT commands. https://github.com/Hamlib/Hamlib/wiki/Documentation 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Moreover most rigs with targetable frequency do not have a "set freq on current VFO"newer Icom's are an exception to that.Rigs that do NOT have targetable frequency only have that (a lot of older rigs). So the idea of doing the vfo swapping works non-targetable rigs but not targetable ones. Hamlib supports 254 rigs now and I'm seeing more edge cases of behaviors partly due to speed ups in the serial I/O. Knob twiddling has been a problem for a long time when users start twiddling knobs.The only knob twiddling I really care about supporting is for satellite doppler work since that is computer controlled and critical to operations.Other cases get support if possible but generally at lower priority. Currently hamlib just reports whatever the rig claims is the current VFO and in some cases a simulated answer and I'm not inclined to overrule the rig answer but provide a better VFO method to start using RX/TX VFO options instead of VFOA/B and Main/Sub. Mike W9MDB On Saturday, November 13, 2021, 04:15:54 AM CST, Bill Somerville via wsjt-devel wrote: Sam, WADR before you suggest re-engineering the way WSJT-X controls rigs via Hamlib I think you should take some time to review the Hamlib library API. Note that the client API does not require client applications to know what rig is being controlled or to issue low level CAT commands. https://github.com/Hamlib/Hamlib/wiki/Documentation 73 Bill G4WJS. On 12/11/2021 23:11, Sam W2JDB via wsjt-devel wrote: > Hi, > > The problem that I can see cropping up is that on some rigs you can not > change the frequency of the Sub VFO until it becomes the Main VFO when > the rig status changes to TX. > > You (WSJT-X) might be able to use a workaround by issuing a swap > VFO command change the TX frequency (if needed) on the new > Main VFO and then issue another swap VFO command. > > At this point you can start the TX process and let rig then takes care > of the correct VFO swap. Mike will not need any convoluted code to > track which is the Main VFO or Sub VFO. > > Just my two cents on this problem. > > 73, > > Sam W2JDB > > > > -Original Message- > From: Bill Somerville via wsjt-devel > To: wsjt-devel@lists.sourceforge.net > Cc: Bill Somerville > Sent: Fri, Nov 12, 2021 4:56 pm > Subject: Re: [wsjt-devel] VFOs reversing > > On 12/11/2021 18:09, Black Michael via wsjt-devel wrote: > > This is on an Elecraft K4. > > When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes > > the Tx frequency WSJT-X assumes since VFOB is the current VFO that it > > reverses roles and sets VFOA frequency instead. > > If VFOB is active and split and ptt=on then VFOB is still tx. I > > really don't know if this applies to all rigs though. > > > > Mike W9MDB > > Mike, > > to deal with that sort of behaviour either all rigs must do the same > thing or WSJT-X will have to determine the rig and decide if the current > VFO changes (as reported by Hamlib) when transmitting split on a rig by > rig basis. Given that a number of rigs cannot be queried for the current > VFO I would think that the best option for Hamlib is not to change the > current VFO when transmitting split. > > 73 > Bill > G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Sam, WADR before you suggest re-engineering the way WSJT-X controls rigs via Hamlib I think you should take some time to review the Hamlib library API. Note that the client API does not require client applications to know what rig is being controlled or to issue low level CAT commands. https://github.com/Hamlib/Hamlib/wiki/Documentation 73 Bill G4WJS. On 12/11/2021 23:11, Sam W2JDB via wsjt-devel wrote: Hi, The problem that I can see cropping up is that on some rigs you can not change the frequency of the Sub VFO until it becomes the Main VFO when the rig status changes to TX. You (WSJT-X) might be able to use a workaround by issuing a swap VFO command change the TX frequency (if needed) on the new Main VFO and then issue another swap VFO command. At this point you can start the TX process and let rig then takes care of the correct VFO swap. Mike will not need any convoluted code to track which is the Main VFO or Sub VFO. Just my two cents on this problem. 73, Sam W2JDB -Original Message- From: Bill Somerville via wsjt-devel To: wsjt-devel@lists.sourceforge.net Cc: Bill Somerville Sent: Fri, Nov 12, 2021 4:56 pm Subject: Re: [wsjt-devel] VFOs reversing On 12/11/2021 18:09, Black Michael via wsjt-devel wrote: > This is on an Elecraft K4. > When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes > the Tx frequency WSJT-X assumes since VFOB is the current VFO that it > reverses roles and sets VFOA frequency instead. > If VFOB is active and split and ptt=on then VFOB is still tx. I > really don't know if this applies to all rigs though. > > Mike W9MDB Mike, to deal with that sort of behaviour either all rigs must do the same thing or WSJT-X will have to determine the rig and decide if the current VFO changes (as reported by Hamlib) when transmitting split on a rig by rig basis. Given that a number of rigs cannot be queried for the current VFO I would think that the best option for Hamlib is not to change the current VFO when transmitting split. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
Hi, The problem that I can see cropping up is that on some rigs you can not change the frequency of the Sub VFO until it becomes the Main VFO when the rig status changes to TX. You (WSJT-X) might be able to use a workaround by issuing a swap VFO command change the TX frequency (if needed) on the new Main VFO and then issue another swap VFO command. At this point you can start the TX process and let rig then takes care of the correct VFO swap. Mike will not need any convoluted code to track which is the Main VFO or Sub VFO. Just my two cents on this problem. 73, Sam W2JDB -Original Message- From: Bill Somerville via wsjt-devel To: wsjt-devel@lists.sourceforge.net Cc: Bill Somerville Sent: Fri, Nov 12, 2021 4:56 pm Subject: Re: [wsjt-devel] VFOs reversing On 12/11/2021 18:09, Black Michael via wsjt-devel wrote: > This is on an Elecraft K4. > When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes > the Tx frequency WSJT-X assumes since VFOB is the current VFO that it > reverses roles and sets VFOA frequency instead. > If VFOB is active and split and ptt=on then VFOB is still tx. I > really don't know if this applies to all rigs though. > > Mike W9MDB Mike, to deal with that sort of behaviour either all rigs must do the same thing or WSJT-X will have to determine the rig and decide if the current VFO changes (as reported by Hamlib) when transmitting split on a rig by rig basis. Given that a number of rigs cannot be queried for the current VFO I would think that the best option for Hamlib is not to change the current VFO when transmitting split. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFOs reversing
On 12/11/2021 18:09, Black Michael via wsjt-devel wrote: This is on an Elecraft K4. When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes the Tx frequency WSJT-X assumes since VFOB is the current VFO that it reverses roles and sets VFOA frequency instead. If VFOB is active and split and ptt=on then VFOB is still tx. I really don't know if this applies to all rigs though. Mike W9MDB Mike, to deal with that sort of behaviour either all rigs must do the same thing or WSJT-X will have to determine the rig and decide if the current VFO changes (as reported by Hamlib) when transmitting split on a rig by rig basis. Given that a number of rigs cannot be queried for the current VFO I would think that the best option for Hamlib is not to change the current VFO when transmitting split. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
