[chirp_devel] [PATCH][BTECH] Bigger serial timeout to allow all radios to work, fixes #3015
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.
But it will give better stability with all the radios we support now.
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?
--Dan
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
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
participants (2)
-
Dan Smith -
M.Sc. Pavel Milanes Costa