Bug #2501

Yaesu FT-1900r can not read header

Added by Dennis Andersen almost 5 years ago. Updated almost 3 years ago.

Status:Feedback Start date:04/05/2015
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Platform:Windows
Model affected:FT-1900r

Description

Tried to program my Yaesu FT-1900r today.
After conneting cable, and following read procedure as per chirp program daily build 20150504 it returns :

Failed to communicate with radio: Failed to read header.

Just to rule out cable failure, it would read from radio with G4HFQ software.

Best regards
OZ2DA
Dennis Andersen

ft2900eu.py - Driver for European FT-2900 models (41.6 kB) Mikael Grön, 04/15/2017 05:07 am

Associated revisions

Revision 2545:cd38cf8f4096
Added by Richard Cochran almost 5 years ago

[ft2900] Support Euro version of FT-2900/FT-1900 (#2501)
This patch adds support for the Euro version of the FT-2900/FT-1900
radio, which uses a different header IDBLOCK than the US version. We
make the IDBLOCK a class variable, and then create a subclass for the
Euro version, with an override to the IDBLOCK.

Revision 2555:f9d1d08e7c99
Added by Richard Cochran almost 5 years ago

[ft2900] Fix checksum calc for Euro version of FT-2900/FT-1900 (#2501)
This patch fixes the checksum calculation for the European versions
of the FT-2900/FT-1900 radio. The US and Euro versions have different
IDBLOCK strings. It turns out that the radio's checksum algorithm
includes the IDBLOCK data as it calculates the checksum, but the
original CHIRP ft2900 driver code hadn't taken this into account.
The differences in the IDBLOCK strings were causing checksum
mismatch.

History

Updated by Richard Cochran almost 5 years ago

This may be due to a Dennis' radio returning a slightly different header than the one used for development/testing. Maybe due to it being a non-US version? Or maybe an older or newer version of the firmware? Regardless, I will correspond with Dennis via e-mail to do some debugging so we can figure out exactly what header his radio is returning.

Richard Cochran

Updated by Richard Cochran almost 5 years ago

Update: Dennis has e-mailed me the information from his debug.log, showing what his radio is returning as its header. His is a European version of the FT-1900. The radio returns:

[2015-04-07 12:29:52,792] chirp.drivers.ft2900 - DEBUG: Header:
000: 56 43 32 33 00 02 41 02 VC23..A.
008: 01 01 00 00 00 00 00 00 ........

[2015-04-07 12:29:52,792] chirp.drivers.ft2900 - DEBUG: len(header) = 10

I will incorporate this into the code in ft2900.py later today.

Updated by Christiaan Adams over 4 years ago

Hi, I'm also seeing this issue. When trying to download from my FT-1900R, I get the message:
"An error has occurred Failed to communicate with radio: Failed to read header"

Admittedly, I am trying this with a partially home-made cable, so not sure if the issue might be the cable. I am using a Retevis 6 in 1 cable (http://www.retevis.com/radio-accessories/cables/6-in-1-radio-usb-program-programming-cable-adapter-universal), which works fine with my Baofeng UV-5R. For my FT-1900R, I wired the cable's shield to the Ground wire on my mic cable, and the cable's tip to the PTT/DATA wire on my mic cable.

When I follow the procedure to download data from the radio, the radio displays "--TX--", but after a few seconds, Chrip pops up with the message above. And then about 10 seconds later, the radio displays "ERROR".

Any suggestions for how I can test that the cable is working correctly? Or how can I send you the data that I'm getting from my radio (if any) to see if I have a different header?

Happy to help debug. Thanks for any advice! -Chris KJ6WEG

Updated by Christiaan Adams over 4 years ago

An update... I purchased a proper programming cable, and unfortunately it's still not working.

I got the Valley Enterprises RPC-YM6-UF FTDI based USB cable, intended for the FT-1900. I tried hooking it up and downloading with CHIRP. After connecting the cable, powering up the radio into clone mode, and pressing the "SET MHz" button, the radio displays "--TX--" as expected, and the red LED on the cable blinks momentarily, but then CHRIP reports the same error: "An error has occrurred Failed to communicate with radio: Failed to read header".

I even opened up the radio and made sure the Wide TX mod was not enabled, did a full reset of the radio, and installed the latest FTDI drivers for the cable. Still produced the same error.

So, any suggestions for how to debug? Is the brief blink of the red LED the header coming down and therefore CHIRP is getting it but not recognizing it? Or is it possible that the radio is simply not sending the data correctly? Any other ways to tell if the issue is with the radio, cable, or CHIRP? Thanks! -Chris

Updated by Tom Hayward over 4 years ago

"An error has occrurred Failed to communicate with radio: Failed to read header".

This means Chirp didn't receive the radio header on the COM port you specified. This can mean a number of things:

  • You specified the wrong COM port
  • You don't have the right driver installed (FTDI usually auto-installs, so I doubt this is your issue)
  • Some other cable problem between you and the radio
  • Didn't hit the SET MHz button quick enough and Chirp timed out.
  • Or, as in the post above, the radio returning a slightly different header than the one used for development/testing

Your debug.log might offer additional clues. See how to report issues.

Updated by Christiaan Adams over 4 years ago

Hi Tom, thanks so much for the advice, and for the link to the "How to report issues" page... lots of good stuff on the wiki's developers pages that I hadn't found before, especially about the debug.log file. I also realized this question would have been a better posted on the mailing list, which I just joined... next time.

So, wouldn't you know it, last night when I tried again, it all worked. What I think happened is that I hadn't correctly reset the radio after undoing the expanded TX mod (re-soldering jumper 3). Once I reset it, everything worked like a charm, and I was able to download/upload from/to the radio.

Just to test, I went back and re-applied the expanded TX mod and reset the radio. Sure enough, CHIRP gave me the previous errors again. Looking more closely at the serial comms, I see that with the expanded TX mod, the header sent from the radio changes slightly:
Normal header: 56 43 32 33 00 02 46 01 01 01
Wide TX header: 56 43 32 33 00 02 c7 01 01 01
(note "c7" in 7th position)

So, for now I've un-done the expanded TX mod again, and programmed my radio, which is great. But, I would really like to be able to program it with expanded TX, since I need some 155.xxx MHz frequencies which my SAR team has licenses for. Is this a common problem that modified radios send different headers? Is it an easy fix to add the alternative header, or does a radio with expanded TX have a different memory structure that would require reverse-engineering and another radio definition?

Updated by Tom Hayward over 4 years ago

  • Status changed from New to Feedback

That's some great detail, thanks. It shows that the header includes both model and region codes. Chirp should probably ignore the region and only act on the model code (first four bytes?), that way all regions could be supported.

Maybe this is for the best. If you are in the United States, the FT-1900 can only be used under Part 97 (ham) licenses. It is not certified for Part 90 (SAR / 155.xxx) licenses. I know at least one SAR team in our area that has had their license revoked for using ham radios on 155.xxx MHz.

Updated by Christiaan Adams over 4 years ago

Tom, thanks for the feedback, glad the details are helpful! Sounds like only acting on the model code would be a good update which could avoid other issues in the future. I'm very aware of the regs, certification status, and legal limitations. I would still like to be able to program this rig in all its modes. Is the suggested change something you think could be added to CHIRP, or will I have to figure out how to set up a dev environment and build a custom version myself? I would offer to attempt submitting the change, but my coding skills are limited, so I'm sure you or another dev can do a much better job.

Updated by Paolo Borsa almost 3 years ago

Hello, I also have the header issue, can't get past it. I have a FT-2900R purchased in Hong Kong, maybe the Asian version is even further different? If needed I can do a few connection test on the radio. My chirp is daily-20170311, on linux.
On the CLI launching chirpw, I read this:

ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/chirp/ui/clone.py", line 249, in run
self.__radio.sync_in()
File "/usr/lib64/python2.7/site-packages/chirp/drivers/ft2900.py", line 541, in sync_in
raise errors.RadioError("Failed to communicate with radio: %s" % e)
RadioError: Failed to communicate with radio: Failed to read header

ERROR: ----------------
ERROR: Clone failed: Failed to communicate with radio: Failed to read header
ERROR: --- Exception Dialog: Failed to communicate with radio: Failed to read header ---
ERROR: None

Regards, Paolo

Updated by Paolo Borsa almost 3 years ago

Edit: the debug log return this header

[2017-03-21 15:39:45,122] chirp.drivers.ft2900 - DEBUG: Header:
000: 56 43 32 33 00 02 c3 02 VC23....
008: 01 01 00 00 00 00 00 00 ........

my radio is FT2900R stock, no modding whatsoever, but purchased in Asia. So maybe asian version has a different header?

I altered the IDBLOCK field of ft2900.py in /usr/lib64/python2.7/site-packages/chirp/drivers and the download proceed without problems. Appearently, the data of the radio was correctly downloaded to chirp.

I am, however, a bit unsure if it would be safe to upload it back again.

Regards

Paolo

Updated by Mikael Grön almost 3 years ago

I "solved" this issue by copying

/Applications/chirp.app/Contents/Resources/chirp/chirp/drivers/ft2900.py
to
/Applications/chirp.app/Contents/Resources/chirp/chirp/drivers/ft2900eu.py
and replacing
IDBLOCK = "\x56\x43\x32\x33\x00\x02\x46\x01\x01\x01"
with
IDBLOCK = "\x56\x43\x32\x33\x01\x02\x41\x02\x01\x01"

Basically I just copied the actual header data from debug.log and pasted it to the IDBLOCK variable, after some hexadecimal conversion.
It worked perfectly for both uploading and downloading.

A better solution, to ignore the region letter (F in the original case, A in mine and Richard Cochrans cases) would probably be better.

Also available in: Atom PDF