[chirp_devel] BTECH IO comments about the patches.

[M.Sc. Pavel Milanes Costa]

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.. at .%
>> >
>> >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