Bug #3919
closedYaesu FT-2800M can't read header
Added by Richard Weller over 8 years ago. Updated over 1 year ago.
100%
Description
Does any one work on these old radios
I see in issues same problems long ago and still no fix
Error cant read header
Files
| debug.log (16.7 KB) debug.log | Richard Weller, 08/13/2016 09:35 AM | ||
| debug.log (16.8 KB) debug.log | Richard Weller, 08/30/2016 09:25 AM | ||
| debug.log (18.5 KB) debug.log | debug.log showing error | Predrag Supurovic, 12/02/2016 04:11 PM | |
| ft2800.py (8.58 KB) ft2800.py | Andy Knitt, 10/22/2020 08:45 AM |
Updated by Richard Weller about 8 years ago
still not working
Updated by Predrag Supurovic almost 8 years ago
I have the same problem with FT2800M. Reading memory from rig does not work. It ends up with message:
An error has occurred Failed to communicate with radio: Failed to read header
I use CHIRP daily-20161123 but older versions did not work too.
I tried reading with G4HFQ FTB2800 and it reads rig properly so I am sure my serial adapter works fine.
I see I am not the only one with this issue.
debug.log is in attachment.
Updated by Bernhard Hailer over 4 years ago
- Subject changed from FT 2800M to Yaesu FT-2800M can't read header
- Status changed from New to Feedback
- Priority changed from High to Normal
- Target version set to chirp-legacy
- Chirp Version changed from 0.4.0 to daily
- Model affected changed from Yeasu FT 2800M to Yeasu FT-2800M
Is this still an issue with the daily builds?
Updated by Bernhard Hailer over 4 years ago
-Duplicates #2303. Please leave further feedback there. Thanks!-
Updated by Bernhard Hailer over 4 years ago
- Status changed from Feedback to Closed
Updated by Andy Knitt about 4 years ago
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
Updated by Andy Knitt about 4 years ago
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.
Updated by Andy Knitt about 4 years ago
I believe I have this working now.
It turns out that the radio uses a different IDBLOCK if it has been modified for extended transmit. The attached modified version of ft2800.py accepts both the standard and extended TX IDBLOCK values and uses the value that was read during a download for the upload process.
I also confirmed that the WARN008 during a read occurs using the unmodified radio with the current CHIRP version, so that's "normal" for CHIRP and doesn't seem to hurt anything, even though FTB2800 gets PASS after a read. At some point I may try to see what FTB2800 is doing differently during a read to get the PASS (probably sending an ACK at the end or something), but for now, the attached file should work for Upload and Download with the two different FT-2800M IDBLOCK values. There may still be other IDBLOCK values out there that could be added in the future for additional compatibility.
I'm not at all familiar with Mercurial and getting set up with that to submit a formal change request seems a bit daunting, so if someone who's already set up for development would like to review this code and submit it, that would be appreciated.
Updated by Bernhard Hailer about 4 years ago
- Platform changed from Windows to All
Hi Andy, thanks for your work! You should still post your patch on the developer's mailing list so that the devs are getting aware of it.
We'll keep this ticket open until the patch has been reviewed and applied.
Updated by Andy Knitt about 4 years ago
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.
Updated by Doug Nelson over 1 year ago
I created a new model "bug ticket" to add the 2900 to "Next" version.
Updated by Andy Knitt over 1 year ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset github|848e37b7db92c6fa1c20df13be52ec58238706e3.