Summary

PACURRENT (PA current, RAD source) is unreliable on the FLEX-8000 series — a known radio-firmware limitation already documented in the codebase and worked around in the UI. The agent automation bridge's new get meters verb (#3727) re-exposes the raw, uncurated meter table (all), so PACURRENT reappears there and a naive consumer (a test harness, an agent) can mistake its clipped/erratic value for a real measurement. This issue captures the evidence and proposes aligning the automation surface with the UI's existing curation.

Already known (for context)

src/gui/MeterApplet.h:14:

Note: PACURRENT is intentionally omitted — on FLEX-8000 series the meter range is capped at 10A (declared max) while real PA draw exceeds this at full power, causing the reading to clip. See FlexRadio community thread "PA Current Meter for 6xxx" and bug SMART-11281.

So the UI correctly omits PACURRENT. The automation get meters → all array does not (it returns every defined meter), which is the gap.

Evidence (live, FLEX-8400M into a 100W dummy load, via the agent automation bridge)

The meter is defined with unit Amps, declared range [0, 10] (convertRaw divides raw by 256, MeterModel.cpp:219).

Time-sampled during a steady ~47W tune (every ~150 ms): PA current read 0 A for the first ~1.1 s, then jumped to 10 A and held — i.e. it sits at the declared-max cap (clipping, exactly as the note describes), and is not reported at all for the first second of transmit.

Windowed power sweep (median power, freshest PA current, ATU bypassed):

The 0 A readings at 10 W and 75 W were confirmed fresh (per-meter age_ms < 1.5 s, added in #3727) — i.e. the radio genuinely reported 0, not a stale model value. So on top of the clipping, the meter is reported sparsely and intermittently as 0 during transmit. Net: it is not usable as a PA-current measurement on this hardware.

Root cause

Radio firmware (FLEX-8000 series), per SMART-11281 and the existing note: declared max 10 A is below real PA draw at power → clips; and the meter is reported at a low/irregular rate. AetherSDR's parse/convert is correct — it faithfully reflects what the radio sends. The bug is the radio's; AetherSDR's only gap is consistency of curation across surfaces.

Suggested actions (AetherSDR side)

1. Curate the automation surface like the UI does. In get meters (AutomationServer.cpp metersSnapshot), annotate or omit meters known-unreliable on the connected model — e.g. add "reliable": false (or a note) to PACURRENT on 8000-series, mirroring the MeterApplet.h omission, so a consumer knows not to trust it. A small shared "known-bad meters per model" list would keep UI and automation in sync.
2. Harness guard. tools/tx_meter_test.py should skip PACURRENT validation on 8000-series (or treat a clipped/0 reading as "unreliable", not a value).
3. The per-meter age_ms from feat(automation): TX automation hardening for the agent automation bridge #3727 already lets consumers reject stale reads; it does not catch the clipping case (a fresh 10 A cap looks valid), which is why explicit curation (1) is the real fix.

Severity

Low. Known hardware limitation, already invisible in the UI; this is about not letting the automation/test surface present it as a trustworthy number. No impact on normal operation.

How it was found

Live transmit + meter validation on a FLEX-8400M (100W dummy load) using the agent automation bridge (#3727) — the windowed, freshness-gated TX meter harness flagged PA current as inconsistent, and per-meter age_ms confirmed the 0 A readings were fresh rather than stale.