[chirp_devel] [PATCH] [New Model] Add Support for Retevis RT23 Radio

[Dan Smith]

> 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