Radio switches from channel-mode to VFO-mode on startup

[craigerl]

Starting with hamlib 4.5.4 (Debian 12), any apps that use hamlib for cat control switch the radio (ic705) from channel mode to VFO mode. For example, I put APRS in channel 99 on the ic705, when direwolf starts (or rigctld, or any hamlib app), the radio switches to VFO mode, which is typically on an HF frequency.

It's as if the "--vfo" switch is the new default.

Is there a way to suppress this behavior? or suppress all uncommanded changes to the radio on startup?

thanks,
-craig
KM6LYW

[mikaelnousiainen]

This is likely due to the routine Hamlib uses to detect which VFO Icom rig is on at startup.

I guess this could be made optional -- delaying it won't help, as AFAIK there's no way to detect if the rig is in MEM (channel) mode, so the code cannot even switch back to MEM VFO. (Thank you Icom :/)

I've been playing around with the VFO detection routines lately, so I don't see many options here other than making VFO detection optional. Thoughts?

cc @mdblack98 see https://github.com/Hamlib/Hamlib/blob/master/rigs/icom/icom.c#L1023 (icom_current_vfo())

[mdblack98]

Can you please test with rigctl...It's probably one of these two commands (or both) that swith it back to VFO modefe fe a4 e0 07 01 fd  fe fe a4 e0 07 00 fd  In rigctl like this to send the commands  w \0xfe\0xfe\0xa4\0xe0\0x07\0x00\0xfd andw \0xfe\0xfe\0xa4\0xe0\0x07\0x01\0xfd Let me know if one or both causes it. Mike W9MDB On Wednesday, November 22, 2023 at 10:39:01 AM CST, Craig Lamparter ***@***.***> wrote: Starting with hamlib 4.5.4 (Debian 12), any apps that use hamlib for cat control switch the radio (ic705) from channel mode to VFO mode. For example, I put APRS in channel 99 on the ic705, when direwolf starts (or rigctld, or any hamlib app), the radio switches to VFO mode, which is typically on an HF frequency. It's as if the "--vfo" switch is the new default. Is there a way to suppress this behavior? or suppress all uncommanded changes to the radio on startup? thanks, -craig KM6LYW — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[craigerl]

Confirmed, both commands switch the rig into VFO mode (from channel/memory mode)

pi@digipi:~ $ rigctl -m 3085 -r /dev/ttyACM0 -s 115200 

Rig command: w \0xfe\0xfe\0xa4\0xe0\0x07\0x00\0xfd
Reply: 
Rig command: w \0xfe\0xfe\0xa4\0xe0\0x07\0x01\0xfd 
Reply: 
Rig command:

[craigerl]

So is there something I can comment out of the 4.5.4 branch and get this going? I'd like to rebuild the 4.5.4 deb that comes with Raspberry Pi OS 12. Quick fix?

thanks,
-craig
KM6LYW

[craigerl]

If it helps, commenting out rig_get_freq() solves the switch-to-vfo on startup problem on the ic705. No idea if there are any unintended consequences, but it seems to work so far.
-craig
KM6LYW

Hamlib/rigs/icom/icom.c

    if (retval == RIG_OK) // then we know our echo status
    {
        rig_debug(RIG_DEBUG_TRACE, "%s: echo status known, getting frequency\n",
                  __func__);
        rs->rigport.retry = 0;
        rig->state.current_vfo = icom_current_vfo(rig);
        // some rigs like the IC7100 still echo when in standby 
        // so asking for freq now should timeout if such a rig
        freq_t tfreq;
//craiger        retval = rig_get_freq(rig, RIG_VFO_CURR, &tfreq);

        if (retval != RIG_OK)
        {
            rig_debug(RIG_DEBUG_ERR, "%s: rig error getting frequency retry=%d, err=%s\n",
                      __func__, retry_flag, rigerror(retval));
        }
    }

[craigerl]

Hrm, or not, really getting mixed results. anyhow, please let me know which function might be throwing the ic705 into VFO mode on startup. thanks!
-craig
KM6LYW

[craigerl]

Looks like it's in two spots, this seems to work

icom.c

    if (retval == RIG_OK) // then we know our echo status
    {
        rig_debug(RIG_DEBUG_TRACE, "%s: echo status known, getting frequency\n",
                  __func__);
        rs->rigport.retry = 0;
//craiger1  this switches rig to VFO on startup:
//        rig->state.current_vfo = icom_current_vfo(rig);
        // some rigs like the IC7100 still echo when in standby
        // so asking for freq now should timeout if such a rig
        freq_t tfreq;
        retval = rig_get_freq(rig, RIG_VFO_CURR, &tfreq);

    priv->poweron = (retval == RIG_OK) ? 1 : 0;
        
//    if (priv->poweron)
//    { 
//        rig->state.current_vfo = icom_current_vfo(rig);
//    } 

[mdblack98]

Can't you just turn MEM mode back on?  Either manually or via the rigctl command "V MEM" ? Is this just for your own use or an application you distribute? It will be any call referring to RIG_VFO_B that is going to cause the VFO to be set. On Friday, December 1, 2023 at 04:19:01 PM CST, Craig Lamparter ***@***.***> wrote: Hrm, or not, really getting mixed results. anyhow, please let me know which function might be throwing the ic705 into VFO mode on startup. thanks! -craig KM6LYW — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[craigerl]

This is for a Raspberry Pi image I'm going to distribute.

When direwolf or rigctld starts, it switches from channel mode to VFO mode uncommanded.

For the newbie user, with an APRS 144.390 frequency in a channel, they're going to get really confused with direwolf switches their rig to 14.123Mhz as it starts. After power failure, the system wont work when it comes back.

So far so good on removing the above two icom_current_vfo() function calls....

-craig
KM6LYW

[mdblack98]

See if there's a way to detect MEM mode on IC7300 or IC9700 or IC705 or any Icom rig.

[craigerl]

fwiw, yaesu guy's are complaining of the same thing (FT100). The patches above are a solid fix for icom at this point.