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 timeoutradio.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.