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

[Dan Smith]

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

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

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

--Dan