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