[chirp_devel] Updates to ICOM IC-Vx Radios
On Wed Sep 29 18:15:07 PDT 2021, Dan Smith wrote:
[kosta] I have tested them against the ICF files, which plainly put is simply a hex dump representation of the binary image.. Currently ICF files are opened as read only, so in theory if we had a mechanism to serialize from image to ICF we could run the tests?
Okay, I forget if you can open as ICF and then save as .img. Technically you should be able to, but I can't remember if the UI will let you. Either way, if we're going to get someone to test these (and we should) we should just get images from them at the same time.
[kosta] I can certainly understand the hesitancy, however given that they are clearly marked as experimental could we consider releasing these in hopes that some user may attempt to run them and thus is more likely to provide an image? As it stands with no support for these radios, users are not provided any mechanism in which to generate an image to begin with... By releasing the experimental drivers we increase the likelihood of potentially receiving feedback and/or getting an image from some user - and assuming their expectations are tempered, impact to the community should be low. This does not alleviate our desire to test on actual hardware, but considering the scarcity of some of these radios it may be something to think about...
Yeah, to me experimental means "we think this works but probably isn't perfect." It's a far cry from "this has never talked to a real radio" IMHO.
Users can load the .py as a module to test it, so if there are users asking for these in a bug, you should be able to send that to them to let them try it before we commit.
--Dan
I have one of these radios, so I'm reviving this thread more than a year later :)
I'd noticed that the bug corresponding to the IC-V80 (797) is closed here, but there doesn't seem to be support: https://chirp.danplanet.com/issues/797
I found this thread on the list archives, so I went ahead and grabbed the patchset of three, fixed a few compilation issues that kept it from working (manglings of @ by the list software / using `mem.number` in the `_set_memory` function), and dropped it into /Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icv80.py on my Mac. Those changes as a single commit: https://github.com/billatq/chirp/commit/ef9f1b4c0d7ed20bc31b10767c5df59d9a05...
I found that while I'm able to clone into chirp, I can't clone back out into the radio.
Does anyone have any suggestions for where to look next? I'm assuming that the ICV80_MEM_FORMAT is likely incorrect?
Additionally, for testing purposes, what's the best way to capture an image from my radio? I didn't see anything obvious in the documentation, but I could easily have missed something.
--Bill
Error from the console is as follows: ==== ERROR: Failed to communicate with the radio Traceback (most recent call last): File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icf.py", line 489, in clone_to_radio return _clone_to_radio(radio) File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icf.py", line 476, in _clone_to_radio raise errors.RadioError("Did not get clone result from radio") RadioError: Did not get clone result from radio ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/ui/clone.py", line 253, in run self.__radio.sync_out() File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icv80.py", line 187, in sync_out icf.IcomCloneModeRadio.sync_out(self) File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icf.py", line 871, in sync_out clone_to_radio(self) File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icf.py", line 492, in clone_to_radio raise errors.RadioError("Failed to communicate with the radio: %s" % e) RadioError: Failed to communicate with the radio: Did not get clone result from radio
ERROR: ---------------- ERROR: Clone failed: Failed to communicate with the radio: Did not get clone result from radio ERROR: --- Exception Dialog: Failed to communicate with the radio: Did not get clone result from radio --- ERROR: None
ERROR: ---------------------------- ====
I have one of these radios, so I'm reviving this thread more than a year later :)
It took me a bit to find the context, here for anyone else:
http://intrepid.danplanet.com/pipermail/chirp_devel/2021-September/006560.ht...
I found this thread on the list archives, so I went ahead and grabbed the patchset of three, fixed a few compilation issues that kept it from working (manglings of @ by the list software / using `mem.number` in the `_set_memory` function), and dropped it into /Applications/CHIRP.app/Contents/Resources/chirp/chirp/drivers/icv80.py on my Mac. Those changes as a single commit: https://github.com/billatq/chirp/commit/ef9f1b4c0d7ed20bc31b10767c5df59d9a05...
At quick inspection, I can see that the _endframe isn't complete and that will keep the radio from ingesting the image. I'm guessing that since the original author didn't have the radio, he was unable to determine what the proper thing was (another good reason for us not to put it into the tree until it's tested). If you have a radio and can clone from it, recent versions of CHIRP will log the endframe to the debug log. There is a two-byte value after "Icom Inc." that each radio emits at the end of the clone. Find that from your log, update _endframe and try again.
Also _memsize looks suspiciously small as well, and that will defeat a write to the radio. Grab a download from the radio and then look at the ending address of "IcomCloneFormat3" to get the size. Also, most of those older radios didn't take a full image on clone in (which is what _ranges is for). Some require you not write to certain ranges, so if that radio doesn't like that, it'll reject an image. That usually happens mid-stream, so if it looks like everything is going well and it fails at the very las minute, then it's probably _endframe.
Does anyone have any suggestions for where to look next? I'm assuming that the ICV80_MEM_FORMAT is likely incorrect?
Not likely related to MEM_FORMAT if you're trying to dump the image unchanged back into the radio.
Additionally, for testing purposes, what's the best way to capture an image from my radio? I didn't see anything obvious in the documentation, but I could easily have missed something.
You said you can download from the radio right? File->Save ... that's an image. Are you looking for something else?
--Dan
On Nov 29, 2022, at 00:08, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
At quick inspection, I can see that the _endframe isn't complete and that will keep the radio from ingesting the image. I'm guessing that since the original author didn't have the radio, he was unable to determine what the proper thing was (another good reason for us not to put it into the tree until it's tested). If you have a radio and can clone from it, recent versions of CHIRP will log the endframe to the debug log. There is a two-byte value after "Icom Inc." that each radio emits at the end of the clone. Find that from your log, update _endframe and try again.
Thanks, appreciate the explanation. I'm seeing this in the debug log:
======== 2022-11-30 01:30:03,102] chirp.drivers.icf - DEBUG: End frame (11): 000: 49 63 6f 6d 20 49 6e 63 Icom.Inc 008: 2e 37 34 .74.....
[2022-11-30 01:30:03,102] chirp.drivers.icf - DEBUG: Last addr: 0e80 ========
From that, I updated the string to be "Icom Inc\x2e\x37\x34". Looks like it's still getting to the almost the end, then displaying Err and failing to clone.
Also _memsize looks suspiciously small as well, and that will defeat a write to the radio. Grab a download from the radio and then look at the ending address of "IcomCloneFormat3" to get the size. Also, most of those older radios didn't take a full image on clone in (which is what _ranges is for). Some require you not write to certain ranges, so if that radio doesn't like that, it'll reject an image. That usually happens mid-stream, so if it looks like everything is going well and it fails at the very las minute, then it's probably _endframe.
From the above, does 3712 (0xE80) seems more reasonable for the memsize given that it's after the end frame? I set the memsize to arbitrary larger numbers, but I still seem to end at that spot on a read.
It wasn't obvious to me how I'd be able to get IcomCloneFormat3 from the radio. I flipped on TRACE_ICF, but the only place I'm seeing Icom in the log is in the end frame.
Since yesterday, I was also able to get a copy of the Icom CS-V80 software and can now produce ICF files from the radio (attached). I can also do some basic capture over serial now from the CS-V80 software talking to the radio, but I'm a bit stuck as where to go next. Should I be looking at the serial traffic on the Icom software and figuring out what frames are doing writes and to what addresses, or is there a more straightforward path that I'm not seeing?
Thanks, William Reading
From the above, does 3712 (0xE80) seems more reasonable for the memsize given that it's after the end frame? I set the memsize to arbitrary larger numbers, but I still seem to end at that spot on a read.
Possibly, but it's still really tiny. Smaller than the smallest old Icom I have.
It wasn't obvious to me how I'd be able to get IcomCloneFormat3 from the radio. I flipped on TRACE_ICF, but the only place I'm seeing Icom in the log is in the end frame.
If it's the more older format, you may see a string of digits like the model number at the end. Look at the IC-2200, D800, 2820 images in the tree.
Since yesterday, I was also able to get a copy of the Icom CS-V80 software and can now produce ICF files from the radio (attached). I can also do some basic capture over serial now from the CS-V80 software talking to the radio, but I'm a bit stuck as where to go next. Should I be looking at the serial traffic on the Icom software and figuring out what frames are doing writes and to what addresses, or is there a more straightforward path that I'm not seeing?
Almost certainly nothing you need to do with the clone protocol itself. Chirp will eat the ICF file and let you save out a .img which will end up the proper size (minus the chirp metadata at the end).
If it still chokes with the proper size, then it's probably that it needs to skip one or more blocks when it writes. Look at the 2200 driver for example, where it defines _ranges. That controls what actually gets written to the radio. I don't know why some of those need to have part of their memory skipped on write, how that works on an actual radio-to-radio clone, or what, but those ranges are mirrors of what the CS software does. You'll have to get that via trace.
--Dan
participants (2)
-
Dan Smith -
William Reading