<div dir="ltr">Jim, I'd try playing with the latency timer. I think we've shot my previous two theories out of the water. However, buffering between the PC and dongle can alter timing and sometimes accounts for behavioral difference between dongles.<div><br></div><div>Separately, I like Dan's idea to try sending larger amounts of data at once. It may provide more data if nothing else. Like Dan said, there's very little guarantee small sleep values are accurate or efficient. There are even fewer guarantees that the timing you use to submit each byte in the application is preserved by the USB dongle. Data takes a much more complex path than if you were to use a HW UART. It should be a lot closer in that case.</div><div><br></div><div>-Nathan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 7:00 PM, Jim Unroe <span dir="ltr"><<a href="mailto:rock.unroe@gmail.com" target="_blank">rock.unroe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> Have you looked at the code? That's not what is happening. We're waiting<br>
>> for<br>
>> an ack after every block we write to the device. The inter-character<br>
>> delays<br>
>> being introduced basically mean we never fill the tiny buffer in the UART.<br>
><br>
> Just tossing out potentially helpful ideas. Are you sure the failure is<br>
> when<br>
> CHIRP is waiting for the "ack" from the radio? I didn't see anyone report<br>
> that<br>
> specifically. Does the radio actually send the ack?<br>
<br>
</span>There is never an ack when it fails.<br>
<span class=""><br>
> Maybe the best solution is to increase the serial port timeout value in<br>
> CHIRP.<br>
<br>
</span>I tried this earlier today and it made no difference.<br>
<br>
Jim KC9HI<br>
</blockquote></div><br></div>