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