hmatuschek
commented
2 years ago Thanks for reporting this issue. In contrast to all other codeplugs, the TyT codeplugs do not use bitmaps to indicate which channels/contacts etc. are valid. Instead they use a bit within each list element to indicate if it is valid or not. To my knowledge, the manufacturer CPS does generate sparse lists. Thus, I stopped decoding when hitting the first invalid element in a list. I've never tested it, after deleting a channel using the keypad. This issue was there from the first release and you are the fist who found/reported it. This should be fixed now in the master branch, but I still need to test it.
Version 0.10.2
I was having a heck of a time with open source tools clobbering my configs and I think I found at least part of the problem... QDMR (and dmrconf) both kind of choke if you the radio skips an index # in a channel list. This would probably also occur if you deleted a channel from the front face of the radio? In the example
dmrconfigconfig below, I added channels 12 and 13, but skipped ID 11. These channels work in the radio as expected.DMRConfig file
``` # Table of digital channels. # 1) Channel number: 1-3000 # 2) Name: up to 16 characters, use '_' instead of space # 3) Receive frequency in MHz # 4) Transmit frequency or +/- offset in MHz # 5) Transmit power: High, Mid, Low # 6) Scan list: - or index in Scanlist table # 7) Transmit timeout timer in seconds: 0, 15, 30, 45... 555 # 8) Receive only: -, + # 9) Admit criteria: -, Free, Color # 10) Color code: 0, 1, 2, 3... 15 # 11) Time slot: 1 or 2 # 12) Receive group list: - or index in Grouplist table # 13) Contact for transmit: - or index in Contacts table # Digital Name Receive Transmit Power Scan TOT RO Admit Color Slot RxGL TxContact 1 Channel1 431.125 +0 Low - 60 - - 1 1 1 1 # Contact1 2 Channel2 432.225 +0 High - 60 - - 1 1 1 1 # Contact1 3 Channel3 433.325 +0 High - 60 - - 1 1 1 1 # Contact1 4 Channel4 434.425 +0 High - 60 - - 1 1 1 1 # Contact1 6 Channel6 141.125 +0 High - 60 - - 1 1 1 1 # Contact1 7 Channel7 142.225 +0 High - 60 - - 1 1 1 1 # Contact1 8 Channel8 143.325 +0 High - 60 - - 1 1 1 1 # Contact1 9 Channel9 144.425 +0 High - 60 - - 1 1 1 1 # Contact1 # Table of analog channels. # 1) Channel number: 1-3000 # 2) Name: up to 16 characters, use '_' instead of space # 3) Receive frequency in MHz # 4) Transmit frequency or +/- offset in MHz # 5) Transmit power: High, Mid, Low # 6) Scan list: - or index # 7) Transmit timeout timer in seconds: 0, 15, 30, 45... 555 # 8) Receive only: -, + # 9) Admit criteria: -, Free, Tone # 10) Squelch level: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 # 11) Guard tone for receive, or '-' to disable # 12) Guard tone for transmit, or '-' to disable # 13) Bandwidth in kHz: 12.5, 20, 25 # Analog Name Receive Transmit Power Scan TOT RO Admit Sq RxTone TxTone Width 5 Channel5 435.525 +0 High - 60 - - 3 82.5 82.5 12.5 10 Channel10 145.525 +0 High - 60 - - 3 82.5 82.5 12.5 12 Secret12 145.525 +0 High - 60 - - 3 82.5 82.5 12.5 13 Secret13 145.525 +0 High - 60 - - 3 82.5 82.5 12.5 ```As a result, when dmrconf reads from the radio it chokes with:
and QDMR doesn't choke, it just happily appears to work (though the import status bar shows 99%), but channels past the missing #11 are absent from the channel list, dropped from the Zone list, etc.
QDMR does however notice that something's afoot; the import status bar stops at 99% (See the screenshot above) and you can find this in the console:
I think it should either, you know, work, or fail. It's too easy to think your import went well and then blow away a bunch of config on your radio, only to notice it months later when you go to switch to your "IMPORTANT BUT RARELY USED CHANNELS" zone.
I suspect that this also applies to group IDs.