CHIRP

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

"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

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 (ymg@dakotacom.net)

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 --> (002)

Device --> � (254)

Device --> (001)

Device --> (001)

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

Host --> (006)

Device --> (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.