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

[Nathan Crapo]

My mistake.  I didn't read the thread well enough.  High latency is the
problem I've experienced most with USB serial devices.  This is different.

You're right Dan.  One could try /increasing/ the latency to increase
buffering, but I think that will just send larger chunks.  It will likely
increase the overall throughput, if anything, not decrease it.  If the
radio just isn't keeping up with the throughput in general this won't help.

I do like your idea of creating a throttled serial driver so long as users
can still opt out of it.  Maybe they could even tune the throttling with a
parameter?  This might help some HW without strewing sleep() calls all over
the place.  I want the max speed I can use, though.  It takes too long to
read/write some radios as it is.  Don't throttle everyone.

Throttling baudrate completely might be a bad idea in some cases.  What if
a radio needs a relatively high amount of time to "digest" a
packet/block/line of information?  Maybe it reads an entire block, and then
commits it to EEPROM, for example.  Or maybe it decrypts the block
(slowly).  If the time needed to process a block is high compared to the
time between symbols, you wouldn't want to impose the block timeout on each
symbol, or the throughput would be much lower than needed; maybe painfully
so.

My experience is most embedded devices don't use XON/XOFF.  Even the
simplest microcontrollers can usually keep up with 9600 baud until they try
to do something like decryption or writing to EEPROM.  Maybe I'm wrong here
- I've never written firmware for a radio.

-Nathan


On Fri, Jun 16, 2017 at 2:30 PM, Dan Smith via chirp_devel <
chirp_devel at intrepid.danplanet.com> wrote:

> > The other thing to try is setting the latency of your USB serial adapter
> > in the driver advanced tab. I have car tuning gear that requires this.
> >
> > By default the latency setting is a bit high for a lot of USB serial
> > dongles. It increases efficiency at the cost of reduced speed. Akin to
> > the Nagle algorithm in networking maybe?
>
> You mean turn _up_ the latency to slow things down a bit? If so, then
> that's worth a try.
>
> IMHO, this really smells like a flow control problem. Either the radios
> are expecting XON/XOFF and we're not doing it, or some of the
> chips/drivers are not signaling to the line discipline that their UART
> buffer is full and thus they're getting overwritten. The latter is more
> likely given that 9600 baud is really slow and most of the radios should
> be able to ingest that stream without needing us to slow down.
>
> If this is really a pervasive problem with drivers or USB devices,
> perhaps we should just write a generic throttled serial class, and let
> people opt-in to using that with a given flow rate. It'd be interesting
> to know if writing 8/16 bytes at a time, and timing it for 10% higher
> than the time it should take to flush that at the current baudrate helps
> all of these problems universally.
>
> --Dan
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170616/41fd2c8c/attachment-0001.html