There are some valid channels in my radio that CHIRP doesn't see as valid after downloading the radio's memory to CHIRP.
There are also some empty (invalid) channels in my radio that CHIRP does see as valid and encounters errors trying to interpret the channel data because the channels are not really valid.

Version info¶

Testing/debug was based on git commit aad8664c7f296cc257e8adf6f3d105ec39f28e46 using the "KG-UV9D Plus" driver.

Valid channels that show as invalid in CHIRP¶

Example channels shown below that should be valid but aren't interpreted as valid by CHIRP: 1, 3, 4, 6
The "valid" or "state" information for each of those channels is found in the second to last column of the first, third, fourth, and sixth data rows below:

DEBUG: Config read (0xa00):
0x0a00: 00 dd d1 28 00 dc e6 c8 04 0b 04 0b 03 d0 01 00   ...(............
0x0a10: 02 a6 71 a4 02 ae 12 c4 03 e8 03 e8 03 d0 02 00   ..q.............
0x0a30: 02 a1 d4 00 02 a9 75 20 03 e8 03 e8 03 d0 01 00   ......u ........
0x0a60: 02 a1 63 b2 02 a9 04 d2 04 30 04 30 03 d0 80 00   ..c......0.0....

DEBUG: Config read (0xa40):
0x0a40: 02 a1 ac f0 02 a9 4e 10 06 56 06 56 e3 d0 fc ff   ......N..V.V....
0x0a50: 00 e0 26 d0 00 df 3c 70 03 e8 00 00 03 d0 80 00   ..&...<p........
0x0a70: 02 a6 67 e0 02 ae 09 00 03 e8 00 00 e3 d0 fc ff   ..g.............
0x0aa0: 00 e0 46 10 00 df 5b b0 04 0b 00 00 e3 d0 fc ff   ..F...[.........

In other words, this dump shows that "state" values of 0x01 and 0x80 can be considered valid.

In chirp/drivers/kguv9dplus.py I see the following related code starting at line 1429:

    if _valid not in VALID_MEM_VALUES:
        # In Issue #6995 we can find _valid values of 0 and 2 in the IMG
        # so these values should be treated like MEM_VALID.
        # state value of 0x40 found in deleted memory - still shows in CPS
        mem.empty = True
        return mem
    else:
        mem.empty = False

For context:

MEM_VALID = 0xfc
MEM_INVALID = 0xff
VALID_MEM_VALUES = [MEM_VALID, 0x00, 0x02, 0x40, 0x3D]

So it seems that CHIRP already has some exceptions to the idea that only a "state" value of 0xFC means a valid memory channel. Values 0, 2, and 0x40, and 0x3D were previously made exceptions and counted as valid memory channels. My memory dump shows that 0x1 and 0x80 should also be added to that list.

Invalid channels that CHIRP interprets as valid¶

I also encountered what is essentially the opposite problem. In my radio I don't have any valid channels after channel 314. However, CHIRP is interpreting the download from the radio as having channels 998 and 999 valid. This results in errors because the rest of the data for those channels is invalid. Channels 998 and 999 correspond to the second and third data rows of the below output (again, the "state" byte is the second to last column):

DEBUG: Config read (0x4840):
0x4840: ff ff ff ff ff ff ff ff ff ff ff ff ff fd ff ff   ................
0x4850: ff ff ff ff ff ff ff ff 00 00 00 00 0f 5d 00 00   .............]..
0x4870: ff ff ff ff ff ff ff ff 00 00 00 00 0f 5d 00 00   .............]..
0x48a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   ................

So now we have an example of "state" value of 0 being used for an invalid channel memory. This is in contradiction to the existing code shown above that makes "state" value of 0 be interpreted as a valid channel.

What I would propose here is that the use of VALID_MEM_VALUES be qualified with another indication of the channel being valid - such as receive frequency not being 0xFFFFFFFF and the channel memory name not being blank. If that is too aggressive (for example could we possibly have a valid channel with a blank name?) then maybe it could be qualified only by receive frequency not being 0xFFFFFFFF.

I might even go so far as to say we should consider using _valid != MEM_INVALID rather than a specific list of VALID_MEM_VALUES as long as we qualify with (_mem.rxfreq != 0xFFFFFFFF) though that is obviously a more aggressive change.