<div dir="ltr"><div><div>&gt; No, a buggy dongle that doesn&#39;t signal to the driver that its buffer is full,</div><div>&gt; or a driver that doesn&#39;t respect a signal and/or manage the buffer properly. A</div><div>&gt; UART is a tiny 16-byte buffer and whatever is managing that has to ensure not</div><div>&gt; to overrun it. It&#39;s a super simple piece of hardware, and if something isn&#39;t</div><div>&gt; managing it properly then you just end up with garbage going out the serial</div><div>&gt; line.</div><div><br></div><div>I don&#39;t see concrete evidence of a buffer overflow or dropped char in this</div><div>thread.  Not ruling it out, but I wouldn&#39;t assume that until you see proof.</div><div><br></div><div>FWIW, I&#39;ve never seen a USB dongle drop chars.  I have seen buffering issues a</div><div>lot.  USB devices have much more overhead for device driver &lt;-&gt; HW</div><div>communication.  Buffering more increase CPU and bus efficiency to counter the</div><div>overhead.</div><div><br></div><div><br></div><div>&gt; Have you looked at the code? That&#39;s not what is happening. We&#39;re waiting for</div><div>&gt; an ack after every block we write to the device. The inter-character delays</div><div>&gt; being introduced basically mean we never fill the tiny buffer in the UART.</div><div><br></div><div>Just tossing out potentially helpful ideas.  Are you sure the failure is when</div><div>CHIRP is waiting for the &quot;ack&quot; from the radio?  I didn&#39;t see anyone report that</div><div>specifically.  Does the radio actually send the ack?</div><div><br></div><div>Here&#39;s a situation I experienced: I used a USB serial dongle to communicate</div><div>between a laptop and a car ECU.  A Windows application would send a request</div><div>character to the ECU, then wait for a response.  It did this as fast as possible</div><div>over and over to constantly receive telemetry data.</div><div><br></div><div>A lot of USB serial dongles would break communication because they wouldn&#39;t send</div><div>the ECU response quick enough and the application would give up.  The</div><div>application thought the connection was broke, when in fact the ECU did respond,</div><div>the dongle received the char and buffered it.  But then the dongle didn&#39;t send</div><div>the response to the host in time.  It was simply waiting for more characters</div><div>because it wanted a fuller buffer before sending something to the host.</div><div><br></div><div>There are two ways to fix this problem: wait longer in the application for the</div><div>response, or allow the USB dongle to send its RX data sooner (latency timer).</div><div><br></div><div>HW UARTs do not suffer this problem as they don&#39;t have the same greedy</div><div>buffering.  Like you said, they&#39;re simpler.  The driver &lt;-&gt; HW communication is</div><div>much more efficient, so higher buffering is not needed.</div><div><br></div><div><br></div><div>&gt; I&#39;m not really sure what the &quot;latency&quot; setting is affecting, and I&#39;m not aware</div><div>&gt; of any such equivalent on non-Windows platforms.</div><div><br></div><div>The latency setting controls how long the driver waits for a full buffer before</div><div>sending it to the dongle.  The latency timer starts when the first character</div><div>arrives at the driver from an app.  The buffer is sent if the timer expires, no</div><div>matter how full it is.  If the buffer fills before the timer expires, it is sent</div><div>immediately.  This scheme is used for dongle -&gt; host buffering as well.</div><div><br></div><div>Looks like you can set the latency_timer via sysfs in Linux for an FTDI chipset.</div><div>I doubt this is very consistent for different dongles.  See:</div><div><br></div><div><a href="https://askubuntu.com/questions/696593/reduce-request-latency-on-an-ftdi-ubs-to-rs-232-adapter">https://askubuntu.com/questions/696593/reduce-request-latency-on-an-ftdi-ubs-to-rs-232-adapter</a></div><div><br></div><div><br></div><div>&gt; I also think that the non-Windows platforms seem to be unproblematic, IIRC.</div><div><br></div><div>Pavel Milanes said this issue happens in both Linux and Windows in his post at</div><div>2:00PM MDT.</div><div><br></div><div>Maybe the best solution is to increase the serial port timeout value in CHIRP.</div><div>I can&#39;t think of a down-side other than sluggishness when trying to open invalid</div><div>ports.</div></div><div><br></div><div>-Nathan</div><div><br></div></div>