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.
Before or after the block you have to read the longer block? Anything you can do to anticipate that the longer read is needed would be good.
Can you read the id block after the rest of the clone is done? You can always stitch the image together later if need be.
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.
Meaning the OEM software asks for 64 bytes in its communication with the radio, or that the radio returns 64 bytes?
I don't think that the portmon-reported length is necessarily the length that the software is reading, but rather the amount returned to the application.
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)
Any time you're doing a flush or throwing away data in the middle of a clone procedure, I'm highly concerned because it means we don't know what all we're reading ...
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.
So we could go with a timeout of 5 minutes then right? I'm being hyperbolic, but what I mean is, you only ever need a short timeout if you're reading more than is available...
--Dan