Just tossing out potentially helpful ideas. Are you sure the failure is when CHIRP is waiting for the "ack" from the radio? I didn't see anyone report that specifically.
No, it's not that's the point. The sending speed either causes something to be dropped or corrupted such that the radio doesn't send the ACK. Increasing the time to wait for the ack doesn't solve anything because the radio doesn't ack it.
The latency setting controls how long the driver waits for a full buffer before sending it to the dongle. The latency timer starts when the first character arrives at the driver from an app. The buffer is sent if the timer expires, no matter how full it is. If the buffer fills before the timer expires, it is sent immediately. This scheme is used for dongle -> host buffering as well.
Okay, based on what I've seen I don't see how this would affect anything, but it's certainly worth poking at it to see if anything useful comes out.
Maybe the best solution is to increase the serial port timeout value in CHIRP. I can't think of a down-side other than sluggishness when trying to open invalid ports.
It affects the time to recover when the radio never sends the ACK. However I believe that we've sufficiently proven that this is _not_ a problem with aggressive timeout while waiting for the ack.
You might be missing some context on this issue, which stretches back to the btech driver development many months ago. That should be in the archives if you're interested. I wrote most of the drivers in the tree and had never encountered a problem like this until Pavel brought it up with the btech driver, and now Jim with this.
--Dan