CHIRP

-Duplicates #2303. Please leave further feedback there. Thanks!-

Having the same issue with my FT-2800M. I see in ft2800.py that the IDBLOCK is:
IDBLOCK = "\x0c\x01\x41\x33\x35\x02\x00\xb8"

However, when I put my radio into cloning mode and hit the MHz but to start transmission, I get this:
0C06000C014133350300B9

I changed the IDBLOCK line in ft2800.py to this:
IDBLOCK = "\x0c\x01\x41\x33\x35\x03\x00\xb9"
After doing this I no longer get the "Failed to read header" error but I'm still not able to read any additional data out of the radio after the header. I suspect that the ACK may need to change as well, but I'm not sure what it should change to.

Unlike the commenter above, the G4HFQ FTB2800 software does not seem to work with my radio.

It seems as though Yaesu may have changed the protocol for this radio partway through production, or perhaps there are different protocol variations for different destinations (USA, Europe, etc.)?

For reference, the serial number of my radio is 8L902088

Update - found that part of my issue was a bad cable that was only receiving from the radio but not sending to it, so the radio was not getting the ACK. After correcting that (and making the change to the header in the code that I mentioned above) the read process completes and I get data into CHIRP from the radio. However, the radio displays WARN008 after the read, where it normally reads PASS, and there may be some warnings/errors in CHIRP that I need to go back and look at. I will update again after trying to change parameters and send to the radio, but need to get my cable permanently fixed first.

Also after fixing my cable issue the G4HFQ FTB2800 software does work. So far it appears that the issue may simply be that there are multiple headers for this model of radio. I'll update as I learn more.

After some additional playing around, I'm realizing that the method I used to store the IDBLOCK from a download to reuse for an upload isn't ideal, as it doesn't get stored in the .img file. Performing a download and then switching to a saved .img file doesn't seem to work - the IDBLOCK doesn't get reused across "tabs" in the GUI it seems. I need to better understand the .img file format to see if there's a mechanism there that can be used to store the IDBLOCK.

The current solution works but requires a download and then an upload using the same "tab" in chirp. The data can from the download can be modified prior to the upload, but it's a bit cumbersome.

I created a new model "bug ticket" to add the 2900 to "Next" version.

https://chirp.danplanet.com/issues/10605