UV-5R Mini: correct capabilities from the actual CHIRP driver (wrong radio family) - #12
Merged
Conversation
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
baofeng_uv5r_minicapabilities 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)inchirp/drivers/baofeng_uv17Pro.py:2349— a UV-17Pro-platform radio. It is not handled bychirp/drivers/uv5r.pyat all.Verified against
kk7ds/chirp@a229fae.Corrections
max_channel_name_charsLENGTH_NAME = 12,baofeng_uv17Pro.py:283;UV5RMinidoes not override itmax_channelsUV5RMini.CHANNELS = 999→memory_bounds (1, 999)max_channels_per_zonebandsrx_onlyUV5RMini.VALID_BANDSThe old
7isuv5r.py:859valid_name_length = 7; the old128is UV-5R'smemory_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:
So validation would previously accept a transmit assignment anywhere in 480–520 MHz, which is receive-only on this radio.
rx_onlyalready exists incapabilities-0.2.schema.jsonand_frequency_in_bandsalready honors it, so this needed no code change.modesstays["FM"], but the reason is now correctCHIRP 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
notesuv5r.py.max_zones: 1is a profile-0.1 schema artifact, not a radio fact.Verification
capabilities.jsonschema-validates againstcapabilities-0.2.schema.json(0 errors)uv run pytest -q→ 21 passeduses mode DMR, which Baofeng UV-5R Mini does not support (FM), exit 1--output-format chirp-csvnow succeeds on an FM fixtureSide effect: this unblocks a fixture that was never actually blocked
Chicago-Offline/chioff-codeplugger-profiles-test#2was reported blocked becauseFIXTURE 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.