rig_set_split_freq_mode does not set TX VFO frequency if frequency requested is the same that RX VFO already has.

**Describe the bug**

Background: [JS8Call](https://github.com/JS8Call-improved/JS8Call-improved) in some configuration uses split mode to keep the audio frequency that gets sent to the rig in a sane range, "carrier" at 1500-2000 Hz.

Problem: When the user-selected audio carrier that is not in that range, all is fine. An appropriate split frequency is used. However, when the user later selects an audio carrier that already is in that range, so split operation would not be needed, the wrong old split frequency is re-used.

Here is what happens:

* JS8Call has set the RX or main VFO or VFOA to, say, 28078 kHz.
* From previous transmissions with an audio carrier in the, say, 1000-1500 Hz range, the TX or VFOB sits on 28077.5 kHz.
* Now a carrier in the 1500-2000 Hz range has been selected.
* JS8Call calls `rig_set_split_freq_mode` with the appropriate new frequency of 28078 kHz. As you may have noticed, this happens to be the frequency where the present VFOA sits.
* We believe that `rig_set_split_freq_mode` first reads the current frequency *of the wrong VFO* and decides no frequency change is needed, so ignores our request and leaves the split VFO at 28077.5 kHz.
* When we then push PTT, the wrong frequency 28077.5 is used instead of the correct 28078.

**To Reproduce**

Use hamlib calls to accomplish the following:

* Set the rig to receive mode.
* Configure split mode with VFOA for RX and VFOB for TX.
* Configure the main VFOA to some frequency.
* Set the auxiliary or split VFOB to some other frequency.
* Push PTT and check the rig that VFOB is used and the other frequency has been selected.
* Back to receive mode.
* While still in receive mode, set the auxiliary or split VFOB to the same frequency that is already VFOA's frequency, using `rig_set_split_freq_mode`.
* Push PTT and check which frequency is used.

**Expected behavior**

The rig shows the frequency that has been configured for VFOB.

Actually seen behavior: The rig shows the previous frequency of VFOB. VFOB frequency has not been changed.
(The calls to hamlib functionality have all reported success.)

We believe this code snipped causes our problem, as it reads the wrong VFO:

```
    // TX VFO may change after enabling split
    tx_vfo = rs->tx_vfo;

    rig_get_freq(rig, tx_vfo, &tfreq);

    if (tfreq == tx_freq)
    {
        rig_debug(RIG_DEBUG_TRACE, "%s: freq set not needed\n", __func__);
        ELAPSED2;
        RETURNFUNC2(RIG_OK);
    }
```

**Additional information**

Here is a combined debug log of JS8Call and hamlib showing the problem.

We believe the statement **rig_set_split_freq: freq set not needed** is wrong.

```
transceiverbase.js8: 25-12-16T02:49:54.401Z: "HamlibTransceiver::do_tx_frequency:" 28078000 reversed: false
transceiverbase.js8: 25-12-16T02:49:54.401Z: "HamlibTransceiver::get_vfos:" RX VFO =  VFOA  TX VFO =  VFOB
transceiverbase.js8: 25-12-16T02:49:54.401Z: "HamlibTransceiver::do_tx_frequency:" rig_set_split_freq_mode VFO 536870912  qrg =  28078000  mode =  PKTUSB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: **2:rig.c(5451):rig_set_split_freq_mode entered
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: vfo_fixup:(from rig_set_split_freq_mode:5479) vfo=TX, vfo_curr=VFOA, split=1
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: vfo_fixup(2107): split=1, vfo==TX tx_vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: vfo_fixup: RIG_VFO_TX changed to VFOB, split=1, satmode=0
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: vfo_fixup: final vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig_set_split_freq_mode: vfo=VFOB, tx_freq=28078000, tx_mode=PKTUSB, tx_width=-1
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: **../../src/rig.c(5532) trace
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig.c(4678):rig_set_split_freq entered
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig_set_split_freq called vfo=VFOB, curr_vfo=VFOA, tx_freq=28078000
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: ***3:rig.c(2436):rig_get_freq entered
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig_get_freq called vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig_get_freq(2454) called vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: vfo_fixup:(from rig_get_freq:2461) vfo=VFOB, vfo_curr=VFOA, split=1
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: vfo_fixup: final vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: ../../src/rig.c(2463) vfo=VFOB, curr_vfo=VFOA
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig_get_freq: cache miss age=4198ms, cached_vfo=VFOB, asked_vfo=VFOB, use_cached_freq=0
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: rig_get_freq(2577): vfo_opt=0, model=2
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: netrigctl_get_freq called, vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: netrigctl_vfostr: called vfo=VFOB
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: netrigctl_vfostr: vfo_opt=0
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: netrigctl_transaction: called len=2
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: network_flush called
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: write_block(): TX 2 bytes
hamlibtransceiver.js8: 25-12-16T02:49:54.401Z: Hamlib: 0000    66 0a                                               f.
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: read_string_generic(): RX 9 characters, direct=1
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: 0000    32 38 30 37 38 30 30 30 0a                          28078000.
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: netrigctl_get_freq: cmd=f, reply=28078000
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: rig_get_band called
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: ***3:rig_get_freq: elapsed=2ms
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: ***3:rig.c(2714):rig_get_freq returning(0)
hamlibtransceiver.js8: 25-12-16T02:49:54.402Z: Hamlib: rig_set_split_freq: freq set not needed
hamlibtransceiver.js8: 25-12-16T02:49:54.403Z: Hamlib: **2:rig_set_split_freq: elapsed=2ms
hamlibtransceiver.js8: 25-12-16T02:49:54.403Z: Hamlib: rig.c(4717):rig_set_split_freq returning2(0)
```

**Desktop (please complete the following information):**

 - OS: Debian Linux Trixie
 - Software that has the problem: JS8Call. I'm using a private version that's functionally identical to 2.4.0 as far as pertinent here.
 - Rig is IC-705.
 - I have been using hamlib communicating with `rigctld`, while `rigctld` communicated with the rig via USB.

**Additional context**

JS8Call bug caused by this is https://github.com/JS8Call-improved/JS8Call-improved/issues/94 . I will band-aid this with a quick fix.

**Something I want to say**

Thank you for providing important and generally high-quality software 🌹 useful for the entire ham radio community!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

rig_set_split_freq_mode does not set TX VFO frequency if frequency requested is the same that RX VFO already has. #1966

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Uh oh!

rig_set_split_freq_mode does not set TX VFO frequency if frequency requested is the same that RX VFO already has. #1966

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions