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.