Hamlib forces VFO B on IC-7100

[Former user]

It appears either the implementation or hamlib itself switches the VFO consistently on to VFO B on the IC-7100 when keying via the Audio Modem interface

I'd suggest this is undesirable, far better to leave the radio operation to the user and simply key, as most serious APRS users would have memories/mode and filter pre-set for APRS usage

[Weston Bustraan]

It looks like this may be a problem with Hamlib https://groups.io/g/direwolf/message/6100

I did check my code and the call to trigger the PTT looks like this:

rig_set_ptt(_rig, RIG_VFO_CURR, RIG_PTT_ON)

So, I would assume that it would keep whatever the current VFO is.

Perhaps you can verify by testing with another app that uses Hamlib or even the hamllib CLI commands

If you find that there is a particular version of Hamlib that fixes the issue, please let me know and I will update the version that comes embedded in QTH.app

[Martin McKay]

Hi there.. thanks for looking at this issue

To provide more information, it doesn’t happen on PTT, but on initial switch on for the device under the ‘connections' pop up (please see below screenshot, clicking the toggle is the action that causes the event).

I’ve verified (and regularly use) hamlib 4.0 as part of Direwolf 1.6 and JTDX v2.2.158 and all 3 work perfectly with the following behaviours

• Direwolf/RigCtl - No automatic changes to anything on the radio, but works perfectly upon command being issued
• JTDX - Automatic switching to VFO A and grabbing the desired frequency, however this is expected as the app is designed to work on specific frequencies as selected in on the main screen and this is the behaviour on all radios I’ve used.

Interestingly, I’ve established the following behaviors when enabling the radio under ‘connections’ pop up.

1. If radio is already on VFO B, a quick ‘flick’ over to VFO A happens before VFO B is then selected
2. If radio is on VFO A, a quick ‘flick’ over to VFO B happens, before returning to VFO A
3. If radio is set to a memory, it appears to switch to VFO mode (VFO A) for a split second, then switch to VFO B

It seems to be that as part of initialisation, the radio is being told to switch to VFO mode, then swap VFO, regardless of the current mode, hence establishing the above pattern.

I’d suggest the best approach would be to not set any specifics and leave the mode/VFO/memory selection to the user, as this can not only vary on frequency depending on part of the world but also filter selection, depending on region

Many thanks, I hope the above helps.

‌

[Weston Bustraan]

What is odd is that QTH doesn’t do anything with setting VFOs. The initialization code is extremely simple. This is what it does when a connection is started:

1. rig_init(rig.id) - Creates hamlib rig data structure
2. rig_set_conf(_rig, TOK_PATHNAME, portPath) - Sets the path to the USB device to use
3. rig_open(_rig) - Open the hamlib connection

I’m going to have to reach out to the Hamlib team because this may be a regression, similar to this user report: https://sourceforge.net/p/hamlib/mailman/hamlib-developer/thread/d4ec996d-fce3-6ac2-0d9a-bf8288f9fb83%40classdesign.com/#msg37319709

[Martin McKay]

That is very odd indeed. I’ve not seen it happen with any other hamlib based apps and I’ve used WSJT-X/JTDX extensively as well as direwolf with hamlib support compiled in, but it may well be due to the specific version of hamlib in QTH.app and a regression bug

I can test the behaviour on other Icom radios if it would help, I have a 9700 and 705 at my disposal

[Martin McKay]

Ok, curiosity got the better of me.. Happens with IC-705 too in the exact same behaviours as described above, using hamlib as PTT control source

[Jeff Hochberg]

I own an IC-7100 (as well as 705, 7300, and 9700). Would it be helpful for me to try to reproduce this issue?

[Martin McKay]

I’ve now seen this behaviour with the latest version of Direwolf compiled for Mac. Expect this is related to a specific version of hamlib running on MacOS, as not all exhibit it (WSJT-X/JTDX as examples)

[Weston Bustraan]

I updated Hamblib to 4.5.5 in QTH.app 0.8.8, so it should contain any fixes that they have done recently.