[RFC] Promote IC-7300MK2 to Supported based on RX, TX, meter and Persist validation

[jensenpat]

Preflight

• Read the current RFC procedure in GOVERNANCE.md; requesting maintainer approval for a public support-status change.
• Searched existing RFCs/issues; no duplicate model-support promotion proposal found.
• No PR has been opened to change the support designation. The linked repair PRs have separate scopes.

Problem

AetherSDR still describes all networked Icom radios as early, outside its supported radio list. For the IC-7300MK2 specifically, that description now understates the accumulated model-specific work: earlier Ethernet RX/scope, audio-routing, TX and meter bring-up, followed by a broad live Persist matrix and targeted repair/retest cycles.

The proposal is to recognize that maturity with a maintained support commitment. It is not a declaration that every Icom feature or every operating-system/radio combination has passed exhaustive certification.

Proposal

Promote the Icom IC-7300MK2 over its built-in Ethernet/RS-BA1 connection to Supported, with a linked feature/evidence matrix and known limitations, in the release that includes the follow-up fixes and completes the short integration check below.

Suggested public wording:

Icom IC-7300MK2 — Supported over Ethernet (RS-BA1). Live-radio validation covers receive audio/scope, transmit operation, radio controls, meters, and reconnect/restart persistence. See the model-specific support notes for tested configurations, feature coverage and known limitations.

“Supported” would mean this model is an intended operating target: its advertised functionality is maintained, reproducible defects are treated as supported-model bugs, and the documented workflows are considered when shared Icom code changes. It does not promise SmartSDR feature parity or erase unsupported/inconclusive entries.

This is model-specific. It does not promote the original IC-7300, IC-705, IC-9700, unknown Icom models or the Icom family as a whole. Existing capability gates and radio-authoritative settings ownership remain intact.

Evidence supporting promotion

Area	Recorded evidence	What it establishes
RX / scope / audio	The existing model-specific bring-up record explicitly lists live MK2 Ethernet RX/scope, PC Audio routing, WSPR, CW decoding, controls, meters and ATU. The profile is checked against the MK2's own CI-V guide. Earlier bring-up record	An operating model-specific backend, with earlier live receive/audio evidence. These are historical results, not new measurements made by the September Persist run.
Controls and visible consumers	The August 13 MK2 certification pass followed CI-V values into actual RF-power, microphone and monitor controls across restart; NR/NB external changes reached the controls. Operator manual surface checks were also recorded. Certification record	Evidence extends beyond setter/model agreement into user-visible behavior and subsequent adoption.
TX	September trials exercised LSB, USB, AM, FM, DFM, DIGU, DIGL and RTTY through the TUNE path; the follow-up established CW text, AM and cold-start DIGU repeats. Final repeat peaks were CW 2.797 W, AM 1.399 W, DIGU 6.993 W, with SWR 1.0, explicit unkey and gauge clearing. First run, P1 follow-up	Actual reported RF on the exercised paths into an authorized dummy load, rather than PTT flags alone. These are native radio-meter observations, not independent waveform, wattmeter or physical-jack measurements.
Meters	The MK2 follow-up checked forward-power, SWR and ALC gauges and the visible supply-voltage value against native observations. S-meter freshness was measured in the first round. Unsupported temperature is now reported as unknown, and native ALC units are preserved. P1 follow-up	Meter provenance, freshness, displayed values and unkey clearing are part of the evidence. This is not certification of every meter's calibration curve.
Persist	The expanded planned matrix completed 14 core control values, 10 mode routes, 30 filter-preset recalls, band changes, four process restarts and six same-process reconnects, plus RX antenna, display, unselected VFO, custom filter, TX passbands and FM tone scenarios. Expanded report	The planned broad run was completed. These are coverage counts, not a claim that every scenario passed: discrepancies and inconclusive checks remain recorded.
Repair and retest	#5514 addresses RX-antenna adoption, the remembered manual SQL choice while Off, explicit Auto intent and local waterfall-rate persistence. Its focused RX-only proof records 16 observations across two process restarts and two reconnects. #5516 adds confirmation freshness/event identity and corrects TX/meter evidence; SQL/AGC retained across restart and final RX reconnect readiness was about 2.4 seconds.	Identified defects led to bounded fixes and live retests. The full expanded matrix has not been rerun on one build combining all fixes.

The first/expanded reports preserve the initial failed attempts. Later source review corrected their “two-tone” labels: those Icom requests generated a single tone, so none is evidence of two-tone/IMD performance. The P1 report is authoritative for that correction. The IC-705's independent-receiver voice test in the shared certification document is not borrowed as MK2 proof.

Release conditions and known limitations

At filing, #5500 is merged; #5514 and #5516 are open. The support label should take effect only after the required repairs are reviewed and integrated into the intended release.

Before changing the public label:

1. Complete the normal release/build gates and one short check on the combined release candidate: identify/connect, receive audio/scope, representative control/meter behavior, explicitly authorized first transmit/unkey, and restart adoption. Record the actual model, firmware, OS and build. This is an integration check, not another exhaustive campaign.
2. Publish a model-specific coverage/known-issues section. Keep the intermittent CI-V identification exhaustion and initial CW/DIGU telemetry observations open; successful repeats have not established their original causes. AM at 2% produced radio-meter zero and a guarded stop, while 5% produced positive output. These need accurate reporting, not manufactured passes.
3. Explicitly document unsupported or unproved areas: genuine Icom two-tone generation; Icom AGC threshold/off-level editing; unestablished scope-narrowing and VFO-exchange paths; physical front-panel latency, crash/power-cycle recovery, and full memory/profile coverage. The earlier filter experiment did not capture all hidden slot definitions before factory recalls, so it cannot certify their original retention/restoration.

Earlier records include ATU/audio-routing work, but this September round did not repeat physical microphone/DAX/VOX/ATU effects or independent RF waveform/jack checks. Unsupported capabilities are normal scope boundaries; intermittent connection/TX symptoms remain known issues for maintainer assessment. They are not described as resolved merely to justify promotion.

Cross-platform impact

The classification and documentation apply to a radio model on the existing shared CI-V/RS-BA1 backend; this proposal adds no platform-specific code.

• macOS: the recent Persist/repair hardware evidence was collected on macOS. fix(icom): retain squelch intent and waterfall speed across restarts #5514 records a successful build and 10/10 selected tests; fix(radiocert): Fix Icom Persist freshness and TX evidence reporting #5516 records a successful main-based build and 8/8 selected tests, plus targeted live evidence on the documented pre-integration binaries.
• Linux and Windows: retain the normal build/release gates and existing backend support paths. The recent macOS lab run does not constitute Linux/Windows live-radio proof. Publish host-platform evidence separately and collect release-candidate smoke results where available; keep missing coverage visible.

The RFC asks approval for the model's supported status, while making the tested host configurations explicit. If maintainers require live checks on all three hosts before that designation, use those checks as the remaining activation gate rather than silently claiming cross-platform hardware certification.

Alternatives considered

• Keep MK2 “early” indefinitely: conservative, but no longer communicates its demonstrated functionality or the investment in maintaining it. It also groups it with models with substantially less evidence.
• Promote the whole Icom family: too broad. Shared code and official guides do not establish each model's hardware behavior.
• Wait for every feature and every possible persistence transition: would make “Supported” equivalent to feature-complete certification. A defined supported scope, release integration check and maintained known-issues list are more useful.

Implementation scope and requested decision

After RFC approval, make a focused documentation PR updating README.md's Supported Hardware section and the model-specific certification/support notes, linking the existing research reports and the release containing the fixes. Correct stale Icom two-tone claims in the existing certification narrative as part of that evidence cleanup. No new dependencies, threads, UI behavior, polling policy or protocol implementation are requested here; no support-label PR has been opened.

Requested decision: approve promoting the IC-7300MK2 to Supported, with the scope and activation conditions above, and identify any additional specific release blocker. The case rests on accumulated RX/TX/meter/Persist evidence and demonstrated repairs, not a claim of universal pass/fail certification.

Related work: #5500, #5514, #5516. Broader certification-framework design remains separate in #5342.

Generated with OpenAI Codex (GPT-6 Astra)

[aethersdr-agent]

Thanks for filing this. This issue involves CI/CD workflows, build infrastructure, or release packaging — that is outside what I can help with, as I am restricted to source code changes in src/ and docs/.

Jeremy will need to handle this one directly.

— AetherClaude (automated agent for AetherSDR)

---

_{🤖 aethersdr-agent · cost: $11.4083 · model: claude-opus-5}

[ten9876]

RFC approved — with the activation gate set to all three hosts

Reviewed against the merged reports on main (first run, expanded run, icom-restart-fixes), the P1 follow-up on the #5516 branch, the 2026-08-13 certification record and the current README wording. Every numeric claim in the evidence table matches its source (14 control values, 10 mode routes, 30 preset recalls, 4 restarts / 6 reconnects, the CW/AM/DIGU repeat peaks, 10/10 and 8/8 selected tests). The two-tone correction and the "coverage counts, not passes" framing are the right level of honesty. Approved as scoped: IC-7300MK2 over Ethernet/RS-BA1 only, no family promotion, capability gates and radio-authoritative settings ownership unchanged.

Decisions

1. Activation gate: live integration check on all three hosts. The macOS evidence establishes the backend; it does not establish the product on Linux or Windows. Before the public label changes, run the short RC integration check from the RFC (identify/connect, RX audio/scope, representative controls/meters, explicitly authorized first TX/unkey, restart adoption) on macOS, Linux and Windows, recording model, firmware, OS and build for each. Until all three are recorded the README keeps early; the support notes may be published ahead of the label with a per-host status table showing what is and isn't done. Missing hosts stay visible as missing, exactly as the RFC proposes — no silent cross-platform claim.
2. Intermittent CI-V identification exhaustion: known issue, not a blocker. Open a dedicated issue for it (directed B6 exhausting five identity attempts; broadcast discovery receiving FA then timing out; a single successful retry after a 3 s pause is not a fix). It goes in the model's known-issues section. Same treatment for the original missing-CW-power and first-DIGU stop observations.
3. README shape: model-level callout inside the Icom bullet. The Icom family bullet stays early. It gains one explicit line, roughly the RFC's suggested wording: IC-7300MK2 — Supported over Ethernet (RS-BA1), linking the model-specific support notes. The FLEX list at the top is untouched, and the "neither is a supported family yet" sentence gets reworded so it no longer contradicts the callout. Also update the roadmap paragraph further down that still lists "transmit confirmation beyond the 705" as remaining work.

Conditions carried from the RFC (unchanged)

• fix(radiocert): Fix Icom Persist freshness and TX evidence reporting #5516 must merge before the label PR opens; the label PR targets the first release after that.
• Publish the model-specific coverage / known-issues section, keeping AM-at-2% (meter zero, guarded stop) reported as observed.
• Explicitly list unsupported / unproved: Icom two-tone generation, AGC threshold/off-level editing, scope narrowing, VFO exchange, front-panel latency, crash/power-cycle recovery, full memory/profile coverage, hidden filter-slot retention.
• Correct the stale two-tone wording in docs/radio-certification.md (the 2026-08-13 "two-tone at 10 % Tune Power" sentence) as part of the docs PR.

Docs PR (README + support notes + certification cleanup) may open once #5516 is merged and the three host checks are recorded. No code changes are approved under this RFC.