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.