Frequency change with mode change is not working as expected

[szporwolik]

Tested with:

• FTdx10
• v1.1.10
• FlRig 2.0.08

---

Steps to Reproduce

1. Set the radio to USB mode on the 20m band.
2. Send the command:
   http://127.0.0.1:54321/14062000/cw

The radio actually tunes to 14.061300 MHz instead.

---

Issue

After this, the system fails to confirm that the command was executed correctly.

---

Workaround

Sending the tune command twice in a row resolves the issue, but it would be cleaner to handle this case directly in WaveLogGate.

[int2001]

does this happen at any time? or only once?
wasn't able to repro. made a few QSOs with it yesterday (ic7300 behind FLRig) and this morning (during contest).
Everytime the same:

• Click on a spot (Old Bandlist)
• Radio QSYs
• With new Websocket-Function the backpath (Gate to Wavelog) instantly switched WL to the new QRG.

Old roundtrip-way:

• yes, possible, that the backpath isn't triggered fast enough (due to 3000ms roundtrip). But that "bug" was there before and is an effect of the architecture.

[szporwolik]

Every time, but I don't need WaveLog to reproduce that - the Flrig and WL Gate is enough.
The most important part is the mode change.

But... I can reproduce it also WITHOUT Flrig and WL Gate. 😄

---

A) Manual check - operation via radio buttons (no CAT involved)
A.1)
Yaesu is tunned to 14.100MHz in USB.

• just the mode change to CW-U re-tunes to 14.100700MHz
• changing back to to USB takes the radio back to 14.100MHz

A.2)
Yeasu is tunned to 7.100MHz in LSB

• mode change to CW-L re-tunes to 7.099300MHz
• changing back to LSB takes the radio back to 7.100

---

B) FLRig + WLGate and visiting the links in the browser (no Wavelog involved)
B.1)

• Yaesu is manually tunned to 14.100MHz in USB
• http://127.0.0.1:54321/14100000/usb -> nothing happens (beside the radio is shortly displaying that width was changed to 3kHz)
• http://127.0.0.1:54321/14100000/cw -> radio is now at 14.100700MHz in CW mode
• http://127.0.0.1:54321/14100000/usb -> radio is now in USB, but at 14099300 😮

B.2)

• Yaesu is manually tunned to 7.100MHz in LSB
• http://127.0.0.1:54321/7100000/lsb -> nothing happens (beside the radio is shortly displaying that width was changed to 3kHz)
• http://127.0.0.1:54321/7100000/cw -> radio is now at 7.099300MHz in CW mode
• http://127.0.0.1:54321/7100000/lsb -> radio is now in LSB, but at 7.100700 😮 x2

---

C) Just the mode change in Flrig - NO WLGate and NO touching the radio
Exact same behavior as cases A.

---

Cases "A" and "C" I can somehow understand, it seems that Yeasu approach is to jump inside sideband possibly closer to the actual CW frequency that was heard by the operator.

Cases "B" - I don't understand why returning back to SSB operation shifts the initial LSB/USB frequency.

To summarize: I have no idea how ICOM, Kenwood or other vendors handle the mode changes, but it seems that Yaesu does not take priority to stay at the frequency (which actually make sense for manual operation).

But... for our interface, we need to be sure that we have control over the end state of the operation, this is why I would kindly ask to re-think the way it's implemented, so we have stable operation for all TRXes.

The solution to reliable jump to spot in DX Waterfall feature is now... always send the tune command twice, it works, but it's kind of "dirty solution". I've been debugging that yesterday, what happens is:

• if you are in LSB at certain frequency, ex. 7.100MHz
• first http://127.0.0.1:54321/7100000/cw command will change the mode to the desired one, but you will be shifted at 7.0993MHz
• 2nd http://127.0.0.1:54321/7100000/cw will put you exactly at 7.100MHz in CW mode

[szporwolik]

Forgot to mention, it seems that the issue was in the Wavelog before - checked at my DX Waterfall branch (prior Websockets PR)

When in LSB, clicking at this spot:

Tunes to:

When in CW already before clicking, the correct frequency is tunned.

[int2001]

vy vy interesting.
i wasn't able to repro it with my icom IC7300. no chance. QRGs are always exact like expected.

maybe a problem with FLRig and Yaesu?

since i've no yaesu, you could try to poke FLRig with the XML-RPC directly (without the Gate) and see what happens.
If the behaviour is the same, it's an FLRig <--> Yaesu issue.
if not, we have to dig in deeper here.

[szporwolik]

Tested and behavior is exactly the same as expected - in the incorrect way. 😃

Test case A

• Starting at 14105 USB (still Yaesu)
• Sending

<?xml version="1.0"?>
<methodCall>
<methodName>main.set_frequency</methodName>
<params><param><value><double>14100000</double></value></param></params>
</methodCall>

• Then, sending

<?xml version="1.0"?>
<methodCall>
<methodName>rig.set_modeA</methodName>
<params><param><value>CW-U</value></param></params>
</methodCall>

Will end end up at:

FAIL ❌

---

Test case B

• Starting at 14105 USB (still Yaesu)
• Sending mode change (same xml as above)
• Sending frequency (same xml as above)
• Result:

SUCCESS! ✅

---

Proposed solution

I think there is an easy fix to be introduced to do a favor for Yaesu users, please take a look at this part of the code:

WaveLogGate/main.js

Lines 608 to 633 in 7b12e31

	if (defaultcfg.profiles[defaultcfg.profile ?? 0].flrig_ena) {
	let postData= '<?xml version="1.0"?>';
	postData+='<methodCall><methodName>main.set_frequency</methodName><params><param><value><double>' + to.qrg + '</double></value></param></params></methodCall>';
	let options = {
	method: 'POST',
	headers: {
	'User-Agent': 'SW2WL_v' + app.getVersion(),
	'Content-Length': postData.length
	}
	};
	let url="http://"+defaultcfg.profiles[defaultcfg.profile ?? 0].flrig_host+':'+defaultcfg.profiles[defaultcfg.profile ?? 0].flrig_port+'/';
	let x=await httpPost(url,options,postData);
	if (defaultcfg.profiles[defaultcfg.profile ?? 0].wavelog_pmode) {
	postData= '<?xml version="1.0"?>';
	postData+='<methodCall><methodName>rig.set_modeA</methodName><params><param><value>' + to.mode + '</value></param></params></methodCall>';
	options = {
	method: 'POST',
	headers: {
	'User-Agent': 'SW2WL_v' + app.getVersion(),
	'Content-Length': postData.length
	}
	};
	x=await httpPost(url,options,postData);
	}
	}

Replacing the order would completely solve it. So, first send the mode (if required) and THEN send the frequency, this would ensure that however radio is handling mode changes you will end up at the correct frequency. 👍🏻

[int2001]

i've to test it and don't think this will work.
ICOM behaves totally different here.

e.g.:

• 80m / CW (Manually set at TRX)
• QSYing to 20m (only Band change - manually) - Mode is USB (since it was used last), and NOT CW

i assume replacing the order won't work here, because the CW which was set at 80m isn't taken for 20m.
going to test here - will report

[int2001]

tested it. your proposal seems to work at least with icom (and yaesu)
i'll create a PR to dev, and we're going to test it a bit deeper.

[szporwolik]

Perfect 🎉 , much appreciated. 😄

If needed, this sequence makes Yaesu end up at the desired frequency as well:

set_mode(target_mode)
set_freq(target_freq)
set_mode(target_mode)

What happens is at the 2nd mode set, we are already in the desired CW mode, so no additional shift is introduced.

Seems like 1 additional XML to be send, but IMHO it's better to do it locally than handle from Wavelog.

[int2001]

i tested it with different order (not making the 3rd request - since it looks redundant).
please test the PR

[int2001]

i think we can close this one, right @szporwolik ?

[szporwolik]

Yes, I think the provided change solve this. 👌🏻