Bug #3387

FT-2900E, can't get past header

Added by Marius Stan almost 4 years ago. Updated almost 4 years ago.

Status:New Start date:02/24/2016
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Platform:Windows
Model affected:Yaesu FT-2900E

Description

Hello,
I'm not able to read my FT-2900E. The debug log follows.
All I could see was that the header is slightly different from the one coded in ft2900.py ?
I'm under windows here, if that matters somehow...

ft2900.py:
IDBLOCK = "\x56\x43\x32\x33\x00\x02\x46\x01\x01\x01"

my ft2900:
56 43 32 33 00 02 c7 01 01 01

here's the relevant debug log:

[2016-02-24 18:54:40,549] chirp.ui.reporting - DEBUG: Checking for updates
[2016-02-24 18:54:41,766] chirp.ui.reporting - DEBUG: Server reports version daily-20160224 is latest
[2016-02-24 18:55:07,809] chirp.ui.mainapp - DEBUG: User selected Yaesu FT-2900E/1900E on port COM16
[2016-02-24 18:55:07,989] chirp.ui.clone - DEBUG: Clone thread started
[2016-02-24 18:55:07,990] chirp.drivers.ft2900 - DEBUG: in _download

[...]

[2016-02-24 18:55:11,506] chirp.drivers.ft2900 - DEBUG: Header:
000: 56 43 32 33 00 02 c7 01 VC23....
008: 01 01 00 00 00 00 00 00 ........

[2016-02-24 18:55:11,506] chirp.drivers.ft2900 - DEBUG: len(header) = 10

[...]

[2016-02-24 18:55:13,019] chirp.ui.reporting - DEBUG: Reporting exception
[2016-02-24 18:55:13,019] chirp.ui.common - ERROR: -- Exception: --
[2016-02-24 18:55:13,019] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 238, in run
File "chirp\drivers\ft2900.pyo", line 448, in sync_in
RadioError: Failed to communicate with radio: Failed to read header

[2016-02-24 18:55:13,019] chirp.ui.common - ERROR: ----------------
[2016-02-24 18:55:13,019] chirp.ui.clone - ERROR: Clone failed: Failed to communicate with radio: Failed to read header
[2016-02-24 18:55:13,028] chirp.ui.clone - DEBUG: Clone thread ended
[2016-02-24 18:55:13,030] chirp.ui.reporting - DEBUG: Reporting model usage: Yaesu_FT-2900E/1900E,download,True
[2016-02-24 18:55:13,032] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Failed to communicate with radio: Failed to read header ---
[2016-02-24 18:55:13,032] chirp.ui.inputdialog - ERROR: Traceback (most recent call last):
File "chirpw", line 66, in <module>
AttributeError: 'NoneType' object has no attribute 'split'

patch.diff (1.5 kB) Daniel Clerc, 04/14/2016 08:00 am

IMG_3711.jpg - Programming Cable for FT2900 (1.3 MB) Daniel Clerc, 04/14/2016 08:15 am

Associated revisions

Revision 2657:1c398653986f
Added by Richard Cochran almost 4 years ago

[FT2900] Allow support of modded variant of FT-2900. Fix #3387
This adds a new registered radio class with appropriate IDBLOCK to
support a modified variant of FT-2900/FT-1900 for upload/download.

Bug #3387

History

Updated by Marius Stan almost 4 years ago

Upon more googling I've come across this explanation:

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

quoted from http://chirp.danplanet.com/issues/2501

The status of Bug 2501 is unclear to me, but it looks like it's still open ?

Updated by Richard Cochran almost 4 years ago

Thanks for your report.

I've just played with the driver a bit. I can make the driver be more accepting of alternate versions of the ID block when downloading from the radio to the computer. However, when uploading from the computer to the radio, the computer must send exactly the proper ID block on the first try, because the radio is not forgiving of alternate versions that may be sent from the computer. And unfortunately, the .img file does not have the idblock stored in it, at least not that I can see.

It's late at night for me right now, so I'm going to sleep on this and attack it tomorrow at the earliest. But I think the most straightforward solution is to create another radio version with an alternate IDBLOCK, similar to what you can see is already there in ft2900.py for the US versus Euro versions. That would mean you'd need to select the proper radio version from the list of supported radios -- the only difference between the current FT-2900E and the proposed new one would be the IDBLOCK and name, I think.

For clarity: is your radio a European version with transmit limits opened up? If you know exactly which solder jumpers are closed and which are open on your radio, that info might allow me to temporarily mod my own radio to match yours, so that I can easily test and confirm that my solution idea will work before I submit it.

As for issue 2501, the original problem reported was that the Euro version of the radio didn't work at all, and that problem was fixed, for the standard Euro version. I see that there were some further comments about a problem with a radio that had expanded transmit opened up, and the later problem seems to be the same as what you're reporting. But I am just now seeing those comments. Oops.

Updated by Marius Stan almost 4 years ago

Thanks for the update.
Since I started fiddling with this issue I've managed to run the daily version under python for windows.
This allowed me to play with ft-2900.py. I've already modified the IDBLOCK to suit my station, but haven't progressed further.
The ACK is set to 0x06 and I think it's correct. Tried a few more values found in vartious yaesy drivers, but 0x06 is the only one getting a response from the transceiver. Still, for some unknown reason the station's reply to 0x06 is 0x04 instead of the expected 0x06 ...
Even if I choose to ignore the mismatch (by commenting the echo exception) chirp stops after this, as the radio doesn't send any memory block after 0x04.
I'm sorry I don't have the log with me right now, I'll update later if needed.
I didn't open my station, so I don't know which jumpers are set. But the ebay seller indeed specified that the station has expanded TX.
Also tried the software from this address: http://www.g4hfq.co.uk/ftb19002900.htm
Same results, it can't read the receiver.
As I do get the header, I'm assuming the cable is ok. Sadly I don't have another one to try it out.

Updated by Daniel Clerc almost 4 years ago

Hi Marius!

I've submitted a patch to fix that issue. Once it is intergrated, your issue will be solved. If you feel save working with patches on the source, please find the patch attached!

Best,

Daniel

Updated by Daniel Clerc almost 4 years ago

Hi Marius!

I re-read your issue. I had the same trouble due to a broken cable. I eventually found out that I needed to have a pull-up resistor in the TX-RX line connection of the cable. Please find attached an image for illustration.

Best, Daniel

Also available in: Atom PDF