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