CHIRP

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 ?

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.

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.