[chirp_users] KG-UV9D Mate issues, debug, and proposed change

[Jonathan Johnson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20230325/28358ca6/attachment.html