New Model #3509
closedWouxun KG-UV9D Plus
100%
Description
Hello, requesting support for new model Wouxun KG-UV9D Plus. I have both the KG-UV9D and KG-UV9D Plus radios; the file formats are different. The Wouxun factory programming software for KG-UV9D Plus will not open files created by KG-UV9D (non-Plus) programming software, nor will the KG-UV9D (non-Plus) programming software read from or write to the new KG-UV9D Plus radio. Thank you.
Files
| KG-UV9D-Plus-OutOfBox-Read.txt (346 KB) KG-UV9D-Plus-OutOfBox-Read.txt | |||
| test.py (23.8 KB) test.py | test program to decode radio transactions | ||
| pcap2txt (106 Bytes) pcap2txt | shell script to grab the important wireshark bits and feed them to pcap2stream | ||
| pcap2stream.py (1.21 KB) pcap2stream.py | converts pcap capture into lines for test.py | ||
| add_kguv9dplus.patch (65.8 KB) add_kguv9dplus.patch | HG patch file for driver based on current upstream 'tip' | ||
| Wouxun_KG-UV9D_Plus.img (32 KB) Wouxun_KG-UV9D_Plus.img | Wouxon 9D Plus image file | ||
| uv9-Error3.png (8.74 KB) uv9-Error3.png | Missing Characters | ||
| uv9-Error4.png (13.1 KB) uv9-Error4.png | Missing Characters | ||
| uv9-Error5.png (31.8 KB) uv9-Error5.png | Error Message trying to input a frequency | ||
| uv9-Error6.png (10.3 KB) uv9-Error6.png | Error Message on reading from radio | ||
| Screen Shot 2019-03-18 at 21.50.26.png (19.3 KB) Screen Shot 2019-03-18 at 21.50.26.png |
Updated by ben-Nabiy Derush over 8 years ago
I also have one of these radios, and would love to see it supported by chirp. How does it work with equipment loan? Is there a list I can get on about when support for this radio (the plus version) is added?
Updated by Rayner Marx over 8 years ago
Hello, I'm not familar with either the loan or notification process. Thanks.
Updated by ben-Nabiy Derush over 8 years ago
How do I go about generating logs? I use Linux. If I need to, I can fire up a windows box, but prefer not to.
Updated by Fred Munden over 8 years ago
Take a look at issue #2671, I have used AccessPort (sudt.com) to capture read/write serial logs. It is a Windows program works on 64bit. I would be very interested in looking at 9D Plus serial port logs. I have compared 8D and 8D Plus serial port logs. They are very different.
Updated by Rayner Marx over 8 years ago
Patrick McCourt wrote:
How do I go about generating logs? I use Linux. If I need to, I can fire up a windows box, but prefer not to.
Hello, looks like Fred has addressed your question. Thanks.
Updated by Dean Santiago over 8 years ago
I also have a wouxun kg-uv9d plus, desperatly trying to clone a baofung uv82 v2 plus which I guess you included in the update cause it now works with chirp since new update thanks a million..
Updated by Carsten Schaudel almost 8 years ago
Is the current author-team interested in contribution to this topic?
I started looking into that, and deriving the KG-UV9DPlus config from the existing UV8d seems not so complicated - considering that the safe-files from the wouxun tool basically just contain a dump of the memorymap.
By my own interest started working on this allready ....
Updated by Ed McGough about 7 years ago
I also have a 9D Plus and would like it added.
Thanks
Updated by Pavel Milanes almost 7 years ago
Hi to all.
A developing process is on going for a similar radio (KG-UV8E, a variant of the KG-UV8D Plus) in issue #3943 and I would like to take a peek on any serial logs from the KG-UV9D Plus to see if they are related and can be supported.
Can any of you produce a serial log for this radio (Download and Upload)?
73 Pavel CO7WT.
Updated by Fred Munden almost 7 years ago
Attached is a read serial log.
Fred
Updated by Gautier Hankenne almost 7 years ago
Pavel Milanes wrote:
Can any of you produce a serial log for this radio (Download and Upload)?
73 Pavel CO7WT.
If you need anything else, please ask again, I would be happy to try and help even with my small knowledge in the radio world. I programmed my UV9D plus with the stock program but chirp is so better!
Gautier
Updated by Pavel Milanes almost 7 years ago
Thank Gautier.
I have started today the analysis of the logs, it's very similar to the KG-UV950... I have the crypt part done but the checksum needs more work.
I'm working on it... I will keep you posted.
73 Pavel, CO7WT
Updated by Pavel Milanes almost 7 years ago
A fragment of the log, you can see the ident of the radio and the band edges in there...
<= Decrypted payload [74] Address: 4b47
000: 4b 47 2d 55 56 39 44 30 32 04 38 07 08 0f a0 14 KG-UV9D02.8.....
016: 00 0d ac 0f 96 1b 58 20 26 08 fc 09 c4 05 a0 05 ......X.&.......
032: be 10 68 11 8a 05 50 06 cc 01 04 38 07 08 0f a0 ..h...P....8....
048: 14 00 0d ac 0f 96 1b 58 26 84 08 fc 09 c4 05 50 .......X&......P
064: 06 cc 0f a0 14 00 05 50 06 cc 00 00 00 00 00 00 .......P........
Invalid packet
The "Invalid packet" is the proof that I have to work it out...
73 Pavel.
Updated by Gautier Hankenne almost 7 years ago
Well done but annoying Invalid packet!
Keep up the good work...
Gautier
Updated by James Lieb over 6 years ago
- File test.py test.py added
- File pcap2txt pcap2txt added
- File pcap2stream.py pcap2stream.py added
I have been working with Pavel to get this radio done. I own a 9D-Plus (powerwerks version) from HRO so YMMV if you got yours from another source. Pavel sent me a testing program that I've been hacking to get things decoded. Once I have all the config packets decoded and understood, I'll create a module for the radio and push patches to the -devel list. If you run test.py across your own trace and see only a hex dump, I haven't gotten to it yet. If you know what those bits are, let me know.
I originally tried the sudt.com terminal monitor but it seems to only work with win7 and below. win8.1 enforces exclusive access to COM ports. Wireshark is an old friend so I used USBPcap instead. The captures do seem to randomly drop parts of writes to channel memory but the radio is happy and I get only a few (2-6) messed up packets and they are all essentially the same so... I have run all of the sudt.com traces that have been posted to the bug.
I've decoded the packet format and tested both the decode and encode. And yes, it is mostly an obstruction and bugs. The check byte at the end of each record is only the low 4 bits (the high nibble is 0x0). See the code for details. Note how, across what range, and in which order the "checksum" and "encrypt" happen. I have confirmed all this by looking at the x86 code.
It should be no surprise that the app one can download from the Powerwerx site site is, at best, lame. I have found a number of bugs in it already and have documented things I have found in the code. I don't know what effect any of this could have on the radio, particularly in the caller id and stun/kill/revive code. ANI codes should be only 0-9 but the app allows "#" and stuffs things like 0x0c and 0x0a in for grins...
I've not fully decoded the 'ident' reply yet but, so far, I've decoded a 'rev' field such that '01' appears to be a UV9d and a '02' is a UV9D-Plus (at least a Powerwerx version). If you post some pre- post- dumps, or better yet, some diff -u files of your own runs I can work with them. It looks like band ranges but I haven't grok'd the encoding yet.
Notes on python. You will note that I have some comments on Python usage. I am a Fedora (linux) shop for everything other than Turbo-Tax and things like this brain-dead app. Current Fedora uses Python 3 and 2.7 whereas others may be using older versions. My first runs of test.py showed up some problems with handling the transactions as strings. These are 8 bit binary streams and treating them like strings with ord() and chr() can do nasty things if the functions think they have found unicode code points. Python3 deliberately breaks things since its strings are fully unicode. I changed things over to only use byte arrays and only convert them to strings for display purposes. If you are using python < 2.7 beware (and upgrade). The chirp codebase will have to be scrubbed for this usage to port to Python3. (must do by 2020). A sample run to see what wiggles when I flip bits in the radio via the app and move the trace file (.pcap) to my workstation:
$ ./pcap2txt conf6.pcap >conf6.txt
$ ./test.py conf5.txt >conf5.dump
$ ./test.py conf6.txt >conf6.dump
$ diff -u conf5.dump conf6.dump>conf5-conf6.diff
I will post more as I get more. I'm supposedly retired from this business... ;)
Updated by John Spady over 6 years ago
Thank you for your dedication to this project James Lieb.
73, John WA7UAR
Seattle
Updated by Dan Mulkiewicz over 6 years ago
Also just registered so I could post no useful information but a BIG "THANK YOU" for your efforts with this radio!
Dan
Updated by justin boquet about 6 years ago
I am hopeing this radio is supported by chirp soon! any thing i can do to help?
Updated by Ben Cook about 6 years ago
I also would like to join those pleading for software for the KG-UV9D. What is the holdup, and what can I do to help? I'd be glad to donate!
Updated by Gary Goss about 6 years ago
Like others, I also have one of these radios. Does it look like it will be added or a lost issue? Thank you for all that you have done. Gary
Updated by James Lieb almost 6 years ago
I have a working driver (more or less). There are a few things not working yet but I am looking for testers who are willing to give it a go. I am particularly interested in a tester who has a UV9D, not a "plus".
I have not fried or bricked my radio (yet) - not that I haven't tried. I will push the code through the normal channels in a few days after I tie up a few loose ends.
What works (full disclosure):
It reads the radio and displays everything that the Powerwerx app displays.
It modifies all those fields although full testing of every field against the supplied app is not complete.
It writes a config to the radio and doesn't brick anything.
It appears that the radio just silently rejects anything it does not like rather than doing a NAK. This is annoying but doesn't brick it. It will also accept bogus values for things like CTCSS/DCS codes which seem to make the Powerwerx app do very wierd things but... I figure a bogus code to an rpt with code squelch is as good as no code so no harm, no foul.
What doesn't work:
It writes image files but does not seem to like what it wrote (yet). It does handle memory csv files though. I do not have a clean, out-of-the-box .img file. That is long gone... An image after a full reset should do but I have not pulled that trigger yet either.
I don't like the UI but that is a core issue (no way to display a 2D table) that makes some tabs (scan groups and callids) awkward. It is not as ugly as the supplied app but...
Updated by James Lieb almost 6 years ago
- File add_kguv9dplus.patch add_kguv9dplus.patch added
Here is a working driver. I have submitted it through chirp-devel but include it here "just in case". I also include the .img file.
The image file is not from and out-of-the-box radio which Powerwerx customized. This image is similar but adds a few
other channel memory entries and has sensible VFO defaults.
Updated by James Lieb almost 6 years ago
- File Wouxun_KG-UV9D_Plus.img Wouxun_KG-UV9D_Plus.img added
Here is the image file described in the previous update. See the patch file above for details.
NOTE: I have not run tox against this driver. Sorry. Fedora does not support a tox < 3.0 and the one from Fedora complains mightily about everything chirp not being 3.x. Taking an upstream python 2.7 dev env would also make a mess of things.
Everything has run in a Python 2.7 on Fedora 29.
Updated by James Lieb almost 6 years ago
Fedora has released an update of chirp that contains this driver.
Name : chirp
Version : 20181214
Release : 1.fc29
This bug should be closed.
Updated by Jerzy Trzeciak almost 6 years ago
Hi
I am sorry my English.
I found smal error in a kguv9dplus.py
In lines 1588-1590
def apply_offset(setting, obj):
f = freq2int(setting.value, 0, 5000000)
obj.offset = f/10
The offset for Europe have to be 7600000 Hz, I think.
Jurek
Updated by Mike Peters over 5 years ago
- File uv9-Error3.png uv9-Error3.png added
- File uv9-Error4.png uv9-Error4.png added
- File uv9-Error5.png uv9-Error5.png added
- File uv9-Error6.png uv9-Error6.png added
I have a UV9D Plus from Buytwowayradios.com and I've had a few problems using CHIRP to program it.
1) Reading from the radio gives me ERROR on some channels, and missing characters in the name on others as you can see from the screenshots below taken from the wouxon program vs chirp. Out of about 500 channels, about 30 or so had missing last character in the name. I had originally programmed the radio with the supplied software.
2) Trying to input a frequency, I often get the error regarding tuning step 12.50 not supported, that it needs to be 12.50kHz.
Thanks for any help!
Updated by Dan Smith over 5 years ago
- Chirp Version changed from 0.4.0 to daily
Mike, you're describing at least one new bug if not two. The tune-step thing is known and I'll push a fix for it in a few minutes. If tomorrow's build still returns ERROR memories, please save and attach a .img of the radio to a NEW bug report.
Thanks!
Updated by Dan Smith over 5 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset commit:2513b6da29c3.
Updated by Jerzy Trzeciak over 5 years ago
Jerzy Trzeciak wrote:
Hi
I am sorry my English.
I found smal error in a driver kguv9dplus.py
In lines 1588-1590def apply_offset(setting, obj): f = freq2int(setting.value, 0, 5000000) obj.offset = f/10The offset for Europe have to be 7600000 Hz, I think.
Jurek
Updated by Jerzy Trzeciak over 5 years ago
Jerzy Trzeciak wrote:
Jerzy Trzeciak wrote:
Hi
I am sorry my English.
I found smal error in a /chirp/driver/kguv9dplus.py
In lines 1588-1590def apply_offset(setting, obj): f = freq2int(setting.value, 0, 5000000) # error obj.offset = f/10
Have to be:
def apply_offset(setting, obj):
f = freq2int(setting.value, 0, 7600000)
obj.offset = f/10
The offset for Europe have to be 7600000 Hz, I think.
Jurek
Updated by Jerzy Trzeciak over 5 years ago
Jerzy Trzeciak wrote:
Jerzy Trzeciak wrote:
Jerzy Trzeciak wrote:
Hi
I am sorry my English.
I found smal error in a /chirp/drivers/kguv9dplus.py
In lines 1588-1590def apply_offset(setting, obj): f = freq2int(setting.value, 0, 5000000) # error obj.offset = f/10Have to be:
def apply_offset(setting, obj): f = freq2int(setting.value, 0, 7600000) obj.offset = f/10The offset for Europe have to be 7600000 Hz, I think.
Jurek
Updated by Elvis Pfutzenreuter over 5 years ago
I have a problem while trying to use Chirp with my 9D+ radio: "Failed to communicate with radio: unpack requires a string argument of length 9". I have been trying several daily versions since a couple months ago.
Is there something I can do to help? I know a bit of Python, so I could help if I get some initial direction on what to look for.