Bug #4409

FT-1802: ERROR: Clone failed: Failed to communicate with the radio: Attempting to use a port that is not open

Added by Mark Whitis almost 6 years ago. Updated about 2 years ago.

Status:Feedback Start date:01/13/2017
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Platform:Linux
Model affected:Yaesu FT-1800

Description

Radio in clone mode
Radio - Download from radio
Port /dev/ttyUSB0
Vender Yeasu
Model: FT-1802M
Dialog: Ok to dismiss
Help: Ok to dismiss
Press MHz button, radio says "----TX----"
chirp acknowledges that clone mode has started
progress bar shows no activity
radio times out and says error

stdout and debug.log show error message
: ERROR: Clone failed: Failed to communicate with the radio: Attempting to use a port that is not open:

This suggests an internal programming error as program was able to read from port to see I had pressed the button but then seems to have a stale file handle.

409shop.com 6-070 USB programming cable with interchangable adapters. (Prolific clone)
409shop.com 6-081 adapter http://ww.409shop.com/409shop_product.php?id=104251
The usb cable has been used with many different radios with chirp
The adapter was ordered to program a friends FT-1802 and this is the first time used.

used apt to install latest chirp-daily before generating debug.log
CHIRP daily-20170111 on Linux - Ubuntu 14.04.4 LTS (Python 2.7.6)

gpsd was killed before running chirp as gpsd.hotplug likes to open this cable when installed.

Same cable with different adapter plug was used to successfully download from a UV-5R+ while filing this bug report.

debug.log (14.4 kB) Mark Whitis, 01/13/2017 03:01 pm


Related issues

related to Bug #3025: FT-1802 Fails to upload Feedback 11/25/2015

History

Updated by Mark Whitis almost 6 years ago

strikeout mode formatting in bug report text is due to a bug in the bug tracker software and was not intended to convey deletion.

Updated by Tom Hayward almost 6 years ago

"Attempting to use a port that is not open" indicates the OS would not let Chirp use the serial port. It may be a permission issue (like not in the dialout group), a driver issue, or most likely another app already claimed the serial port. If this does not always happen with this adapter, I suggest trying again.

There are instructions on how to use the wiki formatting here: http://chirp.danplanet.com/help/wiki_syntax_detailed.html

Updated by Mark Whitis almost 6 years ago

It appears that a chirp bug, attempting to talk to serial port after it has been closed when cancelling, is hiding the real issue here which may be electrical.

The diagnosis suggested by tom hayward is inconsistent with the evidence which shows that chirp is indeed able to communicate with the serial port. Only a portion of the chirp Yaesu FT-1802 driver code is not.

Evidence that chirp can communicate:
- The display on the screen changes from "cloning" to "cloning from radio" when you initiate the transfer from the radio. It would not do this if the driver could not communicate with the port at all.
- On the same PC with the same cable (different pinout adapter) and the same version of chirp, I can program a different brand of radio after failing to program this model.
This evidence is included in the original bug report.
/dev/ttyUSB0 is being opened by the program without error (returns file handle 13).

Rather, it looks more like the driver has bungled the handling of a file handle pointing to the serial port such that portions of the code are unable to talk to the same port.

strace isn't particularly helpful as chirpw forks a child process just after opening the serial port
slsnif has an internal buffer overflow and crashes with timestamp option but without it, prints the following. All of this takes place immediately after the Set/MHz button is pressed.

slsnif /dev/ttyUSB0 --speed 19200 -u

Serial Line Sniffer. Version 0.4.4
Copyright (C) 2001 Yan Gurtovoy ()

Opened pty: /dev/pts/14
Saved name of the pty opened into file '/tmp/slsnif_pty'.
Opened port: /dev/ttyUSB0
Baudrate is set to 19200 baud.

Device --> A (065)

Device --> H (072)

Device --> 0 (048)

Device --> 2 (050)

Device --> 3 (051)

Device --> <STX> (002)

Device --> � (254)

Device --> <SOH> (001)

Device --> <SOH> (001)

Device --> <SOH> (001)
Synchronizing ports...Done!

Host --> <ACK> (006)

Device --> <ACK> (006) ^C

Note that "port is not open" may happen after hitting cancel button after radio says "ERROR". If you wait for the software to eventually tme out, you may get no response from radio instead.

At this point, it looks like the "port not open" is a chirp bug that is confusing the issue. After you hit cancel, the program apparently closes the port before it is done with it.
There may be a problem with the cable pinout adapter which is being masked by the distraction of chirp's internal bug. The PC is able to hear the radio but I don't think the radio can hear the PC.

Note that yaesu_rw gets stuck in the same place chirpw does. It appears it can also hear the radio but not be heard by the radio. That software, however, does not recognize an FT-1802.

Updated by Bernhard Hailer about 2 years ago

  • Description updated (diff)
  • Status changed from New to Closed
  • Model affected changed from FT-1800 to Yaesu FT-1800
  • Platform changed from Windows to Linux

No more traffic on this ticket. - This is an issue with the driver / cable / connector you are using. There are similar reports here on the wiki; please research them, they may contain a solution for you. (We can reopen if there are reasons to believe that we're dealing with a Chirp issue.)

Updated by Bernhard Hailer about 2 years ago

  • Status changed from Closed to Feedback

I think I was a bit too quick closing this issue, after having read this again. We will keep this open until a developer can have a look.
Possibly related to #3025.

Also available in: Atom PDF