Bug #10645
openIC-92AD read errors when downloading from radio
0%
Description
When trying to download from my IC-92AD Chirp will show errors (red label with !) for some channels, and also interleaves memories from the two banks - e.g. in the attached screenshot, starting at memory 21, the odd channels are from Bank A and evens are from Bank B. The same thing happens when I switch to the Bank B tab, except reversed - odds from Bank B and evens from Bank A.
The read results are not consistent, each read will have a different set of red "error" channels and missing / interleaved memory channels.
I am using an original Icom serial cable (DB9) with a SIIG USB-serial adapter (FTDI chip). This same behavior occurs on three different computers, in Linux, MacOS and Windows 10.
I loaded the Icom RS92 software on my Win 10 laptop and it works flawlessly, so the radio and serial cable appear to be fine.
Files
| 92ADLive_230615.png (119 KB) 92ADLive_230615.png | Screenshot of memory slots with errors | ||
| IC92AD_230618_Try2.log (939 KB) IC92AD_230618_Try2.log | |||
| IC92AD_230618_Try4.log (964 KB) IC92AD_230618_Try4.log |
Updated by Joe Martine 11 months ago
Dan Smith wrote in #note-1:
Can you look at the first memory in the radio (or RS92) and describe it for me? Any weird characters in the name? Set for some special mode or something out of the ordinary?
Bank A memory 000 is just 146.52 FM simplex, named '2M Call'. Bank B doesn't have 000. Both banks memory 001 is also 146.52, no name.
I see at least one problem I can fix, related to your DV channels. That's not the problem with the first few errors, but starting with memory 4.
Far as I can tell, scrolling through the radio, I don't even have any DV channels set up. Memory 4 on both banks is a regular FM repeater.
I have no problem wiping the radio and starting over, if you think that might help. It's been a LONG time since I was last using this radio, so I'm not sure if it even has a "reset" option...
Updated by Dan Smith 11 months ago
Actually, scratch the question about memory 1 and the statement about DV. I think maybe this is related to it trying to pull both A and B band memories at the same time. It should be only doing one at a time, but it looks like maybe something about that locking isn't working. The 92 is a strange duck - no other icom (or anything else) radio behaves quite like it.
I'll dig out my 92 tomorrow and see if something has regressed.
(just saw your reply)
Nope, don't reset it (yet). I'll circle back tomorrow.
Updated by Dan Smith 11 months ago
Since you're on linux, I assume you could do some testing from a git repo easily right? The ic9x driver is split between two files which makes LoadingTestModules not work as expected. But if you can, I can push something up to a branch for you to try.
This driver is a real mess, one of the oldest in the chirp tree, rarely ever used or maintained, an from a time period before a lot of conventions in chirp drivers were established. Basically, it's a big mess. I've got some hacks made to the driver that makes it load all the memories consistently for me, but it would be good to get confirmation from you that it does for you as well before I keep charging down this road.
Updated by Joe Martine 11 months ago
Dan Smith wrote in #note-6:
Since you're on linux, I assume you could do some testing from a git repo easily right? The ic9x driver is split between two files which makes LoadingTestModules not work as expected. But if you can, I can push something up to a branch for you to try.
Yes, with a bit of instruction. I'm not a full-time dev but have used git on occasion. I know enough to be dangerous, anyway... :)
Updated by Dan Smith 11 months ago
Okay, looks like you're using pipx, which may be a problem, but try this:
pipx install git+https://github.com/kk7ds/chirp@fix-ic9x
You probably have to uninstall the version of chirp you have installed with pipx first.
It's not perfect and still occasionally fails to talk to the radio, but it is substantially better-behaved in my experience.
Updated by Joe Martine 11 months ago
- File IC92AD_230618_Try2.log IC92AD_230618_Try2.log added
Yes, it performs much better.
On the first run Bank A had a block of about 10-15 unread (red with !) memories, and Bank B had just one. I tried adding new frequencies to some empty memory slots and was able to enter one, two others failed. I didn't get a log file for this run.
For the second and third runs I enabled log files and all memories read just fine. Still a bit intermittent whether I can create new / change entries, mostly works but occasionally fails.
I did get a new odd bug on the second and third runs though - I can't see what's in the currently-selected cell! If I click on a cell to enter or change data it goes blank. The data is there, I can for instance type a new frequency then tab to the next cell and the data shows up and is sent to the radio. Not sure why this happened only on subsequent runs, the first run I was able to see my typing just fine.
Just to make sure enabling the logfile didn't cause the invisible text, I ran again without a log file but still couldn't see the selected cell.
Log file for second run attached.
Updated by Dan Smith 11 months ago
The missing text thing is something specific to the GTK widgets on Linux and isn't related to any of this. I don't know why it happens, it almost never does for me but does more for some others. Try resizing the cells to see if that helps.
I don't see any obvious failures in your log, although it's super big. What memory were you editing when it failed?
Updated by Joe Martine 11 months ago
- File IC92AD_230618_Try4.log IC92AD_230618_Try4.log added
Changing the size of the window fixed the text.
I can't remember which memories had errors! I tried again, this time all changes I tried did work but some errors were generated on the console and in the log. They were in the end successfully updated. There are two examples of this at the bottom of the attached log, Bank B memory 20 (460.150) and 18 (118.400).
Updated by Dan Smith 11 months ago
Okay, cool, well, I'm thinking this is a substantial improvement from what is in the tree at the moment, so I'm inclined to push this through and then we can iterate on the details. I see the failures in the log - I'm guessing we're not waiting long enough for the set_memory response sometimes (or something like that).