[chirp_devel] BTECH IO comments about the patches.

[Jim Unroe]

Pavel,

I tested with all 5 of the radios in my possession. After increasing
the SERIAL_TIMEOUT to 0.68, here are the failures.

UV-2501+220 will not upload under Linux or Windows. Changing the
timeout value makes not difference that I can see.

Mini-8900 will not download under Linux. Changing the timeout value
makes no difference that I can see.

The successful radios are:

UV-2501 PP
UV-2501
UV-5001

DL/UL Times
Linux DL=32 seconds UL=32 seconds
Windows DL = 36 seconds UL=60 seconds

Jim

On Mon, Mar 28, 2016 at 6:09 PM, Jim Unroe <rock.unroe at gmail.com> wrote:
> Pavel,
>
> I bumped the SERIAL_TIMEOUT to .675 and so far, so good. I will test
> the other radios and let you know.
>
> Jim
>
> On Mon, Mar 28, 2016 at 12:43 PM, M.Sc. Pavel Milanes Costa via
> chirp_devel <chirp_devel at intrepid.danplanet.com> wrote:
>>
>> 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.
>>
>> _______________________________________________
>> chirp_devel mailing list
>> chirp_devel at intrepid.danplanet.com
>> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
>> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UV-2501+220_UL_FAIL_debug.log.zip
Type: application/zip
Size: 4056 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160328/d41ab155/attachment-0002.zip 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MINI-8900_DL_FAIL_debug.log.zip
Type: application/zip
Size: 3237 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160328/d41ab155/attachment-0003.zip