Bug #4687
closedicf.py: echoback causes overflow of OS's serial Rx buffer
0%
Description
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.
Files
Updated by Andrew Jorgensen about 7 years ago
This seems to have caused #5007, which could be a Windows-only bug. Thoughts on how to resolve?
Updated by Takayoshi SASANO about 7 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
character.
Updated by Neil Katin about 7 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 about 7 years ago
- File icf.py.diff icf.py.diff added
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 about 7 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
self.__radio.sync_in()
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 about 7 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 over 4 years ago
- Status changed from New to Closed
- Model affected changed from used icf.py to (all models)
This appears to be complete.