El 29/03/16 a las 18:50, Dan Smith via chirp_devel escribió:
This is the same problem I found earlier, the radio does not give the
bad ack on the dummy block, and this is inserted after the valid one in the first valid block read.
000: *06* *05* 58 00 00 40 00 25 ..X..@.%
What keep me puzzled is that this only happen on Linux...
I know I'm not working on this and that it's clearly a tough nut to crack. I just want to make sure we remain grounded and not start to think that random bytes are being added to the data stream on windows. If it's really bad hardware or a buggy driver, it would be an equal-opportunity bug and it would disturb all amounts of stuff from working, including the OEM software.
I'm all for blaming windows for most anything, but let's be sure we're honest with ourselves at the end of the day :D
Yes, I have found a bug (or a feature?): The OEM software is doing a silent retry.
I found in the logs of a (one try) successful download with the OEM software, that it checks the header of the "dummy" first block and if it don't have the (bad) ACK in the beginning, it make a retry from the top... and the user is unaware of this.
This is the behavior we are finding on the actual error ONLY on linux and ONLY with the WACCOM MINI-8900 plus, the dummy block lacks the bad ACK and it's injected later.
The puzzling is that Chirp on windows works OK the way it's now with the WACCOM MINI-8900 plus; so I'm thinking on a run condition in the firmware of this particular radio I bet some pauses in the correct places is the key.
I don't have the radio on hand to test this but I have some ideas I want Jim to test to try to figure what's happening.
73