CHIRP

I was having similar issues with a second-hand FT-7100M with serial number 1DXXXXXX.

The fix I found requires changes to the chirp/driver/ft7100.py script. In the _upload function on lines 136-137, the original 16-byte block sent by the script was not being accepted by my radio. In a modification to the _download function, I inserted a line to print out the 16-byte block read from the radio during a download. I found that this data is different from the original which is as follows (utilizing util.hexprint(data):

000: ee 77 01 00 0e 07 0e 07 .w......
008: 00 00 00 00 00 02 00 00 ........

I modified lines 136-137 with this information:

136 _send(radio.pipe, "\xEE\x77\x01\x00\x0E\x07\x0E\x07"
137 "\x00\x00\x00\x00\x00\x02\x00\x00")

This fixed my issue. This problem could be related to the differences between the several serial numbers this radio model went through over the course of its storied life. A more elegant solution would be to either create a sub-model for this radio depending on serial number or somehow use the 16-byte block read when downloading (line 94) and use it when uploading to the radio.

I have attached a copy of the script.

I now realize I accidentally uploaded the compiled Python script file. Here's the source file.

Tony, did you submit your patch on the developer's mailing list? See Developers. Thanks!

This ticket duplicates #4591. Please follow and post there.
I left a comment there to review the suggested patch.