Bug #3993
closedError when downloading from QYT KT-8900R
Added by Michael Wagner over 7 years ago. Updated almost 7 years ago.
90%
Description
Whenever I try to download from my KT-8900R using chirp, I get the error "Invalid header for block 0x0000" and the radio reboots.
Occurs with CHIRP daily on latest ubuntu.
I attached:
- debug.log
- the .dat - File taken from the QYT's original software using windows XP
- a html-file showing a log on the serial port during a successful download-procedure with the QYT-Software (on Windows XP in a VM)
Please let me know if further information is necessary to solve the issue.
Files
| debug.log (20.8 KB) debug.log | Chirp's debug-logfile | Michael Wagner, 09/05/2016 01:50 PM | |
| KT-8900r_original.dat (91.6 KB) KT-8900r_original.dat | factory .dat-file (taken with QYT software) | Michael Wagner, 09/05/2016 01:50 PM | |
| serial_port_monitor_from_original_software.htm (83.1 KB) serial_port_monitor_from_original_software.htm | log of serial port of a succcessful download | Michael Wagner, 09/05/2016 01:50 PM | |
| debug_true.log (20.2 KB) debug_true.log | Michael Wagner, 09/06/2016 10:39 AM | ||
| kt8900r_portmon.zip (1.14 MB) kt8900r_portmon.zip | Michael Wagner, 09/07/2016 10:57 AM | ||
| debug.log (19.3 KB) debug.log | Kristian Thomassen, 09/08/2016 12:18 AM | ||
| Error mssg.jpg (7.81 KB) Error mssg.jpg | Kristian Thomassen, 09/08/2016 12:18 AM | ||
| manual_with_moserial.png (47.1 KB) manual_with_moserial.png | Michael Wagner, 09/08/2016 09:48 AM | ||
| portmon_chirp_windows.LOG (189 KB) portmon_chirp_windows.LOG | Michael Wagner, 09/08/2016 09:48 AM | ||
| btech.py (55.4 KB) btech.py | Dev version with a potential fix for the troubles of reading in Linux. | Pavel Milanes, 09/12/2016 08:59 AM | |
| btech(1).py (55.5 KB) btech(1).py | Michael Wagner, 09/12/2016 10:32 AM | ||
| debug.log (242 KB) debug.log | logs of sucessful recovery after x05-failure with btech2.py | Michael Wagner, 09/12/2016 03:11 PM | |
| btech_2.py (56.6 KB) btech_2.py | different approach: try without delay, and retry with delay if download fails | Michael Wagner, 09/12/2016 03:11 PM |
Related issues
Updated by Michael Wagner over 7 years ago
- File debug_true.log debug_true.log added
Added debug.log with "debug = True" set in /usr/lib/python2.7/dist-packages/chirp/drivers/btech.py .
Updated by Michael Wagner over 7 years ago
- File kt8900r_portmon.zip kt8900r_portmon.zip added
added traces according to "how to portmon.doc"
Updated by Kristian Thomassen over 7 years ago
- File debug.log debug.log added
- File Error mssg.jpg Error mssg.jpg added
I have a similar problem on Windows 7. I have a QYT KT-8900R. I can program this with the original QYT software at http://www.qyt-cn.com/en/download.html
I use a USB programming cable and have no issues reading and writing with the original software, it goes like a dream.
(However, this software is not as good as CHIRP regarding editing and this is the reason for me to prefer CHIRP).
Trying to read I get the following message: "An error has occurred. Radio identification failed". The radio is a QYT and not any of the many rebranded ones.
Thx for making this software!
Updated by Michael Wagner over 7 years ago
I just compared the traces between OEM-SW (logs via portmon) and the debug-log of chirp:
OEM-SW sends:
605 0.00183710 UV3BAND_E_CPS.e IRP_MJ_WRITE Serial4 SUCCESS Length 1: 06
613 0.00227850 UV3BAND_E_CPS.e IRP_MJ_WRITE Serial4 SUCCESS Length 1: 53
617 0.00195919 UV3BAND_E_CPS.e IRP_MJ_WRITE Serial4 SUCCESS Length 1: 00
623 0.00099817 UV3BAND_E_CPS.e IRP_MJ_WRITE Serial4 SUCCESS Length 1: 00
629 0.00198657 UV3BAND_E_CPS.e IRP_MJ_WRITE Serial4 SUCCESS Length 1: 40
Radio sends:
1050 0.00000838 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 06
1052 0.00001090 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 58
1054 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1056 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1058 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 40
1060 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 25
1062 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1064 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1066 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1068 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1070 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1072 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1074 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1076 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1078 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1080 0.00001117 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1082 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1084 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1086 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1088 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1090 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1092 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1094 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 50
1096 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 89
1098 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 43
1100 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1102 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 50
1104 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 89
1106 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 43
1108 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1110 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1112 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 56
1114 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 06
1116 0.00000754 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 50
1118 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 00
1120 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 01
1122 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: 48
1124 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1126 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1128 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1130 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1132 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1134 0.00000950 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1136 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1138 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1140 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1142 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1144 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1146 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1148 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1150 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1152 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1154 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1156 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1158 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1160 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1162 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1164 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1166 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1168 0.00000810 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1170 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1172 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1174 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1176 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1178 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1180 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1182 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1184 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
1186 0.00000782 UV3BAND_E_CPS.e IRP_MJ_READ Serial4 SUCCESS Length 1: FF
Chirp sends:
[2016-09-08 08:05:49,346] chirp.drivers.btech - DEBUG: ==> (5) bytes:
000: 06 53 00 00 40 00 00 00 .S..@...
Chirp receives:
[2016-09-08 08:05:49,450] chirp.drivers.btech - DEBUG: <== (69) bytes:
000: 06 05 58 00 00 40 25 ff ..X..@%.
008: ff ff ff ff ff ff ff ff ........
016: ff ff ff ff ff ff 00 50 .......P
024: 89 43 00 50 89 43 00 00 .C.P.C..
032: 56 06 50 00 01 48 ff ff V.P..H..
040: ff ff ff ff ff ff ff ff ........
048: ff ff ff ff ff ff ff ff ........
056: ff ff ff ff ff ff ff ff ........
064: ff ff ff ff ff 00 00 00 ........
=> in case of chirp, the second byte (0x05) byte is wrong (without that byte, chirp would be able to decode the message).
I am unable to tell whether:
- the debug.log is wrong
- the radio indeed sends different headers to chirp than it does with the oem-SW
- whether there is a low-level error in the linux-serial-driver or the python-library for serial communication, that inserts that addidional byte. But in that case, also different radios might behave strange?
Does anyone know a serial-port-monitoring tool for linux?
I will try to install chirp (daily) on windows, and create a portmon-log. This however might take a while...
Updated by Michael Wagner over 7 years ago
- File manual_with_moserial.png manual_with_moserial.png added
- File portmon_chirp_windows.LOG portmon_chirp_windows.LOG added
Tested with latest CHIRP on windows - this works - logs of portmon are attached!
Then I tried (in linux) to manually ask the radio to send the data (using the tool moserial) - also in that case the radio answered without the wrong "x05" after the command-code.
Updated by Pavel Milanes over 7 years ago
- Status changed from New to In Progress
- Assignee set to Pavel Milanes
- Estimated time set to 2.00 h
Hi to all, chirp's developer fo this radio here.
We have two separate problems in this issue.
Michael's one: the radio send a miss placed \x05 char when asked for data, this is a well known issue for this family of radios (BTECH 2501/5001 QYT 8900 & R Waccom Mini, etc.)
But we don't have a solution yet, we have noted that it's more prone to happen when you use a Linux OS; some investigation from this side with logs provided from the users (I don't have any of this radios to test) led to a hypothesis that this miss placed \x05 char is a kind of feature telling the software that it must start over, but I can't test that without a radio; and getting one of that radios is complicated from here (Cuba island) where importing any tranceiver is forbidden unless it's carried by a Cuban ham operator returning to the island...
Michael if you like to help me to debug this problem and have time to make some more test please click my user name to see my email and drop me one PM tho that email for further instructions.
The second problem, Kristian's problem is easy: He just found a new firmware unit; it's normal now that from time to time QYT (or other deakers) release a new variant of hist radios (looking the same outside and no info of upgrade is given) with a new firmware and a unknown ID to Chirp.
I have created and submitted a patch to the build queue and it will be supported in the next daily build, as easy as that.
73 Pavel CO7WT.
Updated by Pavel Milanes over 7 years ago
BTW FYI:
I have found that the bad \x05 byte sent by the radio make it non responsive to further commands from the PC. I have crafted a dev version of the driver that detect's the bad \x05 and restart the process for a few times recursively but in the tests with some other users it don't worked as expected: it keeps failing.
Even cleaning the buffer before asking for the data in this particular moment is of no help, the bad placed \x05 is generated by the MCU, it's not generated before hand.
One thing that puzzle me is that this bug/feature is almost exclusive of Linux OS, I have managed to catch a log in this site for portmon (windows) with a radio giving the \x05 and the CPS software restarted the comm process... that's why my hypothesis of it being a flag for kind of: "no go, busy here, restart it over".
73 Pavel CO7WT.
Updated by Michael Wagner over 7 years ago
Hi Pavel,
of course I'm willing and interested to support you with tests.
Maybe I can even give you access to my serial port using a tool like http://lpccomp.bc.ca/remserial/ - let me know what you think about that.
Maybe the whole thing is related to timing? In the one case, where I send the commands manually (which is a very indeterministic timing behaviour ;-) ) i did not receive the x05.
BTW: My radio keeps somehow responsive: at least it reacts on a consecutive 55 20 15 09 25 01 4D 02 and reboots ...
73 de Michael, OE4AMW
Updated by Michael Wagner over 7 years ago
until now, i was not sucessful in finding the "05" with the OEM-software.
However, I found a way to avoid it in linux, by adding delay of 0.01sec after each byte in "_send":
def _send(radio, data):
"""Send data to the radio device"""
try:
for byte in data:
radio.pipe.write(byte)
sleep(0.01)
this of course slows down the whole process, however, without that line, in > than 90% of the cases the download fails, with that line, it worked every time (until now).
So, my assumption is: chirp on linux is too fast for the serial port of the radio ...
Updated by Kristian Thomassen over 7 years ago
The new, uploaded Windows version now worksl like a charm on my KT-8900R. Thank you so very much!
Updated by Pavel Milanes over 7 years ago
- % Done changed from 0 to 50
Michael Wagner wrote:
until now, i was not sucessful in finding the "05" with the OEM-software.
However, I found a way to avoid it in linux, by adding delay of 0.01sec after each byte in "_send":def _send(radio, data):
"""Send data to the radio device"""try: for byte in data: radio.pipe.write(byte) sleep(0.01)this of course slows down the whole process, however, without that line, in > than 90% of the cases the download fails, with that line, it worked every time (until now).
So, my assumption is: chirp on linux is too fast for the serial port of the radio ...
Hum... Interesting, it can be (linux is so -good- fast that flips the radio... hi hi hi hi)
I will craft a dev version with your findings and will post here and link to similar thread issues to inform the users and ask for feedback, of course I will include some "mojo" to slow down just the linux version and not the windows one.
Thanks for your tests, 73 Pavel CO7WT.
Updated by Pavel Milanes over 7 years ago
Here it's.
The attached dev version has a fix for the annoying "Invalid header for block 0x0000" error +in any Linux OS+, for all the radios in this family and it's variants:
- BTECH 2501
- BTECH 2501+220
- BTECH 5001
- QYT KT8900
- QYT KT8900R
- Waccom Mini 8900
To try it you must follow this steps:
Save the file btech.py attached to this post to where you keep your chirp radio image files¶
Open Chirp and Click "Help"¶
Enable "Enable Developer Functions"¶
Click "File"¶
Click "Load Module"¶
Find and load the file that was saved in step 1¶
Note: This special test module only temporarily changes your Chirp. You must load this module every time you load Chirp to test it, otherwise you will wet the default installed Chirp.
We hope to see your comments about this working or not to be included in the next daily version.
Thanks to Michael Wagner for this fix.
73 Pavel CO7WT
Updated by Pavel Milanes over 7 years ago
Kristian Thomassen wrote:
The new, uploaded Windows version now works like a charm on my KT-8900R. Thank you so very much!
You are welcomed, 73
Updated by Michael Wagner over 7 years ago
- File btech(1).py btech(1).py added
Hi Pavel,
I just tested your updated file.
The OS linux is not correctly recognized (at least in my setup), as it returns "linux2. Thanks to https://docs.python.org/2/library/sys.html I learned that it is better to use this idiom:
if sys.platform.startswith ('linux'):
Furthermore, the sleep does not work unless you do not import it:
from time import sleep
(sorry for not mentioning that before ...).
Furthermore I tried it again with 5ms, which in my setup also seems to be enough ...
I attached a new version with those fixes.
73,
OE4AMW
Updated by Jim MacKenzie over 7 years ago
Thanks for this fix - I'll give it a try this evening (UTC-6) if I can find time, and report back.
73
Jim VE5EIS
Updated by Michael Wagner over 7 years ago
- File debug.log debug.log added
- File btech_2.py btech_2.py added
Hi Pavel,
attached you can find a different approach in workarounding the issue:
Instead of statically delaying all writes based on the operating system, I tried following: starting without the delay, and waiting for the first error to occur. If the error occurs, I tried to slow down and just re-read the failed amount of memory - this does not work (at least on my radio). If the error again persists, I'm re-trying the whole download-procedure automatically (still with the delay).
As you can see in the attached debug.log, the latter approach works with my KT-8900R.
This is still no proper solution, but might be interesting in following cases:
- in order to find out whether other radios with the "0x05"-error can be recovered that way
- if there are also windows-users with unresponsive '0x05'-radios, they might give it a try
73 de Michael
OE4AMW
PS: Until now, the hack is only implemented for the download (Radio -> Chirp)
PPS: if it does not work for you, try with "sleep(0.01)" instead of "sleep(0.005)"
Updated by Alex Bdx over 7 years ago
Hi,
I've just tried btech_2.py on my Linux 14.04 LTS connected to a Baofeng UV-5001. Downloading and uploading to the radio using the official Baofeng cable worked like a charm (which was not the case before this update). Thanks for the awesome work guys!
Updated by Michael Wagner over 7 years ago
Hi,
glad to hear that. Can you uplad a debug.log of the procedure? I'd like to understand how your radio behaves (and why the upload also works - I thought my changes will only affect download ...).
Updated by Pavel Milanes over 7 years ago
Hi to all, thanks for the fix and bug hunt (import sleep... GGRRR)
I'm on a hurry now from a WiFi in a public square, last night I spend a few hour reviewing logs and I have a theory of why this slow down works (and that will be the confirmation of Linux being too fast on the serial :0, at least for this code.)
I'm downloading everything to review it in the night and comment with calm tomorrow, I would like to hear about a Waccom mini 8900 user under linux...
73 Pavel CO7WT.
Updated by Michael Wagner over 7 years ago
Hi,
I´m quite curious about your analysis / theory of the root-cause.
Which solution do you prefer? Statically slowing down for all linux-users? Or trying without delay first, and retrying delayed in case of errors (btech_2.py)?
Furthermore, you mentioned that x05-problem also happens (rarely) also on windows. It would be fine to have also reports from affected windows-users.
73 Michael OE4AMW
Updated by Jim Unroe over 7 years ago
I only had time for a quick check this morning. I tried two radios. BTECH UV-2501+220 and WACCOM Mini-8900Plus
Both radios failed the first download attempt when downloading with the default CHIRP driver. After loading the test driver module, both downloaded successfully. Switch back to default, download failed. Load special driver again, success. The btech_2.py definitely made a difference.
Jim KC9HI
Updated by Pavel Milanes over 7 years ago
Jim Unroe wrote:
I only had time for a quick check this morning. I tried two radios. BTECH UV-2501+220 and WACCOM Mini-8900Plus
Both radios failed the first download attempt when downloading with the default CHIRP driver. After loading the test driver module, both downloaded successfully. Switch back to default, download failed. Load special driver again, success. The btech_2.py definitely made a difference.
Jim KC9HI
Hi Jim, good to know.
So far we have confirmed it's working on the following models:
- Waccom Mini 8900 Plus
- BTECH UV-5001
- BTECH UV-2501+220
- QYT KT8900
- QYT KT9000R
That's pretty much 90% of the affected models, so it's time for a patch. My thanks and acknowledge to Michael Wagner in the name of the Chirp team & users for finding and fixing this bug.
73 Pavel CO7WT.
Updated by Orv Beach over 7 years ago
I just purchased a BTECH UV-2501+220, and with the help of this patch, am able to upload/download to it from my Fedora Linux 24 box - thanks!
I have one issue that may or may not be related. While most of the channel data appears to be uploaded properly, each channel displays the frequency of Channel 0. I've verified each channel is configured properly, with that one exception.
Any ideas?
Thanks.
73 - Orv - W6BI
Updated by Pavel Milanes over 7 years ago
Michael Wagner wrote:
(...) I´m quite curious about your analysis / theory of the root-cause. (...)
(...)
73 Michael OE4AMW
I was in debt with the explanation for my theory about this, please note that this is a speculation from my side; Aka: I'm maybe wrong here.
The question here is why this bug affects only Linux based systems and why the delay in the writes solved the issue.
It's a know fact that Linux kernel based operating systems have a more precise and have more granular control over time sensitive applications/operations, for example: Python in Linux can control delays in the order of 1 msec, but python in any Desktop version os MS Windows can only go as low as 5 msecs in modern versions.
Yes, it's a fact backed up with data: google the terms "python timing issues linux vs windows" and you will find a lot of data about it. The numbers I state there (1 vs 5 msecs) are taken from those public data & tests on the internet.
I found an issue in the serial portmon logs latter in the investigations of why this patch worked: on the write operations every write take between 3 to 5 msecs to process it, but at 9600 baud the write operation must take no longer of 1 msec for each individual byte write. I think in that time that was a result of the MS Window time granularity control, but now it appears not.
Maybe some of the MCUs (Micro Controller Units, aka brains of the radio) for the affected models are prepared/instructed/slow to handle serial RX operations (writes from the PC) in intervals of about 5 msecs each byte and no more than that. (This is not rare, some other radios do this for CAT commands, see the source in the hamlib project for more details)
The early versions of this drivers used to have another download/upload strategy that don't have this problem (I think it was top speed at that time) but Dan and others revealed that we are just slowing down the read/writes and getting 100% of the CPU (which match the latter findings, being slow and getting time to the MCU to answer back), so we switched to the actual strategy that's more fast and less resource intensive... and get hit by this problem.
So, my conclusions are that some of the MCU in this radios need a pace of about 5 msecs between writes to be safe or it will trough a misplaced 0x05 char in the stream to sign for a error, and that spoils the download/upload process in Linux with Chirp, the OEM software is prepared for this and just restart the process with a bigger delay as logs shows.
Windows with a worst time granularity rarely get hits by this bug and when it's the OEM software knows what to do, Linux OS in the other hand (No OEM Software for Linux so we are talking about Chirp here) is so fast that it get hit more often, and we have a bug here. Then just slowing the writes in Linux OSs solved it.
About the preferred strategy, I think your way is the best as it get two checkpoints for the signs of a "too fast" operation and get slowed just once flagged, that way both Linux and Windows OS get safe in case of a trouble.
With the actual proliferation of variants and clones for this family it's not rare to find one of them failing on windows soon, so this is the way to go.
73 Pavel CO7WT
Updated by Michael Wagner over 7 years ago
Orv Beach wrote:
I just purchased a BTECH UV-2501+220, and with the help of this patch, am able to upload/download to it from my Fedora Linux 24 box - thanks!
I have one issue that may or may not be related. While most of the channel data appears to be uploaded properly, each channel displays the frequency of Channel 0. I've verified each channel is configured properly, with that one exception.
Any ideas?
Thanks.
73 - Orv - W6BI
Hi Orv,
I´m afraid that this issue is not related ... I suggest waiting for this patch to be included in the daily build, and (if it still persist) opening a new issue for it.
Br,
Michael
Updated by Michael Wagner over 7 years ago
After discussion with Dan Smith ( http://intrepid.danplanet.com/pipermail/chirp_devel/2016-September/004264.html ) I added a new patch, that pretty much looks like in post #9 (with shorter delay ...)
http://intrepid.danplanet.com/pipermail/chirp_devel/2016-September/004265.html
73,
OE4AMW
Updated by Michael Wagner over 7 years ago
Retested with chirp-daily 20160926~xenial~1 - from my point of view, ticket can be closed.
Updated by Pavel Milanes almost 7 years ago
- Status changed from In Progress to Resolved
Updated by Pavel Milanes almost 7 years ago
- Status changed from Resolved to Closed