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@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@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers