dm32: correct scan-list 15-member notes (retract terminator theory) - #16
Open
emuehlstein wants to merge 1 commit into
Open
dm32: correct scan-list 15-member notes (retract terminator theory)#16emuehlstein wants to merge 1 commit into
emuehlstein wants to merge 1 commit into
Conversation
The notes field claimed a full 15-member scan list emits no 0x0000 terminator and makes every scan list unselectable, and implied dropping the largest list to 14. That theory is wrong and was retracted after hardware verification on 2026-08-07 (DP570UV). The 57-byte record buffer is fill(0x00) and the +0x38 padding already terminates a full list, so the terminator guard was never load-bearing. Lists at exactly 15 are fine and are in active use (AirBand, FAMILY, HAM, MARINE). The real cause is that +0x0F is not a member slot: OEM CPS moves the first grid member there on write and that channel is neither scanned nor displayed. CPS counts it, which is why lists read count = list + 1 and why the CPS appears to offer 16. This also replaces the previous 'Current Channel at index 0' explanation for the CPS 16. Also records the related decode bug from upstream PR #156: scan-list ID is 0x19 & 0x3F, not bits 5-2. No limits changed; max_channels_per_scan_list stays 15.
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
1 participant
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.
The
notesfield inradios/baofeng_dm32/capabilities.jsoncarried atheory that is wrong, and it is the kind of wrong that generates bad
advice: it told a reader that a full 15-member scan list is dangerous
and implied dropping the largest list to 14.
What was wrong
The terminator observation about NeonPlug is real, but the conclusion
drawn from it is not. The guard was never load-bearing: the 57-byte
record buffer is
fill(0x00), and the+0x38padding already terminatesa full list. Lists at exactly 15 are fine and are in active use
(
AirBand,FAMILY,HAM,MARINE).What is actually going on
Hardware-verified 2026-08-07 on a DP570UV:
+0x0Fis not a memberslot. OEM CPS moves the first grid member there on write, and that
channel is neither scanned nor displayed. CPS counts it, which is why
lists read
count = list + 1.That also supersedes the other half of the old note. The CPS appears to
offer 16 because it counts this phantom
+0x0Fentry — not because of aCurrent Channelentry registered at index 0. Both explanations pointedat the same symptom; only one of them is the mechanism.
Practical guidance now recorded: leave
+0x0Fzero,+0x1Ais theentire membership, and the
+0x0Bcount byte is unreliable.Also recorded
The related decode bug corrected in upstream PR #156: scan-list ID is
0x19 & 0x3F(low 6 bits), not bits 5-2. The old mask cannot addresspast list 15.
Scope
Notes text only. No limits changed —
max_channels_per_scan_liststays
15, and the cap itself was never in question. 30 tests pass.Refs #3.