El 08/04/16 a las 17:31, Dan Smith via chirp_devel escribió:
So we could go with a timeout of 5 minutes then right? I'm being hyperbolic, but what I mean is, you only ever need a short timeout if you're reading more than is available...
The general (default) timeout is set to 0.7 secs, because we have a bunch of radios to deal with, and this radios put some particular pauses (each models has it's own pauses as high as 0.5 secs in some cases) between the request and the answer of a block.
Aka: we have really a ~0.2 sec timeout for the radios that has the long pause, and the others just continue when it has the right amount of data (69 bytes), this works ok with all radios with no timeouts or other failures.
The problem is in the radios with the read in the high mem zone (second id) it just read 16 bytes instead of the normal 64 bytes, so the timeout must be short here because in this particular moment some times the radios put a misplaced \x05 (we call it 'wrong ACK', it can be a bug or a feature, who knows) that make the requested block of 16 bytes short by one.
normally ACK + 4 bytes of headers + 16 bytes payload (21 bytes) with the wrong ack it's like this: WRONG-ACK + 4 bytes of headers + 15 bytes payload (20 bytes)
When the wrong ack appears in the stream the block is just 20 bytes instead of the normal 21; so the driver get waiting to the normal 0.7 sec of timeouts and the radio resets getting itself out of the clone mode.
This is the root of the problem, my way of solving that is to lower the timeout to allow to capture at least the 20 incomplete bytes and timeout ASAP to keep in sync with the radio, because we only care about 12 bytes in there and don't care about if the full 16 or 15 byte were received, I'm happy with the first 12 in the payload because in there is out check string.
In fact the rest of the 4 or 3 bytes are different in each radio model, some times full \x00, some times \xFF and even \x20
Doing it like this allows me to keep going fast into the normal read and it works.
Cheers.