[chirp_devel] BTECH IO comments about the patches.

[M.Sc. Pavel Milanes Costa]

El 28/03/16 a las 06:39, Jim Unroe escribió:
> Pavel,
>
> I only had time to test 2 radios before work, UV-2502 PP and UV-5001.
>
> Windows seems to work fine: DL 33 seconds UL 58-61 seconds
>
> Linux has trouble starting. From a cold start this error is usually received:
>
> Invalid header for block 0x0000:
>
> The debug log is attached.
>
> Usually after the 2nd or 3rd attempt it will start and be fine after that.
>
> UV-5001 DL 33 seconds UL 67 seconds (Windows was faster for a change)
>
>
>   I will have more time after work to play with the timing.
>
> Jim

Humm, strange

 From the log I see that the clone mode is accepted, the first dummy* 
read is made but it doesn't get the incorrect \x05 at the beginning, in 
fact it hasn't ACK at all, and it must be there.

* All radios but the 2501+220, make a dummy read of the first mem block 
and the ACK for that only first block is wrong (\x05), then following 
reads give the correct (\x06) ACK always. (this first ACK can be a bug 
or a feature... a flag for something,  who knows!)

To fight with lags on this dummy block there is a _clean_buffer() 
between the dummy and the real reads that should capture any garbage in 
the middle.

Then we have the real block read inside the cycle, but in his case the 
bad ACK is doubled, with the correct ACK (\x06) and then the missing bad 
ACK (\x05) that spoils the header and that's the error you are seeing.

I have checked the serial logs with portmon, and the driver is doing 
what is supposed to do, why it get this way in Linux is a mystery.

Any help people?

The strange part is that in windows it doesn't happen.

Jim, please try to replicate this bug (with the cold start) in Windows, 
to see if we have a Linux only trouble. It can be a bug that get masked 
by the different OS serial handling.

73 Pavel.