[chirp_devel] Updates to ICOM IC-Vx Radios

[William Reading]

On Nov 29, 2022, at 00:08, Dan Smith via chirp_devel <chirp_devel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icom-v80-2.icf
Type: application/octet-stream
Size: 9329 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20221130/e2c68358/attachment-0001.obj