Summary
Add a baofeng_uv5r_mini radio definition so profiles can target the Baofeng UV-5R Mini.
Today radios/ contains only baofeng_dm32 and retevis_matetalk_p4, so _load_capabilities() (src/codeplugger/profile.py:192) raises unknown radio 'baofeng_uv5r_mini' for any profile pointing at it.
Why now
muehlstein-codeplugger-profiles already registers a physical UV-5R Mini in instances.yml (5rm_01 / CO-5RM-01, assigned to Jess, FCC ID 2AJGM-5RMINI, fw v0.05, hw rev v1.7) with profile: muehlstein_uv5r_mini. That profile can't be written or validated until codeplugger knows the radio, so the registry currently points at something unbuildable.
What's needed
radios/baofeng_uv5r_mini/capabilities.json conforming to schemas/capabilities-0.2.schema.json.- Sourced figures for the required
limits keys: max_channels, max_zones, max_channels_per_zone.
bands, modes, bandwidths_khz — omit any that can't be sourced; validation degrades gracefully rather than guessing (_check_radio_support, profile.py:118).- Provenance in
notes, per the precedent set by the DM-32 and P4 files.
The interesting part: this is the first FM-only radio
Both existing radios declare "modes": ["FM", "DMR"]. The UV-5R Mini is analog FM only, so this would be the first "modes": ["FM"] entry — which is the first time the mode check in _check_radio_support can actually reject a channel for mode. Worth an explicit test: a DMR assignment selected against this radio should fail with the "does not support" error rather than pass through.
Zones are the open design question. The stock UV-5R Mini has no zone concept. The schema allows max_zones: 0 ("radio has no zone concept"), but max_channels_per_zone has minimum: 1 and is required, so a zoneless radio still has to declare a per-zone channel count that means nothing. Worth deciding whether:
max_zones: 0 + a filler max_channels_per_zone is acceptable, or- the schema should relax
max_channels_per_zone to conditionally-required when max_zones > 0.
Also unverified: whether profile 0.1's structure assumes zones exist at all. If a zoneless profile can't be expressed, that's a blocker beyond the capabilities file and probably belongs in its own issue.
Suggested acceptance criteria
Notes
Specs above are transcribed from instances.yml, not verified against the radio or its manual. Someone should confirm channel capacity and band edges from a real source before these numbers get baked into a capabilities file — the DM-32 notes field is a good model for how much provenance detail is expected. Related: #3 (capabilities modeling CPS ceilings vs real constraints) is the same class of problem.
Summary
Add a
baofeng_uv5r_miniradio definition so profiles can target the Baofeng UV-5R Mini.Today
radios/contains onlybaofeng_dm32andretevis_matetalk_p4, so_load_capabilities()(src/codeplugger/profile.py:192) raisesunknown radio 'baofeng_uv5r_mini'for any profile pointing at it.Why now
muehlstein-codeplugger-profilesalready registers a physical UV-5R Mini ininstances.yml(5rm_01/CO-5RM-01, assigned to Jess, FCC ID2AJGM-5RMINI, fwv0.05, hw revv1.7) withprofile: muehlstein_uv5r_mini. That profile can't be written or validated until codeplugger knows the radio, so the registry currently points at something unbuildable.What's needed
radios/baofeng_uv5r_mini/capabilities.jsonconforming toschemas/capabilities-0.2.schema.json.limitskeys:max_channels,max_zones,max_channels_per_zone.bands,modes,bandwidths_khz— omit any that can't be sourced; validation degrades gracefully rather than guessing (_check_radio_support,profile.py:118).notes, per the precedent set by the DM-32 and P4 files.The interesting part: this is the first FM-only radio
Both existing radios declare
"modes": ["FM", "DMR"]. The UV-5R Mini is analog FM only, so this would be the first"modes": ["FM"]entry — which is the first time the mode check in_check_radio_supportcan actually reject a channel for mode. Worth an explicit test: a DMR assignment selected against this radio should fail with the "does not support" error rather than pass through.Zones are the open design question. The stock UV-5R Mini has no zone concept. The schema allows
max_zones: 0("radio has no zone concept"), butmax_channels_per_zonehasminimum: 1and is required, so a zoneless radio still has to declare a per-zone channel count that means nothing. Worth deciding whether:max_zones: 0+ a fillermax_channels_per_zoneis acceptable, ormax_channels_per_zoneto conditionally-required whenmax_zones > 0.Also unverified: whether profile
0.1's structure assumes zones exist at all. If a zoneless profile can't be expressed, that's a blocker beyond the capabilities file and probably belongs in its own issue.Suggested acceptance criteria
capabilities.jsonadded and schema-validatesnotesProfileValidationErrormuehlstein_uv5r_miniprofile validates end-to-endNotes
Specs above are transcribed from
instances.yml, not verified against the radio or its manual. Someone should confirm channel capacity and band edges from a real source before these numbers get baked into a capabilities file — the DM-32notesfield is a good model for how much provenance detail is expected. Related: #3 (capabilities modeling CPS ceilings vs real constraints) is the same class of problem.