Bug #4545
closedICOM ID-51A Plus 2
Added by Justin Curti almost 8 years ago. Updated about 2 years ago.
100%
Description
Using a MacBook Pro, when trying to clone a Icom ID-51A Plus 2, a error message pops up: "Failed to communicate with the radio: I can't talk to this model". I have tried cloning in clone mode as well as in normal mode. I do not know if I am doing something incorrectly, or if there is a communication issue between CHIRP and this Icom model. Likewise, I did not see any other post on this particular model having issues.
Files
debug.log (30.5 KB) debug.log | Peter Kringle, 08/28/2020 12:41 PM | ||
Marc 20221112v2.icf (301 KB) Marc 20221112v2.icf | Marc Rieffel, 11/18/2022 01:26 AM | ||
Marc 20221112.icf (301 KB) Marc 20221112.icf | Marc Rieffel, 11/18/2022 01:26 AM | ||
id51plus-test1118.py (4.38 KB) id51plus-test1118.py | Dan Smith, 11/18/2022 10:40 PM | ||
debug.log (42.2 KB) debug.log | Marc Rieffel, 11/20/2022 02:33 AM | ||
debug.20221119.log (34.8 KB) debug.20221119.log | Marc Rieffel, 11/20/2022 03:37 AM | ||
id51plus.py (5.67 KB) id51plus.py | 97deb87ec2be2e3263f36b4289a81774d629822a | Dan Smith, 11/20/2022 05:09 AM | |
Icom_ID-51 Plus2_20221120.img (127 KB) Icom_ID-51 Plus2_20221120.img | Marc Rieffel, 11/20/2022 08:11 PM | ||
debug.20221120.log (45.9 KB) debug.20221120.log | Marc Rieffel, 11/20/2022 08:11 PM | ||
Icom_ID-51 Plus2_20221120.img (127 KB) Icom_ID-51 Plus2_20221120.img | Marc Rieffel, 11/20/2022 08:33 PM |
Updated by Scott Pettigrew over 7 years ago
I am also receiving this error on a daily build, installed on Linux Mint.
Updated by Gerry Carpinetti over 7 years ago
I have a ICOM ID-51A Plus 2 and receiving the same errors as mentioned above post on Windows 10
Updated by Mark MacConnell almost 7 years ago
Gerry Carpinetti wrote:
I have a ICOM ID-51A Plus 2 and receiving the same errors as mentioned above post on Windows 10
Anyone able to fix this problem. I just downloaded the most current version on Windows 10 and having this same problem.
Updated by Creede Lambard over 6 years ago
Not to turn this into a "me too" fest, but I'm having the same issue with this radio on both Windows 10 and Mac OS.
Updated by Bernhard Hailer over 4 years ago
- Status changed from New to Feedback
- Target version set to chirp-legacy
- Chirp Version changed from 0.4.0 to daily
- Model affected changed from ID-51A Plus 2 to Icom ID-51A Plus 2
- Platform changed from MacOS to All
Have you tried with a recent version since you submitted this?
If you haven't, and if you're still having this issue, please refer to the Wiki "How To Report Issues" and provide a debug log. Thanks!
Updated by Peter Kringle about 4 years ago
I just confirmed the same problem with MacOS 10.15.6 running CHIRP daily-20200827 I am attaching the debug log when i try both ID-51 and ID-51Plus options.
As a side note I also have an older ICOM 51 Plus which works perfectly, but the newer Plus2 does not.
Updated by Bernhard Hailer about 4 years ago
Thank you, the log is helpful. This radio has a new version number in its firmware:
[2020-08-28 12:39:39,639] chirp.drivers.icf - INFO: This model: 000: 33 90 00 03 00 00 00 00 3....... [2020-08-28 12:39:39,639] chirp.drivers.icf - INFO: Supp model: 000: 33 90 00 02 00 00 00 00 3.......
A developer needs to look into it and see what it takes to talk with this version.
Updated by Marc Rieffel about 2 years ago
Is the Plus2 still not supported? I'm not sure if this ticket is up to date, but I'm experiencing similar behavior with version daily-20221025 in November 2022. Thanks.
Updated by Marc Rieffel about 2 years ago
Would additional detail, logs, etc., help get this resolved?
Updated by Marc Rieffel about 2 years ago
- File Marc 20221112v2.icf Marc 20221112v2.icf added
- File Marc 20221112.icf Marc 20221112.icf added
Here are a couple of .icf files from my plus2 in case they're of any use.
Updated by Dan Smith about 2 years ago
- File id51plus-test1118.py id51plus-test1118.py added
I'm attaching a test module that hopefully makes the 51Plus2 just work. I don't have one to test with, but it looks like for CHIRP's purposes it's probably just a model number change.
Enable developer mode in Help, restart chirp, File->Load Module this file, test. Report with images and debug logs if there are problems. If it seem to work, report here and I'll include it in the next build.
Updated by Marc Rieffel about 2 years ago
I updated Chrip, enabled developer mode, and loaded the plus2 module. I get a red background. Then I do download from radio, 51aplus2. The radio gives one quick beep then I get a dialog "An error has occurred. Failure to communicate with the radio: unpack requires a string argument of length 4." But the radio keeps going with "CLONE OUT" for a while longer, gives a couple quick beeps, and returns to normal. So it seems the command to "read" went to the radio, which then sent its output, but Chirp isn't able to parse what comes back from the radio.
Are there additional debug logs I could provide that would help?
Thanks
Updated by Marc Rieffel about 2 years ago
debug.log attached.
Updated by Dan Smith about 2 years ago
Hi Marc, that looks like it might be a different bug that I introduced in the last day. Can you tell me what sort of cable you're using?
Regardless, you might want to back up two versions from current and try the module there to rule out the difference. You can find the older versions here:
https://trac.chirp.danplanet.com/chirp_daily/
I would try 20221109.
Updated by Dan Smith about 2 years ago
Actually, that could also be that the 51plus and 51plus2 differ by more than I expected. If you don't mind trying the older version to rule that out, that would help. If it turns out not to help, then that probably means it's the other thing and I'll generate a different module for you to try.
Updated by Marc Rieffel about 2 years ago
- File debug.20221119.log debug.20221119.log added
Same result with 20221109. Debug.log attached. Happy to keep trying these and sending debug.logs. Thanks.
Updated by Marc Rieffel about 2 years ago
And my cable is ICOM OPC-2350LU, plus a USB-A to microUSB adapter cable. Both came with the radio used, so I don't know if the adapter cable was originally included with the ICOM cable or not. But the combination worked fine for me when using the ICOM upload/download software, so I'm reasonably confident they work OK.
Updated by Dan Smith about 2 years ago
Okay, that's good news that the older builds behave the same. That means I didn't break anything :)
It likely means the Plus and Plus2 are more different than I expected, so I'll have to work on that a bit. I'm able to open your ICF file with the module loaded, so hopefully the memory format isn't much different.
Updated by Dan Smith about 2 years ago
- File id51plus.py id51plus.py added
Okay, here's another module to try. This is not something we can put into the main release, but it should help clarify if the difference is what I think it might be.
Best to update back to the latest version of chirp for this, especially tomorrow's build (20221120).
Thanks!
Updated by Marc Rieffel about 2 years ago
- File Icom_ID-51 Plus2_20221120.img Icom_ID-51 Plus2_20221120.img added
- File debug.20221120.log debug.20221120.log added
The latest 20221120 build gave me startup errors, so I went to yesterday's 20221119. Loaded the module fine. Connected radio, download from radio, SUCCESS!
The memories looked right (I'd only manually entered a few), bank names looked right, D-STAR callsign looked right (n.b. I'm new to D-STAR so don't know if I've configured it properly.)
Settings only shows one driver option, "Use Hi-Speed Clone", nothing more.
Then (not having made any changes in CHIRP) I did save-as. Resulting .img attached.
Then I did upload to radio, and that seemed to work fine. The radio still has my memories etc.
Debug.log attached.
Great progress!
Anything in particular that I should try next?
Updated by Marc Rieffel about 2 years ago
I was able to download some more memories from repeaterbook, copy some entries from other radios, etc. And they seemed to upload and work OK. Resulting .img attached.
Updated by Dan Smith about 2 years ago
Awesome, thanks for the report. I will need to do some work to make this into something I can put in the main build, but the hard work is done at least.
Yes, today's build is broken on windows and mac because of bug #10130.
Trying to tweak values in chirp and uploading them to see if the radio agrees would be my next step (which I see you've just now done - very nice). Also, if you can, a debug log from both an upload and download using tomorrow's build (since today's was broken) would be helpful as it will log some extra information for me.
In general, I don't spend a lot of time decoding the settings in the radio (i.e. the stuff under the Settings tab) except for very popular radios. The channels are very laborious to enter manually on the radio, and decoding the channel format once works for all 1000 memories. The settings on the other hand are ALL different and a lot of work. Thus, there's a lot of bang-for-buck on the channels, much less so on the settings.
If there's something specific in the settings that is likely to be helpful to have exposed in chirp, I can see about adding it for you, but no promises. It takes an enormous amount of time to decode all of them (especially for a complex radio like this) and other volunteers have spent years decoding all the bits from simpler and wildly more popular radios like the UV5R.
Updated by Dan Smith about 2 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset commit:286ed0727656.