Bug #10208
closedError communicating with radio (Unicode) Wouxun drivers
Added by Lynda Leung almost 2 years ago. Updated almost 2 years ago.
100%
Description
Platform:
macOS Monterey 12.6.2
FT232R USB UART
Wouxun radios - KG-UV8D Plus, KG-UV8E, KG-UV8T
Error communicating with radio
Failed to communicate with radio: unicode strings are not supported, please encode to bytes: '{\x80ΓΏ\x00('
All three drivers return the same error as all three share the base drive codes.
Files
| chirp_debug-mbok5o0x.txt (35.8 KB) chirp_debug-mbok5o0x.txt | kguv8e debug log | Lynda Leung, 01/01/2023 04:09 PM | |
| chirp_debug-zt633ba4.txt (41.5 KB) chirp_debug-zt633ba4.txt | kguv8t debug log | Lynda Leung, 01/01/2023 04:16 PM | |
| chirp_debug-76dteca1.txt (45.2 KB) chirp_debug-76dteca1.txt | kguv8dplus debug log | Lynda Leung, 01/01/2023 04:18 PM | |
| Screenshot from 2023-01-02 11-24-40.png (59.2 KB) Screenshot from 2023-01-02 11-24-40.png | Tony Fuller, 01/02/2023 05:25 PM | ||
| kguv8dplus.py (41 KB) kguv8dplus.py | Prospective Converted KG-UV8DPlus | Dan Smith, 01/02/2023 05:58 PM | |
| chirp_debug-thce2iz2.txt (35.9 KB) chirp_debug-thce2iz2.txt | Attempt to use kguv8e.py replacement driver | Lynda Leung, 01/02/2023 07:24 PM | |
| chirp_debug-b2w3qtz3.txt (35.9 KB) chirp_debug-b2w3qtz3.txt | kguv8e.py attempt #2 | Lynda Leung, 01/02/2023 07:33 PM | |
| kguv8e.py (41.8 KB) kguv8e.py | Prospective Converted KG-UV8E v3 | Dan Smith, 01/02/2023 07:47 PM | |
| chirp_debug-jo9z50rk.txt (1.06 MB) chirp_debug-jo9z50rk.txt | Lynda Leung, 01/02/2023 07:57 PM |
Updated by Dan Smith almost 2 years ago
Can you attach your debug log please? Help->Show Debug Log.
Updated by Lynda Leung almost 2 years ago
- File chirp_debug-mbok5o0x.txt chirp_debug-mbok5o0x.txt added
- File chirp_debug-zt633ba4.txt chirp_debug-zt633ba4.txt added
- File chirp_debug-76dteca1.txt chirp_debug-76dteca1.txt added
Sure thing, here a log file attached
I find it interesting that some of these radios references to a kg935g.py driver.
Updated by Dan Smith almost 2 years ago
Hi Lynda,
Thanks for the logs.
These actually don't share code (although they probably should) so it will be three separate efforts. I can take a crack at them in the blind, but I just want to make sure: you can test all three of these right?
Updated by Dan Smith almost 2 years ago
- Status changed from New to In Progress
- Assignee set to Dan Smith
- Target version set to chirp-py3
Hi Lynda,
I'm attaching the first one for you to try, the KGUV8DPlus. You need to enable developer mode in the Help menu. After you restart chirp, you can use File->Load Module to load this file and then give it a test. Please report back about how it works, and if it doesn't, include a debug log with it.
I'll start on the other ones now.
Updated by Tony Fuller almost 2 years ago
Hey Dan,
This can be reproduced if you enable developer mode, load one of the Wouxun images in the repo, and then attempt to upload to a custom serial port named loop:///dev/null.
Updated by Dan Smith almost 2 years ago
This can be reproduced if you enable developer mode, load one of the Wouxun images in the repo, and then attempt to upload to a custom serial port named
loop:///dev/null.
Only the first bit of it. After it gets past the first attempt to identify the radio, there's a bunch of code that you'll never get to that needs conversion as well. I've been writing unit tests effectively simulating these radios to exercise all the code without an actual radio:
https://github.com/kk7ds/chirp/blob/master/tests/unit/test_kguv8d.py
Updated by Dan Smith almost 2 years ago
- File kguv8dplus.py kguv8dplus.py added
Sorry for all the false starts. These drivers are a bit of a mess with a ton of copied code with very subtle differences. Hopefully this one works for the 8dplus.
Updated by Lynda Leung almost 2 years ago
I was just about to post that the KGUV8DPlus is current loaned out to a friend, and I dont have immediate access to the radio.
however, I do have a few KGUV8E's around I can test the new codes with. I'll post again with my results soon.
Updated by Lynda Leung almost 2 years ago
Bear with me here. But Im not sure where I am putting the kguv8e,py, as Im not familiar with the structure of this new program.
Is it hidden somewhere or stored in an archive file somewhere ?
$ pwd
/Applications/CHIRP-next.app
$ find . -name "kguv8e.py"
$
Updated by Dan Smith almost 2 years ago
You don't need to put it anywhere specific. Enable Developer mode in chirp via the Help menu. Then restart chirp and you will have a new File->Load Module menu entry. From there, you can just select the .py file, wherever you saved it. It will be loaded into chirp for just that session to test.
Updated by Lynda Leung almost 2 years ago
- File chirp_debug-thce2iz2.txt chirp_debug-thce2iz2.txt added
After fiddling around for a while, I think I might have figured out how to load the driver file by using pull down. menu File, "Load Module".
The screen upper and lower banner becomes red.
Upon attempt to download from the radio I got a "Radio did not respond" error.
Attached is the log file associated with this attempt. Please let me know if if this is the right way to do this.
Updated by Dan Smith almost 2 years ago
- File kguv8e.py added
Yep, that's the right way to load it. That log helped me identify something I did wrong, so here's a replacement to try.
Updated by Lynda Leung almost 2 years ago
Dan Smith wrote in #note-15:
You don't need to put it anywhere specific. Enable Developer mode in chirp via the Help menu. Then restart chirp and you will have a new File->Load Module menu entry. From there, you can just select the .py file, wherever you saved it. It will be loaded into chirp for just that session to test.
Got it, kinda sorta figured it out too. Thanks for confirming this is the right way of doing this. Thats actually a really nice feature not having the fiddle with the file structure while debugging!
Updated by Lynda Leung almost 2 years ago
- File chirp_debug-b2w3qtz3.txt chirp_debug-b2w3qtz3.txt added
Dan Smith wrote in #note-18:
Yep, that's the right way to load it. That log helped me identify something I did wrong, so here's a replacement to try.
Same error again. Attached log for you to trace.
Updated by Dan Smith almost 2 years ago
Okay, found another thing. That error message is very non-specific, so we may continue seeing that until it suddenly works :)
Here's another one to try.
Thanks for your help here - debugging remotely like this is quite laborious, for both of us.
Updated by Lynda Leung almost 2 years ago
- File chirp_debug-jo9z50rk.txt chirp_debug-jo9z50rk.txt added
Dan Smith wrote in #note-22:
Okay, found another thing. That error message is very non-specific, so we may continue seeing that until it suddenly works :)
Here's another one to try.
Thanks for your help here - debugging remotely like this is quite laborious, for both of us.
I'm just grateful that devs like you are really on top of it, so I really dont mind at all.
Looks like we lucked out! the latest version worked. I started with a download, and immediately upload it back to the radio.
Both operations completed without throwing any errors. Cheers!
Attached log file for your reference.
Updated by Dan Smith almost 2 years ago
- % Done changed from 0 to 30
Okay, great, thanks!
If it's okay I'd like to put you down as the tester for this. Can I use your callsign for that (if so what is it)? It's just helpful to know who has what if we need to test something again.
Is there an ETA for return of the 8DPlus such that you'd be able to test that? If not very soon, I'll probably put what I have into the tree since it's closer to right and just not mark it as tested.
And finally - do you have a UV8T to test with locally? If so, I'll start on that one to get it validated, otherwise I might punt until I have a tester ready.
Thanks!
Updated by Lynda Leung almost 2 years ago
Another thing I, going to try in the future is to enter to actually input unicode, specificity in chinese for channel names.
Since the default radio config has a few chinese characters in it, which suggest it might be able to render unicode characters outside of the standard ascii set. Original CHiRP naturally didnt like those entries.
Anyways of course you can put me down on as a tester for this radio, my callsign is W5EGL. As for the 8DPLus. Probably sometimes next week? I might be able to get my friend run the test file over the phone. So it might still be a good idea to post it for testing here ahead of time. Especially assuming the resolution is the same for that radio too.
AS for the UV8T, I no longer have this radio, and the last one was sold. From what I know Uv8E is almost identical, just without umm certain restrictions? For those in the know of course.
Updated by Lynda Leung almost 2 years ago
Oh yea, you should be able to put me down as a tester for the 8DPlus , KG-968, and KG-UVN1 (if it ever would come to past). I have access to a number of these radios as I am a small fry direct dealer of Wouxun radios.
Updated by Lynda Leung almost 2 years ago
Sorry for the post spam. the KG-958's and KG-UVN1 , I have two of each of these available for loans out if someone want to develop drivers for them.
Updated by Dan Smith almost 2 years ago
Honestly the drivers for all these radios should share a ton of code, but they don't. I didn't write them, and maintaining them with all this copied (but tweaked) code is a bit failure-prone (as you noticed).
I'll put you down as the tester for the 8E and the other two will remain as "prospective" until someone can confirm, just to be on the safe side.
As far as unicode, the character set in the radio is definitely not capable of full unicode, as the memory reserved for the characters is only 8-bits wide. Most of the radios that support "foreign" glyphs do so by way of multiple character sets that fit 8-bits wide with a switch between them. In order to make that work, a developer that can understand the alternate glyphs has to write code to support it, which hasn't happened (for any of these).
Thanks for your help!
Updated by Dan Smith almost 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 30 to 100
Applied in changeset github|4b60aae1a30e0f5d52a349d60c882731e7c02610.