El 06/04/16 a las 10:27, Jim Unroe escribió:
Pavel: 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.
Sure.
[.....]
I don't think we have to exactly follow the OEM software in this regard either. It just adds a complication that seems to me as not being necessary.
Jim
After a few test this path is a no go.
When you ignore the read of the high mem zone that contains the second ID, the radio answer to the first block read with a block without the starting ACK (neither good or bad, just not ACK at all!) and add a 0xf0 at the end of the block, then stop responding.
So maybe the radio expects the read of this high mem block to move on and we have to follow the OEM software on this.
Checking the timing on the serial logs (portmon in crono mode) for the affected radios, the patch for a smaller serial timeout makes sense, we are doing things now (with the lower serial timeout) just like the OEM does, and it works.
The other mentioned way of a short read and then a serial flush is a more complicated version of the one in the actual patch, so I think you will reject it also.
Dan, sorry for my insistence with this patch.
I'm a amateur in python programming with less than a year of experience (I have a kind of experience on other languages), this is my first big python project and I will like to test the way you mention about a buffer, but I have not a reference for doing it.
I was testing a kind of buffer on other context and after a few tests and deep thinking it's a no go here for a few reasons, can you please take a time and guide me or elaborate more on the buffer version concept for me to understand it?
Cheers Pavel.