Bug #10198
closedReading from Yaesu FT-4XE hang with error
100%
Description
Tested platform:
Ubuntu 22.04.1 LTS with chirp that install from "Ubuntu software" manager, daily 20221217
Win10 with lastest patches, 2 different machines, chirp daily 20221217 and one chirp version from 3/2022
All platform has similar behaviour and error messages
Cable: Yaesu SCU-59 (original USB version)
Radio: Yaesu FT-4XE, ser # 2J481xxx
Win10 machines has installed Yaesu own USB driver from yaesu.com product files page. Utility from same page work fine for both direction (read, write)
How to test/use:
- start app
- Radio > Download from Radio
- set proper cfg COM3 (same as hw manager view), Yaesu and model FT-4XE (try also XR, same result)
- check ok and select "next/ok" for following notes
- chirp start communicate to radio, as it shows "TX" and signal bar start going forward
- after while, it shows up attached error message.
Error messare is same in all platforms.
Files
| chirp_error2.PNG (15.8 KB) chirp_error2.PNG | port and radio select | ||
| chirp_error.PNG (16.5 KB) chirp_error.PNG | Error message | ||
| chirp_error3.PNG (32.7 KB) chirp_error3.PNG | usb-ser driver | ||
| chirp_log.txt (37.1 KB) chirp_log.txt | log | ||
| chirp_radio.JPG (122 KB) chirp_radio.JPG | Radio after sw start communication | ||
| ft4x_rd.txt (163 KB) ft4x_rd.txt | Successful read with Yaesu software | ||
| ft4x_wr.txt (197 KB) ft4x_wr.txt | Successful write with Yaesu software | ||
| ft4x_rd_chirp.txt (81.5 KB) ft4x_rd_chirp.txt | Failed attempt to read with Chirp |
Related issues
Updated by Dan Smith over 1 year ago
- Has duplicate Bug #10247: FT-4XE won't sync added
Updated by Beni K over 1 year ago
After fixing Bug #10275 this problem also affects CHIRP-next on Linux.
Updated by Mikel EA5IYL Forcada over 1 year ago
Beni K wrote in #note-2:
After fixing Bug #10275 this problem also affects CHIRP-next on Linux.
Yes, it persists on GNU/Linux, Ubuntu 22.04 in my case. I've used CHIRP next-20230116 on Python 3.10.6 wxPython 4.0.7 gtk3 (phoenix) wxWidgets 3.0.5.
It starts cloning and then fails, issuing this error: "Failed to communicate with radio: Incorrect ACK on serial port."
There's a warning in advance, I wonder if it is related:
WARNING: Stopping clone thread
WARNING: ID suspect. Expected000: 49 46 54 2d 33 35 52 00 IFT-35R.
008: 00 56 31 30 30 00 00 .V100...
, Received:000: 49 46 54 2d 33 35 52 00 IFT-35R.
008: 00 56 31 30 30 00 01 .V100...
Apparently the IDs don't match (the last byte expected was 00 and the radio sends 01): does this "stop the clone thread" as the warning says?
I'll try to build from source and see if I can circumvent this.
Updated by Mikel EA5IYL Forcada over 1 year ago
Mikel EA5IYL Forcada wrote in #note-3:
Beni K wrote in #note-2:
After fixing Bug #10275 this problem also affects CHIRP-next on Linux.
Yes, it persists on GNU/Linux, Ubuntu 22.04 in my case. I've used CHIRP next-20230116 on Python 3.10.6 wxPython 4.0.7 gtk3 (phoenix) wxWidgets 3.0.5.
It starts cloning and then fails, issuing this error: "Failed to communicate with radio: Incorrect ACK on serial port."
There's a warning in advance, I wonder if it is related:
WARNING: Stopping clone thread
WARNING: ID suspect. Expected000: 49 46 54 2d 33 35 52 00 IFT-35R.
008: 00 56 31 30 30 00 00 .V100...
, Received:000: 49 46 54 2d 33 35 52 00 IFT-35R.
008: 00 56 31 30 30 00 01 .V100...Apparently the IDs don't match (the last byte expected was 00 and the radio sends 01): does this "stop the clone thread" as the warning says?
I'll try to build from source and see if I can circumvent this.
I've upgraded to 20230117 which was released minutes ago.
I've edited sendcmd in ft4.py so that it prints the command sent before ack is checked against '\x06'.
I have found that the point in which acknowledgement from the radio is not received or recognized varies from one download to another.
After sending 'PROGRAM', the commands sent have the form 'R\x00' + byte + '\x10', and the byte progresses like this: '\x00', '\x10', etc. I've seen it fail at '\x30', but also at '\x70' or at '\xf0'. I haven't looked into the format of commands, so I don't know what these are (reading commands?), but there is an intermittent condition that produces an empty 'ack', probably lower level.
Can't get any further without studying all the code, sorry.
Updated by Simon Taylor about 1 year ago
I can confirm the same issue on OSX, using CHIRP next-20230303 and a home-made cable (using FTDI) that works using Yaesu's PC software.
Updated by Gabriel Criado about 1 year ago
I confirm the problem, I have 2 yaesu FT-4X, tested with MacOS and Raspberry OS. Both radios gives the same error while reading and the display changes to "CLONE" but the software doesn't read. Using a Mirkit 6n1 FTDI cable. Other radios works fine (Baofeng, QYT)
Updated by Bartlomiej Zielinski about 1 year ago
- File ft4x_rd.txt ft4x_rd.txt added
- File ft4x_wr.txt ft4x_wr.txt added
- File ft4x_rd_chirp.txt ft4x_rd_chirp.txt added
I have the same issue with FT-4XE. Tested with both "legacy" and "next" versions of Chirp. I attach the session dumps.
Updated by Dan Smith about 1 year ago
- Has duplicate Bug #10466: Yaesu FT-4XR download error added
Updated by kml ob 6 months ago
I had the same issue with my FT-4XE, so I've looked into the code and fixed the issue by adding a retry mechanism in the part which sends the commands to the radio.
Works like a charm.
Tested the download and upload to my FT-4XE successfully. The pull request with my change is here: https://github.com/kk7ds/chirp/pull/816
Updated by kml ob 6 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|e424cdd171942f048898db307e40bc75b86c680f.