[chirp_devel] [PATCH][BTECH] Bigger serial timeout to allow all radios to work, fixes #3015

[M.Sc. Pavel Milanes Costa]

El 31/03/16 a las 12:46, Dan Smith via chirp_devel escribió:
>> Practice have dictate that this value must be around 0.67 secs and to be
>> safe we rise it to 0.7 seconds, it must not impact to much on the speed
>> of the read/write with the driver.
> So I just wanted to point out that the only reason you should not be
> able to use a long timeout, is if you're reading data from the radio and
> aren't sure how much to read. Surely these blocks are all an equal size,
> right? Where is the case where you actually need to read some amount
> that you can't predict, and which isn't an error case?
>

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, it can happen a few times or none 
in the download, it may be related with a busy MCU doing some other task...

Every radio has a "random processing time" it takes for this, 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.

73