[chirp_devel] [kguv9dplus] Not all programmed memories showing
Hi CHIRP devs,
A Wouxun KG-UV9d+ user (John) reports in issue #6995 that CHIRP is not displaying any frequencies he set. I was able to reproduce this issue with the IMG file that John uploaded at https://chirp.danplanet.com/issues/6995
Upon inspection, in kguv9dplus.py on line 1099, we can find "if _valid != MEM_VALID:" and "mem.empty = True". It turns out that however John added these frequencies (via HT or manufacturer sw) the _valid variable sometimes has a value of 0, and sometimes 2.
One way to patch the driver is to change the logic so that "if _valid == MEM_INVALID:" then "mem.empty = True". Another way (proposed below) is to patch the driver to treat values of 0 and 2 like MEM_VALID.
Looking forward to feedback, Tony
--
# HG changeset patch # User Tony F goldstar611@hotmail.com # Date 1566779617 18000 # Sun Aug 25 19:33:37 2019 -0500 # Branch issue_6995 # Node ID 578b10fb85f16a4e50b80a4871fc26fd25ebaee4 # Parent f2f71d0cd6a9a2eadd18b6315afd6078a6519632 [kguv9dplus] Memories tab completely blank Fixes #6995 https://chirp.danplanet.com/issues/6995 Changes based on values in the uploaded IMG file
diff --git a/chirp/drivers/kguv9dplus.py b/chirp/drivers/kguv9dplus.py --- a/chirp/drivers/kguv9dplus.py +++ b/chirp/drivers/kguv9dplus.py @@ -1096,7 +1096,9 @@ mem = chirp_common.Memory() mem.number = number _valid = _mem.state - if _valid != MEM_VALID: + if _valid != MEM_VALID and _valid != 0 and _valid != 2: + # In Issue #6995 we can find _valid values of 0 and 2 in the IMG + # so these values should be treated like MEM_VALID. mem.empty = True return mem else:
if _valid != MEM_VALID:
if _valid != MEM_VALID and _valid != 0 and _valid != 2:
# In Issue #6995 we can find _valid values of 0 and 2 in the IMG
# so these values should be treated like MEM_VALID.
I would guess that this means the valid flag is actually one bit in that value and not the whole byte. So the right fix would be to check that bit and not compare it against all the possible values.
I've applied this, but would love to apply a follow-up which changes this to checking the bit :)
--Dan
participants (2)
-
Dan Smith
-
Tony Fuller