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

[Dan Smith]

> A buggy dongle that sends characters too fast?  Hmm.  Maybe the 
> serial dongle isn't preserving application timing because of 
> buffering?

No, a buggy dongle that doesn't signal to the driver that its buffer is
full, or a driver that doesn't respect a signal and/or manage the buffer
properly. A UART is a tiny 16-byte buffer and whatever is managing that
has to ensure not to overrun it. It's a super simple piece of hardware,
and if something isn't managing it properly then you just end up with
garbage going out the serial line.

By writing to it slowly from the application you're working around that
issue. If we know the radio can take the data at a full 9600 baud (which
we do) then there's really not any other explanation for the
application's speed of writing the data affecting the result, IMHO.

>  Now we're back to lowering the latency timer.  For
> example: the application sends a record, waits for processing, and 
> then sends another record.  If the dongle/driver buffers across two 
> records, and then blasts out the entire block it could nullify the 
> record processing timeout.  Lowering the latency timer might help 
> with this as it reduces buffering.

Have you looked at the code? That's not what is happening. We're waiting
for an ack after every block we write to the device. The inter-character
delays being introduced basically mean we never fill the tiny buffer in
the UART.

> My experience was FTDI chipsets were most reliable in many ways. They
> responded well to a change in the latency parameter I mentioned 
> earlier.  Prolific USB dongles come in second to FTDI in my 
> experience.

Yep, me as well, although Jim's testing just now seems to indicate that
they are the least reliable, which surprises me. I'm not really sure
what the "latency" setting is affecting, and I'm not aware of any such
equivalent on non-Windows platforms. I also think that the non-Windows
platforms seem to be unproblematic, IIRC.

--Dan