[chirp_devel] [PATCH][BTECH] Bigger serial timeout to allow all radios to work, fixes #3015
Dan Smith
Thu Mar 31 12:32:05 PDT 2016
> The problem is no the data amount (and then the time it takes to
> transfer) but the pauses that the radios made between the end of the
> request and the start of the data from the radio, sum to that the fact
> that this pauses are not normalized
Right, but that is a reason to use a *longer* timeout. (or go the full
buffer route).
> Every radio has a "random processing time" it takes for this,
The pedant in me requires me to point out that the radio is incapable of
being random :D
> logs has
> showed as high as 0.5 secs in some cases, but practices tells that it
> must be higher. Jim has tested almost all the radios in the driver (some
> with the help of the users) and he found that a value of 0.67 was good
> enough, but 0.7 will not harm.
So read with a 2.0s timeout, and exactly the number of bytes, right?
Then you're good and safe no? The timeout is only for if something went
completely wrong and the stream stopped (or stopped for long enough that
something really bad happened).
--Dan
More information about the chirp_devel
mailing list