Hi, first off I want to say thank you for this excellent software!
I'd like to report some issues with the KG-UV9D Mate support. I have debugged some channel memory loading issues and would like to report my findings and suggested changes. I can report what works for my scenario but of course you may have more information about previously reported issues with this radio so my proposed changes are only suggestions on how to deal with the issues.
My testing and debug has all been done with CHIRP-next from github.com/kk7ds/chirp, commit 60f989ccb337ad4a36a24bcc964948ae453c47cf and using the "KG-UV9D Plus" driver as recommended on a table I found on the website.
There are 2 separate but related issues I've seen while using CHIRP-next.
Issue #1:
There are some valid channels in my radio that CHIRP doesn't see as valid. Example channels shown below that should be valid but aren't interpreted as valid by CHIRP: 1, 3, 4 The "valid" or "state" information for each of those channels is found in the second to last column of rows 1, 3, and 4 of the following:
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....
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 1423:
if (_valid != MEM_VALID and _valid != 0 and _valid != 2 and _valid != 0x40): # 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
For context, MEM_VALID and MEM_INVALID definitions are: MEM_VALID = 0xfc MEM_INVALID = 0xff
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 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.
Issue #2:
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 rows 2 and 3 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 exception for "state" values of 0, 2, 0x40 (and now 0x1 and 0x80) only be applied if the receive frequency is valid (i.e. not 0xFFFFFFFF) and the channel memory name is not blank. There is precedent for something very similar in some existing code at line 1417 of the same file:
# Override Mem Valid state to handle quirky 9PX CPS New codeplug # issue where there is a channel programmed but the CPS # "state" value is 0xFF indicating an invalid memory if _valid == MEM_INVALID and _mem.rxfreq != 0xFFFFFFFF and _nam != '': _valid = MEM_VALID
So my overall patch to fix both issues (at least for my particular memory dump) is as follows:
diff --git a/chirp/drivers/kguv9dplus.py b/chirp/drivers/kguv9dplus.py index cc0f3df8..77df32e0 100644 --- a/chirp/drivers/kguv9dplus.py +++ b/chirp/drivers/kguv9dplus.py @@ -1420,8 +1420,7 @@ class KGUV9DPlusRadio(chirp_common.CloneModeRadio, if _valid == MEM_INVALID and _mem.rxfreq != 0xFFFFFFFF and _nam != '': _valid = MEM_VALID
- if (_valid != MEM_VALID and _valid != 0 and _valid != 2 and - _valid != 0x40): + if (_valid != MEM_VALID and not (_valid in [0, 2, 0x40, 0x3, 0x1, 0x80] and _mem.rxfreq != 0xFFFFFFFF and _nam != '')): # 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
Again, thank you for your efforts developing this software and I hope this report is useful.
Jonathan KI5RRE