CHIRP

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 ag6qr@sonic.net

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.

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

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

"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.

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?

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.

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

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