13
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

CHIRP - #Bug 3993 · PDF fileCHIRP - Bug # 3993 Status: Closed Priority: Normal Author: Michael Wagner Category: Created: 09/05/2016 Assignee: Pavel Milanes Updated: 06/16/2017 Due

  • Upload
    ngothuy

  • View
    214

  • 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