[chirp_devel] [PATCH][BTECH] Bug fix about radios resetting on the download, fixes #3015

[M.Sc. Pavel Milanes Costa]

El 05/04/16 a las 10:25, Dan Smith via chirp_devel escribió:
>>       if radio._id2 is not False:
>> +        # lower the timeout here as this radios are reseting due to timeout
>> +        radio.pipe.setTimeout(0.05)
>> +
>>           # query & receive the extra ID
>>           _send(radio, _make_frame("S", 0x3DF0, 16))
>>           id2 = _rawrecv(radio, 21)
> This just means that you're reading too much here, right? Do the radios
> have different sized responses? Can you not read the appropriate amount
> here to avoid the timeout entirely?
>
>

Hi Dan,

No, it means that the radio answer with a variable length, the default 
serial timeout is 0.7 secs to allow all radio to fit in, but some radios 
has a second id (this part of the code) that must be read before any 
operation, this second Id is a simple read of 16 bytes (21 with 
ACK+headers) in the upper memmap.

But most of the time the radio answer with less than the 21 bytes (some 
times_it does answe__r _with 21 bytes)  then the driver wait for the 
extra byte until the default serial timeout, meanwhile the radio see no 
activity and resets itself getting out of the clone mode.

That's why I have lowered the timeout here to a safe value of 0.05 secs 
that practice has showed is stable at least with our test scenario.

This lower timeout is good also in the next portions of the code on the 
upload procedure that this radios has to read some 1 or 2 bytes from the 
radio always being the last one an ACK.

At the end of the ident I reset the serial timeout to the default 0.7 
secs to be safe.

Another approach would be reading less than the 21 bytes and doing a 
serial flush after just to be sure. We only need to check for an 
specific string on this data block depending or radio model, but will 
work only if the string is always far of the end of the block (I have to 
check that yet).

This way is more intrusive and will require more code changes, I 
realized of this alternative way right now.

--- Pavel.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160405/b458a40e/attachment-0001.html