[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 18:57, Dan Smith via chirp_devel escribió:
>> No, it means that the radio answer with a variable length
> You don't really think that the radio is answering with a variable
> length, right? Or are you saying we don't always know whether we need to
> read 8 or 16 bytes because we haven't identified the model yet? The
> radio isn't really capable of sending a random length of data...

No, I have confirmation by the first ID that this radio is the model I 
know it's; but the OEM reads the second ID of the radio and we are 
copying this behavior... _and now I realize that maybe we don't need to 
do that_, as we know for sure that this is the radio it's.

Jim, we will test in that way this night.

This read of the second ID is way beyond in the high mem area, the area 
that is not touched by the OEM software, we are doing a simple and 
common read but this radios has the bad behavior (bug? feature? flag?) 
to send a misplaced \x05 byte on the first reads... and this misplaced 
\x05 is the one that is doing the block shorter or longer.

The OEM always use the 64 bytes length on the reads, but this particular 
high mem reads is always 16 bytes, the restriction you see later in the 
code about almost 16 bytes is because the string we need is in the lower 
16 bytes.

This can be another approach, send the request for the 16 bytes and read 
at least 16 (from the 21 it must be) then process it and at the end do a 
serial flush to get the buffer clean (or a dummy read of the 5 following 
bytes)

>> This way is more intrusive and will require more code changes, I
>> realized of this alternative way right now.
> I really think that it's most likely that you're reading the blocks at
> different sizes than you should, which causes you to get out of sync,
> and thus depend on the timeouts to avoid hanging too long in between
> them.

No, the OEM doit in this sizes as the logs shows, and we are doing it 
the same size. The OEM always use the 64 bytes length on the reads, but 
this particular high mem reads is always 16 bytes only.

> That would explain why the download and upload performance differs
> so much -- sometimes we get lucky and don't hit a lot of timeouts, but
> if we get out of sync early, we hit the timeout on each block,
> introducing a couple hundred milliseconds of unneeded delay on each round.

Yes, it can be.

>
> If the radio is really writing blocks in different sizes with varying
> delays through the image, then the fully buffered approach I described
> earlier is definitely the way to go...

No, the read size (64 bytes) is constant trough the read, the same we 
have on the write to the radio with 16 bytes on each bloc, but this 
particular high mem reads is always 16 bytes only.

Yes, I'm playing with an approach on buffering the whole data stream and 
them process it, of curse on another similar scenario, to get used to it 
and maybe implement it here.

Dan, I vote for applying the patch as Jim reported it works and it don't 
break anything; we can test further on this two paths and maybe we can 
manage this to work:

- Test if we can avoid this second ID read, as we now for sure with the 
normal ID that we have the correct radio.
- Test the request 16 bytes as usual, but reads at least 16 to process 
and then flush the serial, to get the buffer clean for the next steps.

So it's your call, apply it now or wait to test the two mentioned paths 
to see if one of them works better?

The WACCOM Mini-8900 is another story (bug) with it's annoying \x05 byte 
popping around and the OEM doing silent reties when it found the \x05 
byte in a specific position. It's like the OEM know it will not work and 
retry the entire process from top.

Cheers, Pavel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160406/e5bb70ca/attachment-0001.html