[chirp_devel] BTECH IO comments about the patches.
Hi Dan and Jim, This are all the patches related to the driver IO so far.
Dan this are safe to apply but not to release until Jim confirmed with all the radios he has that it works as expected, as this radios are tricky on the serial line.
Jim as you may noticed I have changed thing a lot with the Dan advice, please test the driver and let's use this emails in the devel list to coordinate the job and needed changes (I hope to be none or minimal).
Now there is a SERIAL_TIMEOUT var to tweak for speed and safeness of work for all radios. So far the most slow was the QYT KT-UV890 so try to reach Robin to test it once you have tuned this param for the BTECHS & WACCOM Mini. (you must have Robin's email in one of mines, if not ask me privately)
I set it to 0.6 seconds to start, my math from the former values and the excel spreadsheet shows that this value is big enough with some room to improvement (lower it, my math says that about 0.45 is the sweet spot).
I will try to connect from the park again at noon and evening to check the progress.
73 from the park with the WiFi ;-)
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
On Mon, Mar 28, 2016 at 2:25 AM, M.Sc. Pavel Milanes Costa via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi Dan and Jim, This are all the patches related to the driver IO so far.
Dan this are safe to apply but not to release until Jim confirmed with all the radios he has that it works as expected, as this radios are tricky on the serial line.
Jim as you may noticed I have changed thing a lot with the Dan advice, please test the driver and let's use this emails in the devel list to coordinate the job and needed changes (I hope to be none or minimal).
Now there is a SERIAL_TIMEOUT var to tweak for speed and safeness of work for all radios. So far the most slow was the QYT KT-UV890 so try to reach Robin to test it once you have tuned this param for the BTECHS & WACCOM Mini. (you must have Robin's email in one of mines, if not ask me privately)
I set it to 0.6 seconds to start, my math from the former values and the excel spreadsheet shows that this value is big enough with some room to improvement (lower it, my math says that about 0.45 is the sweet spot).
I will try to connect from the park again at noon and evening to check the progress.
73 from the park with the WiFi ;-)
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
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.
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
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
Hi Jim and all, see below
El 28/03/16 a las 20:48, Jim Unroe escribió:
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.
I think I found the bug, reviewing the serial logs I found that the 2501+220 does a extra step before the upload of the first block and just after the second ID, I will work on that direction.
Funny, it's just on the upload process.
Mini-8900 will not download under Linux. Changing the timeout value makes no difference that I can see.
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...
Jim, can you make two portmon serial log of a download in windows, first with the OEM and then with Chirp ?
Also activate the "debug = True" and send to me the debug.log that correspond to that Chirp download.
All this for the WACCOM Mini of course.
73 Pavel.
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
--Dan
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
El 28/03/16 a las 20:48, Jim Unroe escribió:
UV-2501+220 will not upload under Linux or Windows. Changing the timeout value makes not difference that I can see.
Hi Jim,
I posted a fix patch for this particular issue that also affects the QYT KT8900 (not R), I will send the full code to you in a private email to test.
73
Dan this are safe to apply but not to release until Jim confirmed with all the radios he has that it works as expected, as this radios are tricky on the serial line.
Release is just "apply + time". If I apply them to the repository, the build system generates a build that night automatically. So I'll wait to apply them until you both say I should.
--Dan
El 29/03/16 a las 18:45, Dan Smith via chirp_devel escribió:
Dan this are safe to apply but not to release until Jim confirmed with
all the radios he has that it works as expected, as this radios are tricky on the serial line.
Release is just "apply + time". If I apply them to the repository, the build system generates a build that night automatically. So I'll wait to apply them until you both say I should.
Yes, all the patches are safe to apply.
I have some last tweaks and fixes that I will send today night: - Raise the serial timeout to allow all radio to work safely. - Fix for the WACCOM MINI 8900 download on Linux
participants (3)
-
Dan Smith -
Jim Unroe -
M.Sc. Pavel Milanes Costa