MercurySkyPulse (MSP) codex assisted - CAT read only frequency

[N4EAC]

Small non-intrusive low priority frequency reading (read-only) through Mercury modem hamlib CAT allowing client to collect current frequency.

[rafael2k]

Thanks @N4EAC. We'll take a look on it.

[N4EAC]

Thanks @N4EAC. We'll take a look on it.

Valeu Rafael, obrigado!

[rafael2k]

Thanks for this — read-only frequency telemetry is genuinely useful, and the design shows you thought about the hard part: caching, the PTT-active gate, the post-PTT quiet window, resolving the VFO through the open session rather than probing, and not polling during a connected session. That's the right set of instincts for an HF TNC.

There's one problem I'd want fixed before merge, and it's a serious one.

rig_get_freq() runs while holding the lock that PTT needs

radio_io_get_frequency() takes g_radio_mutex and then makes up to three blocking Hamlib CAT calls inside it — rig_get_freq, then on failure rig_get_vfo and rig_get_freq again. radio_io_key_on() takes that same mutex before rig_set_ptt.

The cost when a rig is slow or briefly unresponsive is not small. Straight from the Hamlib backend for the radio we run here:

// Hamlib rigs/yaesu/ft710.c:139
.timeout = 1000,
.retry   = 3,

So a single failing read is ~4 s, and the fallback path can chain three of them. During that window key_on() is blocked on the mutex, so PTT is late by however long the CAT read takes.

We have been bitten by this exact class twice in the last week: a Hamlib call blocking inside the keying path silently ate ARQ turnaround, and separately ~1.1 s of extra PTT tail made every incoming ACK collide with our own transmission. A multi-second PTT delay is worse than either, and it fails in the field on exactly the rigs that are already marginal.

The allow_frequency_poll gate cannot prevent this, and I want to be clear about why, because it's the natural first fix. The gate is evaluated before the poll begins. The sequence that hurts is:

1. link idle, nothing connected → allow_poll true, poll starts, lock taken
2. Hamlib blocks on the serial read
3. now a CALL arrives and the FSM decides to answer
4. key_on() blocks behind the poll → the ACCEPT goes out seconds late → connect fails

Step 3 happens after step 1, so no amount of pre-checking state closes it. snap.connected || snap.trx == 1 also doesn't cover a broadcast or CQ transmission from an idle state.

Options

• Minimum: bound the blocking. Configure a short timeout and no retries for the read path so the worst case is tens of ms rather than seconds, and say what the bound is. Cheap, keeps the current structure.
• Robust: poll from the thread that decides to key, rather than from the UI publisher thread. Then a read can never be in flight when a transmission is requested, because the same thread does both. This removes the race rather than narrowing it.

I'd take either, with a preference for the second. What I'd rather avoid is merging a path where PTT latency depends on how fast a particular radio answers a CAT query.

Smaller points

Needs a rebase. The PR is CONFLICTING — radio_io.c moved in #182 (network-rig diagnostics and a Hamlib 5 fix). Should be mechanical; your additions and mine are in different functions.

The $(AR) fix is good and independent. 9803d0f (honouring the cross archiver in modem/freedv/Makefile) is a real cross-compile fix with nothing to do with the frequency work. Happy to take that one on its own straight away if you want to split it out — no reason for it to wait on the rest.

JSON wire format. Appending the two fields at the end is the right call and the test is updated. Just flagging that ui_status_to_json is parsed by remote clients, so field order matters — you've kept it stable, which is what that comment in the file is asking for.

Happy to look again once the locking is addressed. The feature itself is welcome.

[N4EAC]

Rafael, first of all thank you for taking your time to review and respond. I will, from my side, pause further release testing of automatic frequency polling, re_base the Mercury compatibility work, move polling into the radio/keying execution path, add an adversarial test simulating a blocked CAT read followed by an immediate PTT request. I will then rebuild my mercury runtime purposed for my application while still looking into contributing with you guys. Give me some time please.