New Model #3509

Wouxun KG-UV9D Plus

Added by Rayner Marx over 6 years ago. Updated over 3 years ago.

Status:Closed Start date:03/24/2016
Priority:Normal Due date:
Assignee:- % Done:

100%

Category:-
Target version:-
Chirp Version:daily Equipment Loan Offered:No

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.

KG-UV9D-Plus-OutOfBox-Read.txt (345.6 kB) Fred Munden, 01/29/2018 06:01 pm

test.py - test program to decode radio transactions (23.8 kB) James Lieb, 04/19/2018 01:40 pm

pcap2txt - shell script to grab the important wireshark bits and feed them to pcap2stream (106 Bytes) James Lieb, 04/19/2018 01:40 pm

pcap2stream.py - converts pcap capture into lines for test.py (1.2 kB) James Lieb, 04/19/2018 01:40 pm

add_kguv9dplus.patch - HG patch file for driver based on current upstream 'tip' (65.8 kB) James Lieb, 12/03/2018 06:08 pm

Wouxun_KG-UV9D_Plus.img - Wouxon 9D Plus image file (32 kB) James Lieb, 12/03/2018 06:17 pm

uv9-Error3.png - Missing Characters (8.7 kB) Mike Peters, 02/21/2019 01:42 pm

uv9-Error4.png - Missing Characters (13.1 kB) Mike Peters, 02/21/2019 01:42 pm

uv9-Error5.png - Error Message trying to input a frequency (31.8 kB) Mike Peters, 02/21/2019 01:42 pm

uv9-Error6.png - Error Message on reading from radio (10.3 kB) Mike Peters, 02/21/2019 01:42 pm

Screen Shot 2019-03-18 at 21.50.26.png (19.3 kB) Elvis Pfutzenreuter, 03/18/2019 05:55 pm


Related issues

duplicated by New Model #5191: WOUXUN KG-UV9D PLUS Rejected 09/26/2017
duplicated by New Model #5311: wouxun KG-UV9D Plus Rejected 11/04/2017
duplicated by New Model #5313: wouxun KG-UV9D Plus Rejected 11/04/2017
duplicated by New Model #5475: wouxun KG-UV9D Plus Rejected 11/04/2017

Associated revisions

Revision 3010:55a608519054
Added by James Lieb over 3 years ago

[kguv9dplus] Add support for Wouxon KG-UV9D Plus

Issue: #3509

Adds support for Wouxon KG-UV9d Plus model available from Powerwerx

Passes run_tests and pycodestyle-2.7

This supports all functions relative to the Wouxon/Powerwerx configuration
app with the following exceptions:

1. Scanning CTCSS/DCS (menu 51) is only available on the radio. It appears
to be in volatile memory and gets reset to default (CTCSS) on power cycle.
The supplied app doesn't support it either.

2. DTMF Transmit Interval is on the configuration tab and seems to operate
on the supplied app but it does not appear to be written to the radio.
As a result, it is not in the memory map and doesn't appear at all in
this driver.

3. The supplied app fills in '0's to the right of either the menu or reset
password UI fields. The Chirp UI doesn't seem to support field writeback so
a less than 6 digit password has trailing blanks. However, the full '0'
padded
password is correctly uploaded to radio. Re-downloading the radio will show
the
filled out field correctly. For example, a password of '1234' is actually
sent
to the radio as '123400'.

4. Some tabs (Call ids in partiicular) would be better presented as a three
column
table.

Signed-off-by: Jim Lieb <>

Revision 3012:792e9bcf08a5
Added by Dan Smith over 3 years ago

Add KG-UV9Dplus image for #3509

Revision 3013:e69b2387dc67
Added by Dan Smith over 3 years ago

Fix style issues in kguv9dplus

I forgot to add it to the manifest, so I didn't notice these:

./chirp/drivers/kguv9dplus.py:982:74: E222 multiple spaces after operator
./chirp/drivers/kguv9dplus.py:1031:80: E501 line too long (80 > 79 characters)
./chirp/drivers/kguv9dplus.py:1032:80: E501 line too long (80 > 79 characters)
./chirp/drivers/kguv9dplus.py:1890:26: W291 trailing whitespace

Related to #3509

Revision 3171:2513b6da29c3
Added by Dan Smith over 3 years ago

Fix tuning step on Wouxun KG-UV9D Plus

Related to, but also closes #3509

History

Updated by ben-Nabiy Derush about 6 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 about 6 years ago

Hello, I'm not familar with either the loan or notification process. Thanks.

Updated by ben-Nabiy Derush about 6 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 about 6 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 about 6 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 about 6 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 over 5 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 almost 5 years ago

I also have a 9D Plus and would like it added.

Thanks

Updated by Pavel Milanes over 4 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 over 4 years ago

Attached is a read serial log.

Fred

Updated by Gautier Hankenne over 4 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 over 4 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 over 4 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 over 4 years ago

Well done but annoying Invalid packet!

Keep up the good work...

Gautier

Updated by James Lieb over 4 years ago

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 4 years ago

Thank you for your dedication to this project James Lieb.
73, John WA7UAR
Seattle

Updated by Dan Mulkiewicz about 4 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 almost 4 years ago

I am hopeing this radio is supported by chirp soon! any thing i can do to help?

Updated by Ben Cook almost 4 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 almost 4 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 over 3 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):

1. It reads the radio and displays everything that the Powerwerx app displays.

2. It modifies all those fields although full testing of every field against the supplied app is not complete.

3. 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 over 3 years ago

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 over 3 years ago

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 over 3 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 over 3 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 3 years ago

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 3 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 3 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Applied in changeset 2513b6da29c3.

Updated by Jerzy Trzeciak over 3 years ago

Jerzy Trzeciak wrote:

Hi
I am sorry my English.
I found smal error in a driver 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 Jerzy Trzeciak over 3 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-1590

def 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 3 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-1590

def 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 Elvis Pfutzenreuter over 3 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.

Also available in: Atom PDF