Yes, it does make sense. Serial connections use
*two* independent data lines (plus ground): RX and TX.
If you trigger your radio to give you all its data (download
contents), then the radio will use its TX line to feed the RX of
the USB cable. Chirp reads it from there. The radio's RX line is
not in use for this task.
But when you try to upload data, then the TX line of your cable
tries to feed into the RX line of your radio. It attempts to send a
command causing the radio to accept data. There's a disconnect.
Nothing arriving at the radio, which otherwise would send an
acknowledgement back.
Check your cable and connector.
Regards
Bernhard AE6YN
On 01-Jan-21 18:51, D.J.J. Ring, Jr.
wrote:
Bernhard,
This is a problem only
for writing, not reading from radio.
Doesn't make sense to
me.
Best wishes,
David
N1EA
On Fri, Jan 1, 2021, 20:04
Bernhard Hailer AE6YN <ham73tux@gmail.com>
wrote:
Hi DR,
This looks like a cable / driver / connector
issue. Please refer to these Wiki articles:
CableGuide
CableGuide FTDI OEM Cables
*Linux notes:* Linux generally is quite good with USB to
Serial converter drivers. The most likely cause for
grief is a connector which doesn't provide good
electrical contact. In your case, it looks like serial
TX is not making contact. Check your cable and
connector.
73 es GL
Bernhard AE6YN
On 01-Jan-21 13:17, D.J.J. Ring, Jr. wrote:
I
can download from my Yaesu FT-897D
successfully using CHIRP daily-20201221 on Linux -
Debian GNU/Linux 10 (Python 2.7.16) but I cannot
upload.
I
get the following error message.
raise errors.RadioError("Failed to communicate
with radio: %s" % e)
RadioError: Failed to communicate with radio:
Radio did not ack block 0
ERROR: ----------------
ERROR: Clone failed: Failed to communicate with
radio: Radio did not ack block 0
ERROR: --- Exception Dialog: Failed to communicate
with radio: Radio did not ack block 0 ---
ERROR: None