[chirp_devel] Updates to ICOM IC-Vx Radios

[Dan Smith]

> 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