Upload
ngothuy
View
216
Download
1
Embed Size (px)
Citation preview
CHIRP - Bug # 3993
Status: Closed Priority: Normal
Author: Michael Wagner Category:
Created: 09/05/2016 Assignee: Pavel Milanes
Updated: 06/16/2017 Due date:
Chirp Version: daily
Model affected: KT8900R
Platform: Linux
Subject: Error when downloading from QYT KT-8900R
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.
Related issues:
related to Bug # 3871: Cannot connect to Baofeng uv-5001 Gen III Closed 07/31/2016
related to Bug # 3907: Linux version of chirp won't download btech uv-2501+220 Closed 08/11/2016
related to Bug # 3635: Can't download from BTech UV-2501+220 in Linux, but ca... Closed 05/08/2016
related to New Model # 2673: Juentai JT-6188 Feedback 06/26/2015
related to Bug # 3587: QYT KT8900 : Clone failed: Invalid header for block 0... New 04/18/2016
Associated revisions
Revision 2769:0713e77f8ee3 - 09/08/2016 10:14 am - Pavel Milanes
[PATCH][QYT KT8900R] New variant discovered in the wild, fixes #3993
A new variant of this radios was discovered on the wild, this patch giver Chirp support for it
Revision 2779:a5ff94c0d722 - 09/23/2016 10:43 am - Michael Wagner
[btech] Delay writes statically, to avoid invalid header-response from KT-8900. Fixes #3993
Much simpler approch to ommit the "0x05"-Respone-Bug on KT-8900 (and other radios) mostly on linux.
Instead of detecting platform or only delaying only on case of previous errors, the write is now always delayd.
Result of following thread:
http://intrepid.danplanet.com/pipermail/chirp_devel/2016-September/004264.html
73,
OE4AMW
History
#1 - 09/06/2016 10:39 am - Michael Wagner
- File debug_true.log added
04/29/2018 1/12
Added debug.log with "debug = True" set in /usr/lib/python2.7/dist-packages/chirp/drivers/btech.py .
#2 - 09/07/2016 10:57 am - Michael Wagner
- File kt8900r_portmon.zip added
added traces according to "how to portmon.doc"
#3 - 09/08/2016 12:18 am - Kristian Thomassen
- File debug.log added
- File 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!
#4 - 09/08/2016 01:33 am - Michael Wagner
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
04/29/2018 2/12
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
04/29/2018 3/12
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...
#5 - 09/08/2016 09:48 am - Michael Wagner
- File manual_with_moserial.png added
- File 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.
#6 - 09/08/2016 10:14 am - Pavel Milanes
- Status changed from New to In Progress
- Assignee set to Pavel Milanes
- Estimated time set to 2.00
Hi to all, chirp's developer fo this radio here.
We have two separate problems in this issue.
04/29/2018 4/12
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.
#7 - 09/08/2016 10:30 am - Pavel Milanes
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.
#8 - 09/08/2016 11:48 am - Michael Wagner
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
#9 - 09/08/2016 02:44 pm - Michael Wagner
04/29/2018 5/12
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 ...
#10 - 09/09/2016 01:27 pm - Kristian Thomassen
The new, uploaded Windows version now worksl like a charm on my KT-8900R. Thank you so very much!
#11 - 09/12/2016 06:27 am - Pavel Milanes
- % 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.
#12 - 09/12/2016 08:59 am - Pavel Milanes
- File btech.py added
- % Done changed from 50 to 90
04/29/2018 6/12
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:
1. Save the file btech.py attached to this post to where you keep your chirp radio image files
2. Open Chirp and Click "Help"
3. Enable "Enable Developer Functions"
4. Click "File"
5. Click "Load Module"
6. 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
#13 - 09/12/2016 09:23 am - Pavel Milanes
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
#14 - 09/12/2016 10:32 am - Michael Wagner
- File 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'):
04/29/2018 7/12
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
#15 - 09/12/2016 12:59 pm - Jim MacKenzie
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
#16 - 09/12/2016 03:11 pm - Michael Wagner
- File debug.log added
- File 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)"
#17 - 09/12/2016 09:43 pm - Alex Bdx
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!
#18 - 09/12/2016 10:29 pm - Michael Wagner
04/29/2018 8/12
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 ...).
#19 - 09/13/2016 02:15 pm - Pavel Milanes
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.
#20 - 09/14/2016 02:27 am - Michael Wagner
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
#21 - 09/14/2016 03:43 am - Jim Unroe
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
#22 - 09/15/2016 07:49 am - Pavel Milanes
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.
04/29/2018 9/12
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.
#23 - 09/17/2016 11:25 am - Orv Beach
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
#24 - 09/19/2016 01:56 pm - Pavel Milanes
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.
04/29/2018 10/12
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
#25 - 09/23/2016 04:09 am - Michael Wagner
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
04/29/2018 11/12
#26 - 09/23/2016 12:10 pm - Michael Wagner
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
#27 - 09/26/2016 01:00 pm - Michael Wagner
Retested with chirp-daily 20160926~xenial~1 - from my point of view, ticket can be closed.
#28 - 06/16/2017 07:31 am - Pavel Milanes
- Status changed from In Progress to Resolved
#29 - 06/16/2017 07:32 am - Pavel Milanes
- Status changed from Resolved to Closed
Files
debug.log 20.8 kB 09/05/2016 Michael Wagner
KT-8900r_original.dat 91.6 kB 09/05/2016 Michael Wagner
serial_port_monitor_from_original_software.htm 83.1 kB 09/05/2016 Michael Wagner
debug_true.log 20.2 kB 09/06/2016 Michael Wagner
kt8900r_portmon.zip 1.1 MB 09/07/2016 Michael Wagner
debug.log 19.3 kB 09/08/2016 Kristian Thomassen
Error mssg.jpg 7.8 kB 09/08/2016 Kristian Thomassen
manual_with_moserial.png 47.1 kB 09/08/2016 Michael Wagner
portmon_chirp_windows.LOG 189.4 kB 09/08/2016 Michael Wagner
btech.py 55.4 kB 09/12/2016 Pavel Milanes
btech(1).py 55.5 kB 09/12/2016 Michael Wagner
debug.log 242.1 kB 09/12/2016 Michael Wagner
btech_2.py 56.6 kB 09/12/2016 Michael Wagner
04/29/2018 12/12