Project

General

Profile

Actions

Bug #10198

closed

Reading from Yaesu FT-4XE hang with error

Added by Saku Elovaara almost 2 years ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
12/27/2022
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
Yaesu FT-4XE
Platform:
Windows
Debug Log:
I read the instructions above:

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:

  1. start app
  2. Radio > Download from Radio
  3. set proper cfg COM3 (same as hw manager view), Yaesu and model FT-4XE (try also XR, same result)
  4. check ok and select "next/ok" for following notes
  5. chirp start communicate to radio, as it shows "TX" and signal bar start going forward
  6. 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 Saku Elovaara, 12/27/2022 07:57 PM
chirp_error.PNG (16.5 KB) chirp_error.PNG Error message Saku Elovaara, 12/27/2022 07:57 PM
chirp_error3.PNG (32.7 KB) chirp_error3.PNG usb-ser driver Saku Elovaara, 12/27/2022 07:57 PM
chirp_log.txt (37.1 KB) chirp_log.txt log Saku Elovaara, 12/27/2022 07:57 PM
chirp_radio.JPG (122 KB) chirp_radio.JPG Radio after sw start communication Saku Elovaara, 12/27/2022 08:00 PM
ft4x_rd.txt (163 KB) ft4x_rd.txt Successful read with Yaesu software Bartlomiej Zielinski, 03/21/2023 01:17 AM
ft4x_wr.txt (197 KB) ft4x_wr.txt Successful write with Yaesu software Bartlomiej Zielinski, 03/21/2023 01:18 AM
ft4x_rd_chirp.txt (81.5 KB) ft4x_rd_chirp.txt Failed attempt to read with Chirp Bartlomiej Zielinski, 03/21/2023 01:18 AM

Related issues 2 (0 open2 closed)

Has duplicate Bug #10247: FT-4XE won't syncRejected01/09/2023

Actions
Has duplicate Bug #10466: Yaesu FT-4XR download errorRejected03/22/2023

Actions
Actions #1

Updated by Dan Smith almost 2 years ago

  • Has duplicate Bug #10247: FT-4XE won't sync added
Actions #2

Updated by Beni K almost 2 years ago

After fixing Bug #10275 this problem also affects CHIRP-next on Linux.

Actions #3

Updated by Mikel EA5IYL Forcada almost 2 years 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.

Actions #4

Updated by Mikel EA5IYL Forcada almost 2 years 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.

Actions #5

Updated by Simon Taylor over 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.

Actions #6

Updated by Gabriel Criado over 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 over 1 year ago

I have the same issue with FT-4XE. Tested with both "legacy" and "next" versions of Chirp. I attach the session dumps.

Actions #8

Updated by Dan Smith over 1 year ago

  • Has duplicate Bug #10466: Yaesu FT-4XR download error added
Actions #9

Updated by kml ob 12 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

Actions #10

Updated by kml ob 12 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF