Skip to content

UV-5R Mini: correct capabilities from the actual CHIRP driver (wrong radio family) - #12

Merged
emuehlstein merged 1 commit into
mainfrom
fix/uv5r-mini-capabilities-from-chirp-driver
Aug 12, 2026
Merged

UV-5R Mini: correct capabilities from the actual CHIRP driver (wrong radio family)#12
emuehlstein merged 1 commit into
mainfrom
fix/uv5r-mini-capabilities-from-chirp-driver

Conversation

@emuehlstein

Copy link
Copy Markdown
Contributor

Summary

The baofeng_uv5r_mini capabilities were sourced from the classic UV-5R. That is the wrong radio family, and most numbers in the file were wrong as a result.

CHIRP handles this radio as class UV5RMini(UV17Pro) in chirp/drivers/baofeng_uv17Pro.py:2349 — a UV-17Pro-platform radio. It is not handled by chirp/drivers/uv5r.py at all.

Verified against kk7ds/chirp @ a229fae.

Corrections

Field Was Now Source
max_channel_name_chars 7 12 LENGTH_NAME = 12, baofeng_uv17Pro.py:283; UV5RMini does not override it
max_channels 128 999 UV5RMini.CHANNELS = 999memory_bounds (1, 999)
max_channels_per_zone 128 999 matches above
bands VHF 136–174, UHF 400–520 5 ranges, 3 rx_only UV5RMini.VALID_BANDS

The old 7 is uv5r.py:859 valid_name_length = 7; the old 128 is UV-5R's memory_bounds (0, 127). Both are the other driver.

The band fix is the one that mattered

Old file declared one TX-capable block 400–520 MHz. CHIRP declares:

  • 108–136 airband — RX only
  • 136–174 VHF — TX
  • 350–390 — RX only
  • 400–480 UHF — TX
  • 480–520 — RX only

So validation would previously accept a transmit assignment anywhere in 480–520 MHz, which is receive-only on this radio. rx_only already exists in capabilities-0.2.schema.json and _frequency_in_bands already honors it, so this needed no code change.

modes stays ["FM"], but the reason is now correct

CHIRP declares MODES = UV17Pro.MODES + ['AM'] — NFM, FM, and AM (RX airband). So FM-only is a codeplugger output policy, not a hardware limitation. The previous note implied the radio couldn't do anything else. Behavior is unchanged; DMR selection is still correctly rejected.

Also recorded in notes

  • The platform trap, explicitly, so nobody re-sources this from uv5r.py.
  • That max_zones: 1 is a profile-0.1 schema artifact, not a radio fact.

Verification

  • capabilities.json schema-validates against capabilities-0.2.schema.json (0 errors)
  • uv run pytest -q21 passed
  • DMR assignment against this radio still rejected: uses mode DMR, which Baofeng UV-5R Mini does not support (FM), exit 1
  • --output-format chirp-csv now succeeds on an FM fixture

Side effect: this unblocks a fixture that was never actually blocked

Chicago-Offline/chioff-codeplugger-profiles-test#2 was reported blocked because FIXTURE ADD (11 chars) exceeded the 7-char limit. That limit was fictional. The real limit is 12, so the existing fixture fits and needs no rename.

The UV-5R Mini values were sourced from the classic UV-5R. They are the
wrong radio family. CHIRP handles it as class UV5RMini(UV17Pro) in
chirp/drivers/baofeng_uv17Pro.py:2349 - a UV-17Pro-platform radio, NOT
chirp/drivers/uv5r.py.

Corrections, each traceable to the driver:

- max_channel_name_chars 7 -> 12. LENGTH_NAME = 12 on the UV17Pro base
  (baofeng_uv17Pro.py:283); UV5RMini does not override it. The old 7 is
  uv5r.py:859 valid_name_length = 7, a different driver.
- max_channels 128 -> 999, and max_channels_per_zone to match.
  UV5RMini.CHANNELS = 999 => memory_bounds (1, 999). The old 128 is
  UV-5R's memory_bounds (0, 127).
- bands: replaced VHF 136-174 + UHF 400-520 with UV5RMini.VALID_BANDS,
  five ranges, three marked rx_only: airband 108-136 (RX), VHF 136-174
  (TX), 350-390 (RX), 400-480 (TX), 480-520 (RX). This is the correction
  with real consequence: a single 400-520 TX block let validation accept
  transmit assignments from 480-520 MHz, which is receive-only.

modes stays ["FM"], but notes now say why. CHIRP declares MODES =
UV17Pro.MODES + ['AM'] (NFM, FM, AM; AM is RX airband), so FM-only is a
codeplugger output policy, not a hardware limit. The previous note implied
the radio was incapable of anything else.

notes also records the platform trap and that max_zones = 1 is a
profile-0.1 schema artifact, not a radio fact.

Verified: capabilities schema-validates, 21 tests pass, DMR selection is
still rejected for this radio, and chirp-csv export now succeeds for an
FM fixture (it previously failed at resolve on the bogus 7-char limit).
@emuehlstein
emuehlstein merged commit 2bd8e67 into main Aug 12, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant