Bug #4687

icf.py: echoback causes overflow of OS's serial Rx buffer

Added by Takayoshi SASANO over 5 years ago. Updated about 2 years ago.

Status:Closed Start date:03/28/2017
Priority:Normal Due date:
Assignee:- % Done:


Target version:-
Chirp Version:daily Platform:All
Model affected:(all models)


ICOM's cloning cable connects PC's TXD and RXD of UART. So PC always
receives echoback when sending any data to rig.

In icf.py code, data is sent by pipe.write() but its echo back
is not received immediately. Received all echobacks and response from
rig are processed after all clone data has sent.

This means OS (or its device driver) needs enough receive buffer to store
all echobacks and response. The size of the buffer is OS dependent,
we should not expect it is always enough.

So we have to call pipe.read() after pipe.write() to discard echoback
immediately. I am testing CHIRP on OpenBSD-6.0/amd64 and ICOM's IC-P7,
this fix is required to send clone data from PC to rig.

icf.py.diff (1.4 kB) Takayoshi SASANO, 09/05/2017 08:53 am

Associated revisions

Revision 2888:c4cf293122fe
Added by Takayoshi SASANO about 5 years ago

previous patch for bug #4687 causes PEP8 regression problem,
"E261 at least two spaces before inline comment".

Replace a tab character to two spaces to fix the problem.

Revision 2929:c31ea5cfe7d7
Added by Takayoshi SASANO almost 5 years ago

revert #4687
Different from OpenBSD-6.0, OpenBSD-6.1 is no longer required this modification.
And, this cause #5007 bug. Revert to 2715:d1bc2c917785.


Updated by Andrew Jorgensen almost 5 years ago

This seems to have caused #5007, which could be a Windows-only bug. Thoughts on how to resolve?

Updated by Takayoshi SASANO almost 5 years ago

Andrew Jorgensen wrote:

This seems to have caused #5007, which could be a Windows-only bug. Thoughts on how to resolve?

I sometimes have seen "Out of sync with radio" with my IC-P7/PL2303 family USB-clone cable/OpenBSD
combination but there is no problem with same rig/cable and Windows10. So I thought this problem
is only mine, not so serious.

I found "Out of sync" error has occurred by receiving single preamble character (0xfe) from rig,
normally we receive two 0xfe(s). If #5007 has same reason, we have to know who discards the

Updated by Neil Katin almost 5 years ago

I played with this a bit more, and can confirm the patch is causing #5007.

I replicated it on both window and linux, so it is not a windows only bug.

Either of the read commands (in send_clone_frame() or start_hispeed_clone() would cause the error. The pipe.flush() in send_clone_frame() could be left enabled and the ID-51 would still clone.

Let me know if there is any more detail I can provide that would help.

Updated by Takayoshi SASANO almost 5 years ago

I am testing new diff to solve this problem and at least works good on my environment
(OpenBSD-6.1/amd64, IC-P7 with PL2303 based USB cable, IC-7200 with built-in USB interface).

I attach the diff, please test.

Updated by Neil Katin almost 5 years ago

I tried the patch; I still got an out of sync error.

Here's the relevant info from the log (let me know if you want the whole thing instead of just an excerp):

DEBUG: User selected Icom ID-51 Plus on port /dev/ttyUSB0
DEBUG: Clone thread started
WARNING: Received echoback is different from sent frame
DEBUG: Sent frame (10):
000: fe fe ee ef e0 00 00 00 ........
008: 00 fd 00 00 00 00 00 00 ........

DEBUG: Echoback (3):
000: fe fe ef 00 00 00 00 00 ........

ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
File "/home/neil/src/chirp/chirp.hg/chirp/ui/clone.py", line 249, in run
File "/home/neil/src/chirp/chirp.hg/chirp/drivers/icf.py", line 646, in sync_in
self._mmap = clone_from_radio(self)
File "/home/neil/src/chirp/chirp.hg/chirp/drivers/icf.py", line 352, in clone_from_radio
raise errors.RadioError("Failed to communicate with the radio: %s" % e)
RadioError: Failed to communicate with the radio: Out of sync with radio

Updated by Takayoshi SASANO almost 5 years ago

I tried previous revision (2715:d1bc2c917785) on OpenBSD-6.1/amd64.
Testing with this OpenBSD release is no problem.
So it's time to trash 2869:a6ecd7940d6b and 2888:c4cf293122fe.

But, does anyone who can describe what is happening?
Theoretically there should be no problem to read echoback immediately
after sending data and read frame should be same as sent frame.

Updated by Bernhard Hailer about 2 years ago

  • Status changed from New to Closed
  • Model affected changed from used icf.py to (all models)

This appears to be complete.

Also available in: Atom PDF