Panadapter zoom is offered per-pane but is radio-wide on the HL2, and `panSpanIsRadioWide` reaches no UI code

What happened

Pressing + on one panadapter zooms every panadapter. Reported by an operator running a Hermes-Lite 2 with multiple receivers, who reasonably expected the control to apply to the pane it sits on.

The radio is behaving correctly — the UI is not being honest

On the HL2 the panadapter span is the DDC sample rate, and openHPSDR protocol 1 carries one rate for the whole radio:

Cc ccConfig(SampleRate rate, int numRx, std::uint8_t ocFilterByte) noexcept

One rate, numRx receivers. There is no per-receiver rate to set, so independent spans are not something this hardware can express. Hl2Backend::capabilities() already says so:

span.radioWide = true;

and RadioCapabilities.h's own comment on that field predicts this exact report:

"This is why receivePanBandwidthControl can be absent on a radio that plainly does change its span: the control exists, but it is not a per-panadapter one, and offering it as per-pan would let an operator narrow one window and silently retune the other three."

That is precisely what happened.

The defect

grep -rn 'panSpanIsRadioWide\|radioWide' src/gui/ returns nothing. The declaration exists on the backend and no UI code consumes it. SpectrumWidget builds a +/− pair per pane with the tooltip "Zoom in" and gives the operator no way to know the control is shared.

Same shape as #5744's finding that Hl2Spectrum::reset() had no caller: a fact correctly declared and never read.

It must not be fixed by hard-coding HL2 behaviour

A Flex computes its panadapters in the radio and genuinely does have independent spans. Whatever is done here has to read the capability, or it will be wrong on one family or the other.

Options, for a maintainer to choose

A — Label it. Keep the per-pane buttons; when panSpanIsRadioWide, change the tooltip to say the control moves every panadapter on this radio. One line, no layout change. Leaves a per-pane control that is not per-pane, which is honest but still slightly odd.

B — Hoist it. When panSpanIsRadioWide, render a single span control outside the panes and drop the per-pane pair; when false, keep it exactly as today. Truthful on both families, and the first real consumer of the capability record. Costs a layout decision about where the shared control lives.

C — Mark the panes. Keep the buttons per-pane and add a shared-span indicator to each panadapter. Cheaper than B, but four indicators each saying "this one isn't mine" reads worse than one control that is.

We would implement whichever is preferred — this is filed as a report rather than a PR because the choice is a UI-shape question that belongs to the maintainers, not to us.

Our own preference is B, on the grounds that a per-pane control which silently is not per-pane will mislead the next operator the same way, and B is the only option that is correct on a Flex without a family check.

A second constraint worth recording, since it bears on any UI that offers span freely

Span and receiver count share one 100BASE-T link, so they trade off:

Computed from ep6BitsPerSecond() and maxReceiversAtRate() in MetisProtocol.h, whose own comment notes that four receivers at 384 kHz is "not a safety margin below 100" — and the link does not refuse, it drops. Dropped EP6 packets are gaps in every panadapter at once.

Not verified

Only the HL2 was exercised. The Flex and ANAN paths are read from source, not run — in particular whether a Flex's per-pane zoom is already correct in this widget was not tested.

🤖 Generated with Claude Code

Start in src/gui/ and inspect SpectrumWidget's per-pane zoom controls, then trace how RadioCapabilities.h is exposed to the UI and how Hl2Backend::capabilities() sets panSpanIsRadioWide. Confirm the chosen UI treatment uses the capability rather than an HL2-specific check, and verify the resulting behavior for both radio-wide and independent-span radios.