Bug #11179
closedLanchoNLH HG-UV98: Cannot clone from radio using current CHIRP next-20240217 regardless of platform
100%
Description
I tried cloning from radio using CHIRP next-20240217 on MacOS 14.3.1 as well as a Windows VM, using a FTDI cable and the included cable. I was expecting to see the usual editable channel table, but the result was the same for all combinations:
The Chirp GUI shows progress until completion as it is cloning from radio. Then nothing happens other than the radio rebooting and the unsuccessful download being stored in the backup folder (8kB image attached). Chirp is not using much CPU time at this point.
The log shows many DEBUG messages during the download itself and ends with this traceback:
[2024-02-17 13:50:45,859] chirp.wxui.main - INFO: Saved backup to /Users/laufer/.chirp/backups/Lanchonlh_HG-UV98_20240217T135045.img
Traceback (most recent call last):
File "chirp/wxui/main.py", line 1517, in _menu_download
File "chirp/wxui/main.py", line 205, in __init__
File "chirp/wxui/memedit.py", line 1161, in refresh
File "chirp/wxui/memedit.py", line 1067, in refresh_memory
File "chirp/wxui/common.py", line 290, in do_radio
File "chirp/wxui/memedit.py", line 1063, in get_cb
File "chirp/wxui/common.py", line 290, in do_radio
File "chirp/wxui/memedit.py", line 1046, in extra_cb
File "chirp/wxui/memedit.py", line 958, in _refresh_memory
File "chirp/wxui/memedit.py", line 918, in mem2row
KeyError: 'A'
I also get a corresponding popup when trying to open the backup file manually:
An error has occurred
'A'
Files
| chirp.config (347 Bytes) chirp.config | |||
| Lanchonlh_HG-UV98_20240217T164209.img (8.17 KB) Lanchonlh_HG-UV98_20240217T164209.img | BACKUP image created just before traceback | ||
| hg_uv98.py (25.6 KB) hg_uv98.py | 47f9140a | ||
| clipboard-202402191019-n9y6k.png (14.1 KB) clipboard-202402191019-n9y6k.png | Memory channel selection ending at 127 | ||
| hg_uv98.py (25.7 KB) hg_uv98.py |
Updated by Dan Smith about 1 year ago
- File hg_uv98.py hg_uv98.py added
Try this module please. Instructions at LoadingTestModules .
I'm not sure this driver has been tested in chirp-next yet, so there may be other issues. Please test and report back please!
Updated by Konstantin Läufer about 1 year ago
Dan Smith wrote in #note-1:
Try this module please. Instructions at LoadingTestModules .
I'm not sure this driver has been tested in chirp-next yet, so there may be other issues. Please test and report back please!
Amazing, thanks! Will try in a bit and report back.
Updated by Konstantin Läufer about 1 year ago
Dan Smith wrote in #note-1:
Try this module please. Instructions at LoadingTestModules .
I'm not sure this driver has been tested in chirp-next yet, so there may be other issues. Please test and report back please!
This driver works for me round-trip!!! Thanks again for your prompt help!
I'll let you know if anything else comes up.
Updated by Dan Smith about 1 year ago
Okay very good to hear. I'll queue this for the next build in a few days, thanks.
Updated by Konstantin Läufer about 1 year ago
Dan Smith wrote in #note-4:
Okay very good to hear. I'll queue this for the next build in a few days, thanks.
Thanks again, everything has been working great so far!
There is a very minor off-by-one error preventing channel 128 from coming up in Settings > VFO > Memory Channel A/B.
Updated by Dan Smith about 1 year ago
- File hg_uv98.py hg_uv98.py added
Okay, that seems to be a bug that has been in the driver forever, so technically a different thing. But here's an update with it and I'll just sweep this in with the main fix.
Updated by Dan Smith about 1 year ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|d70f2e8f88210c0079e0e3f1a4576243369d82be.
Updated by Konstantin Läufer about 1 year ago
Dan Smith wrote in #note-6:
Okay, that seems to be a bug that has been in the driver forever, so technically a different thing. But here's an update with it and I'll just sweep this in with the main fix.
Fantastic, thank you, it's working!!!