USB/LSB detection does not update on band change

[Tyrbiter]

If the band is changed from say 80m -> 20m or vice versa then the sideband detection will show up in red unless there is a modem start/stop cycle. It does not update even on PTT activity. It would be preferable for the selected sideband to be checked at a sensible interval.

[tmiw]

Does this also happen even without band changes? I'm also assuming this is in 1.7.0 aka master?

[Tyrbiter]

Yes, it's current master. If you remember I commented before that the only time that the radio mode/freq updates is on modem start but the view was it would be expensive to keep updating it. Obvs this only matters when going from <10MHz to >10MHz or vice versa but freedv doesn't know this with reporting off, and possibly with it on.

[tmiw]

Hmm, I just tried the following and it seems to be behaving as intended:

1. Open SDR software and tune to 14.236 DIGU.
2. Start FreeDV and ensure Hamlib is configured to use the SDR program.
3. Note that the bottom properly shows "USB".
4. Change the SDR to DIGL instead. FreeDV still shows "USB".
5. Toggle PTT. FreeDV properly turns the indicator red and shows "LSB" instead.
6. Change bands to 40 meters and ensure the SDR is still in DIGL mode.
7. Toggle PTT again. FreeDV turns the indicator white.

Perhaps it's an issue that's radio dependent. @drowe67, how does this function work for you?

[Tyrbiter]

I have tried this again. If I change mode to the incorrect one for the frequency and then hit PTT, the indicator correctly turns red. As long as I use the LSB/USB mode button on the TS-890 then it is correct as soon as PTT is selected.

If I have the second VFO set to a band with the opposite mode set, and use the A/B button to swap VFOs, then PTT does not pick up the mode change, and of course I can't see what frequency is set but previously the freq box did not update either.

[tmiw]

Could it be that one Hamlib bug that came back? The FreeDV code to control that status display hasn't changed in a while and uses the "current" VFO instead of hardcoding A or B. For example:

int Hamlib::update_frequency_and_mode(void)
{
    rmode_t mode = RIG_MODE_NONE;
    pbwidth_t passband = 0;
    int result = rig_get_mode(m_rig, RIG_VFO_CURR, &mode, &passband);

[Tyrbiter]

I was wondering about this too, it could be that hamlib doesn't realise that the A/B change has happened. I will see if Mike understands the problem.

[Tyrbiter]

Here is the response from Mike W9MDB

---

This will not be "fixed". What you apparently want is for VFO_CURR to figure out what buttons you've pushed and that's not the way it works. VFO_CURR is hamlib's view of the current vfo based on what the rig has been told to do. Many rigs do not have get_vfo (can you say "Icom"?) so if the application needs to know both VFOA and VFOB modes it has to specifically ask for it. There is a new command that makes it a bit easier and returns Freq/Mode/Width/Split/SatMode in just one call for each VFO and will use cached values.  Again though it will not follow buttons you push.  That requires rig_get_freq and rig_get_mode with VFOA/VFOB arguments.

Rig command: \get_vfo_info VFOA Freq: 145000000 Mode: None Width: 0 Split: 0 SatMode: 0

Rig command: \get_vfo_info VFOB Freq: 146000000 Mode: FM Width: 15000 Split: 0 SatMode: 0

---

It would appear that the behaviour in freedv currently will depend on the radio in use.

Could this be changed to a more 'generic' method, from what Mike is saying the A/B button doesn't do anything detectable outside the radio so the VFO_CURR argument is unable to determine if there is a VFO change. I don't think changing VFOs is that unusual a thing to do, how to capture it? Have to confess this seems much more complex that it was in the past.

[tmiw]

Could this be fixed by just using VFO A? Outside of maybe a few SDR programs, I'm not sure there are radios that transmit from anywhere other than A (though perhaps someone can correct me on that).

[Tyrbiter]

It's not a show stopper, but in the case of my TS-890 which has only a single receive chain, the A/B button is placed right under my finger when using the tuning knob. Hence I tend to have 2 freqs/bands of interest already dialled up and flip between them.

This would be less problematic once I can sort out the pipewire/wireplumber issue with devices changing under me, still trying to get the developers to respond to my ticket.

[tmiw]

Hmm, I'm not sure if we can use this but it looks like there's a way to determine whether a VFO can transmit. From https://github.com/Hamlib/Hamlib/blob/master/include/hamlib/rig.h:

/** \brief \c Macro to tell you if VFO can transmit */
#define RIG_VFO_TX_VFO(v)   ((v)|RIG_VFO_TX_FLAG)

/** \brief \c TX -- alias for split tx or uplink, of VFO_CURR  */
#define RIG_VFO_TX          RIG_VFO_TX_VFO(RIG_VFO_CURR)

Otherwise, barring the case where it turns out that TX from VFO B is common, I'm also okay just assuming VFO A.

[Tyrbiter]

Hmm, I'm not sure if we can use this but it looks like there's a way to determine whether a VFO can transmit. From https://github.com/Hamlib/Hamlib/blob/master/include/hamlib/rig.h:

/** \brief \c Macro to tell you if VFO can transmit */
#define RIG_VFO_TX_VFO(v)   ((v)|RIG_VFO_TX_FLAG)

/** \brief \c TX -- alias for split tx or uplink, of VFO_CURR  */
#define RIG_VFO_TX          RIG_VFO_TX_VFO(RIG_VFO_CURR)

Otherwise, barring the case where it turns out that TX from VFO B is common, I'm also okay just assuming VFO A.

Perhaps leave this sitting here and revisit if a method of working out what's happening with VFOs appears.

[tmiw]

Perhaps leave this sitting here and revisit if a method of working out what's happening with VFOs appears.

That's something we can do.

Another possibility is to just show the statuses of both VFOs. Maybe assume VFO A is always the TX VFO and keep the same red/no coloring behavior for that one (while B is either no color or yellow/orange depending on its current frequency/mode, indicating that it might become a problem if it gets swapped with A).

Or, maybe we can revisit refreshing the status every second or two. Other apps (like WSJT-X) seem to do that no problem. I'll think some more about it in any case.

[Tyrbiter]

Fine, you usually know best ;-)

[tmiw]

I'm going to go ahead and close this due to version 1.8.3 being released with #266. Please reopen if this ends up still being an issue.