Project

General

Profile

Actions

New Model #53

closed

Support Wouxun KG-UV6D

Added by Richard Shaw over 12 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Target version:
Start date:
02/12/2012
Due date:
% Done:

0%

Estimated time:
Equipment Loan/Gift Offered:
I read the instructions above:

Description

Please consider supporting the Wouxun KG-UV6D. From what I can gather it's somewhat different from the UV2D since you can not use the software from the UV2D and even suggests it can kill your radio.

http://www.wouxun.us/item.php?item_id=222&category_id=50


Files

wouxun6.patch (2.2 KB) wouxun6.patch Initial wouxun6 patch Dan Smith, 03/14/2012 05:32 PM
output (3.11 KB) output KG-UV6D Stefano Comelli, 03/17/2012 08:18 AM
wouxun6_r2.patch (2.18 KB) wouxun6_r2.patch Replacement initial wouxun patch Dan Smith, 03/17/2012 09:06 AM
output_r2 (3.33 KB) output_r2 Output v2 Stefano Comelli, 03/17/2012 09:31 AM
wouxun6_r3.patch (2.18 KB) wouxun6_r3.patch Dan Smith, 03/17/2012 09:34 AM
output_r3 (3.36 KB) output_r3 Stefano Comelli, 03/17/2012 09:57 AM
wouxun6_r4.patch (2.32 KB) wouxun6_r4.patch Wouxun patch to accept id and attempt download Dan Smith, 03/17/2012 10:18 AM
output_r4 (3.11 KB) output_r4 Stefano Comelli, 03/17/2012 10:23 AM
output.log (3.13 KB) output.log Richard Shaw, 03/19/2012 03:41 PM
Wouxun_KG-UVD6D.img (8 KB) Wouxun_KG-UVD6D.img First image dowloaded from radio Filippi Marco, 05/24/2012 03:46 PM
wouxun_menu_lock.patch (1.79 KB) wouxun_menu_lock.patch Dan Smith, 05/25/2012 07:12 PM
Wouxun-KG-UV6X-pristine.img (8 KB) Wouxun-KG-UV6X-pristine.img Initial dump from KG-UV6X, pristine Ed Santiago, 05/25/2012 07:26 PM
Actions #1

Updated by Dan Smith over 12 years ago

  • Status changed from New to Blocked
  • Priority changed from Normal to Low

I will certainly evaluate and make an attempt when I have an opportunity to get my hands on one.

I will say, however, that supporting these radios in a sane and safe way is an ever-increasing challenge. The ultra-low cost chinese manufacturers do no design and architecting of their products, which leads to issues like the one they have created with incompatible software and radio versions. This becomes somewhat of a liability for me, as CHIRP becomes a path to potentially bricking a radio.

Actions #2

Updated by Richard Shaw over 12 years ago

Is there anything I can do to help? I could do a read/write using the supplied software if there was a way to capture the serial input/output. I'm currently using Fedora 16 but running the software on a virtualized Windows XP instance.

Actions #3

Updated by Dan Smith over 12 years ago

Unfortunately, probably not. Have you tried downloading an image with the existing Wouxun driver? Even if it doesn't decode the memories properly, you may be able to save the image and attach it here. I can't promise anything, but I could take a look.

You can try using a serial sniffer and sending me a transcript of the communication, but having me develop at a distance may get rather frustrating and error-prone.

Actions #4

Updated by Dan Smith over 12 years ago

This isn't very helpful, but I think that if you (and others) want CHIRP support for the UV6, one path might be to contact the vendor you bought it from and tell them. Wouxun.us has helped in the past with providing equipment for the initial driver to be written. The radio is so cheap that it would be pretty trivial for any of the vendors to spare one, especially if their customers want CHIRP support.

So, something to think about... :)

Actions #5

Updated by David Behar over 12 years ago

For the Wouxun KG-UV6D, the communications protocol and the radio memory map for channel attributes are the same as for the KG-UVD1 (and successors) with the following exceptions:

Memory map - channel attributes (other than label): KG-UVD1 has 128 memory structures of sixteen bytes, starting at 0x0010. KG-UV6D has 199 memory structures of sixteen bytes, starting at 0x0010.

Memory map - channel labels: KG-UVD1 has 128 memory structures of 16 bytes (only first six bytes usable), starting at 0x1010. KG-UV6D has 199 memory structures of sixteen bytes, starting at 0x1010.

Communications protocol: For KG-UVD1, "log in" with the string "HiWOUXUN", followed by 0x02. For KG-UV6D, log in with "HiWXUVD1" -- apparently with no 0x02 following (or at least not necessary).

Channel steps accommodated. For KG-UVD1, frequencies must be a multiple of 5 kHz or a multiple of 6.25 kHz. (I believe the radio will round or round down -- not sure -- if a frequency has been specified which does not meet this requirement.) For KG-UV6D standard models, frequencies must be a multiple of 2.5 kHz or a multiple of 6.25 kHz. (Note that there are models of the KG-UV6D which do not accommodate 2.5 kHz spacing -- rather, they are like the KG-UVD1.)

Feel free to contact me for additional info, or for perhaps some help with testing.

David

Actions #6

Updated by Richard Shaw over 12 years ago

David,

Thanks for the detailed info!

Dan,

Does this take care of your needs? Is there anything I can do to help at this point?

Thanks,
Richard

Actions #7

Updated by Dan Smith over 12 years ago

  • Chirp Version changed from 0.1.12 to 0.2.0

Richard,

Yeah, it might be enough. Are either of you running Linux? It would be much easier to communicate a patch for you to test if so...

Thanks!

Actions #8

Updated by Dan Smith over 12 years ago

Here's a patch against the current tip that will provide the first bit of testing we need. There is another model number the early radios go by (KG669V) which I don't know for the UV6. So, if you can apply and run this patch, it will fail during identification, but will print out the information that I need.

Thanks!

Actions #9

Updated by Stefano Comelli over 12 years ago

Hi, I am a owner of the KG-UV6D, I've applied & tested the patch, I hope the attached file is containing the info you need.
Thank you.

Actions #10

Updated by Dan Smith over 12 years ago

Actually, not, but only because there was a bug in the patch. Sorry about that. I'm attaching a second revision, so if you could apply that and re-test I would appreciate it. This is in place of the previous one, so start with a fresh tree or unapply the previous one first.

Thanks!

Actions #11

Updated by Stefano Comelli over 12 years ago

Ok, second try. I do not know if is it relevant, but my radio is connected to my Ubuntu 11.10 thru USB cable.

Actions #12

Updated by Dan Smith over 12 years ago

Aiee, sorry, another typo in the patch. Attaching r3. It sure is hard to develop by proxy like this, my apologies for the extra work.

Hopefully after you get the output from this patch, I'll be able to post one that actually downloads :)

Actions #13

Updated by Stefano Comelli over 12 years ago

Ok, no problem at all, no need to apoligies, I'm happy to help :-)

Actions #14

Updated by Dan Smith over 12 years ago

Okay, got farther. It doesn't behave exactly like David says, but it is sending back the ASCII ACK character. The attached patch should treat that as success and attempt a download.

After the download, you may or may not see actual data decoded in the memory editor. However, you should be able to save it as a .img and attach here, if the download completes.

Thanks!

Actions #15

Updated by Stefano Comelli over 12 years ago

No download complete yet, still an error.
Now I've to go, see you later...

Actions #16

Updated by David Behar over 12 years ago

Re post #14... If you have a moment, Dan, I would be interested in learning about any errors you (or anyone) has found in information I posted in post #5. Thanks! David

Actions #17

Updated by Richard Shaw over 12 years ago

I applied the patch to my version of chrip (0.1.12) and when I try to start chirp I get the following error:

$ chirpw
Traceback (most recent call last):
File "/usr/bin/chirpw", line 28, in
from chirpui import mainapp, config
File "/usr/lib/python2.7/site-packages/chirpui/mainapp.py", line 35, in
from chirp import platform, xml, csv, directory, ic9x, kenwood_live, idrp, vx7
File "/usr/lib/python2.7/site-packages/chirp/directory.py", line 24, in
from chirp import wouxun
File "/usr/lib/python2.7/site-packages/chirp/wouxun.py", line 336, in
@directory.register
NameError: name 'directory' is not defined

Actions #18

Updated by Dan Smith over 12 years ago

David,

The earlier radios return a model number after the "logon" message. The UV6 seems to be returning just an ASCII ACK byte (0x06). It's not clear yet if that is a "good" thing and if it will allow a download to begin after that.

Richard,

0.1.12 is very old and thus you must apply the patch to a recent version. Preferably a snapshot of the repository (see the developers page on the website) or a very recent daily build.

Actions #19

Updated by Richard Shaw over 12 years ago

Dan,

I'm working on getting an updated version (0.2.0) packaged for Fedora but for some reason it's trying to install everything into /usr/usr instead of one /usr. I'm using the original spec file from the 0.1.12 source RPM which doesn't appear to contain anything strange. I've tried removing the --prefix option but it still does this. Any ideas?

Richard

Actions #20

Updated by Dan Smith over 12 years ago

Richard, lets please not confuse this bug with unrelated issues. Feel free to send me the spec and/or open a different bug for discussion, but lets not do it here.

Actions #21

Updated by Richard Shaw over 12 years ago

Sorry about that. I just want to be able to take whatever modifications you some up with here and get it into Fedora properly when we're done. I patched around the problem and I'll submit it separately. So apparently 0.2.0 isn't new enough either. What's the chances of getting a 0.2.1 release once this is figured out?

Actions #22

Updated by Dan Smith over 12 years ago

0.2.0 should be plenty new enough to use as a patch base for this.

0.2.1 will actually come out fairly soon, but it will only have bug fixes. This is new feature, so it won't go until 0.3.0 under the new versioning scheme, but it will be available in the daily builds as soon as we have something that actually works (as with all other changes).

Actions #23

Updated by Richard Shaw over 12 years ago

Well I initially had a crash in 0.2.0 with the UV6D patch applied but I just tried over SSH/X11 forwarding and it seems to work. Obviously I can't get any output from the radio until I get home from work.

Actions #24

Updated by Richard Shaw over 12 years ago

I got a chance to try a download and here's the results.

Actions #25

Updated by Dan Smith over 12 years ago

Hmm, this was a UV6? It behaves differently than Stefano's apparently, in that it returns a radio model code (like the UV1,2,3 do), although it's not enough to do a download. It appears that when I ask for the first block of data, I get only a few bytes instead of the full block I'm expecting. This is why developing without the hardware in hand is very difficult.

We'll have to wait for David to maybe comment on more differences in the behavior.

Actions #26

Updated by Richard Shaw over 12 years ago

Yes, it's the regular KG-UV6D. Are you sure Stefano's didn't output it as well? I looked at his last attachment and it's identical to mine:

000: 4b 47 36 36 39 56 f8 00 KG669V..

Actions #27

Updated by Richard Shaw over 12 years ago

Dan,

I just wanted to check in and see if there's any more information I can provide.

Actions #28

Updated by David Behar over 12 years ago

Regarding the login protocol, maybe this will be helpful:

000038: Write Request (DOWN), 15.11.2011 13:51:34.326 +0.0
Buffer size: 0x8 bytes
48 69 57 58 55 56 44 31 HiWXUVD1

000041: Read Request (UP), 15.11.2011 13:51:34.326 +0.0
Buffer size: 0x1 bytes
Status: 0x00000000
06 .

000042: Write Request (DOWN), 15.11.2011 13:51:34.326 +0.0
Buffer size: 0x1 bytes
02 .

000045: Read Request (UP), 15.11.2011 13:51:34.342 +0.015
Buffer size: 0x8 bytes
Status: 0x00000000
06 4B 47 36 36 39 56 F8 .KG669Vø

000046: Write Request (DOWN), 15.11.2011 13:51:34.342 +0.0
Buffer size: 0x1 bytes
06 .

000049: Read Request (UP), 15.11.2011 13:51:34.342 +0.0
Buffer size: 0x1 bytes
Status: 0x00000000
06 .

Actions #29

Updated by Filippi Marco over 12 years ago

  • Chirp Version changed from 0.2.0 to 0.2.2

Next monday a friend will lend me a KG-UV6D for a week or two, my plan is to give a big step forward to the support of this model.

@ Dan - please confirm wouxun6_r4.patch is actually the state of the art
@ Stefano - be ready for beta testing ;)
@ all - please update me with any info that can help

Actions #30

Updated by Dan Smith over 12 years ago

  • Assignee set to Filippi Marco
  • Target version set to 0.3.0

Marco,

Yes, that's my latest. However, remember that I never actually tested any of it myself, so it may be completely wrong when you get the radio :)

Thanks very much for doing this!

Actions #31

Updated by Tom Hayward over 12 years ago

  • Status changed from Blocked to In Progress
Actions #33

Updated by Ed Santiago over 12 years ago

Hi. I just (10 minutes ago) received a new KG-UV6X (I don't know how/if it differs from a UV6D). Have tried chirp-0.2.2 and hg e7cbbe3465f1 (2012-05-23). Both crash as follows:

User selected Wouxun KG-UV6D on port /dev/ttyUSB0
Clone thread started
000: 4b 47 36 36 39 56 f8 00   KG669V..

-- Exception: --
Traceback (most recent call last):
  File "/home/esm/src/net/wouxun/chirp/chirp.hg/chirpui/clone.py", line 223, in run
    self.__radio.sync_in()
  File "/home/esm/src/net/wouxun/chirp/chirp.hg/chirp/wouxun.py", line 409, in sync_in
    self._mmap = wouxun6_download(self)
  File "/home/esm/src/net/wouxun/chirp/chirp.hg/chirp/wouxun.py", line 167, in wouxun6_download
    return do_download(radio, 0x0000, 0x2000, 0x0040)
  File "/home/esm/src/net/wouxun/chirp/chirp.hg/chirp/wouxun.py", line 104, in do_download
    len(cmd) + blocksize))
Exception: Failed to read full block (7!=68)
------
Clone failed: Failed to read full block (7!=68)
Clone thread ended
--- Exception Dialog: Failed to read full block (7!=68) ---
None
----------------------------

I'll help any way I can: I'm highly motivated, because I have no access to Windoze (Linux only)... and I can't use my radio, because (this was not clear when I ordered it) it comes from the factory with the keyboard locked. Argh.

Actions #34

Updated by Ed Santiago over 12 years ago

Okay ... got a little farther. I'm able to Alt-D download from radio by making the following changes to the patch:

+    return _wouxun_identify(radio, "HiWXUVD1")
+    return _wouxun_identify(radio, "HiWXUVD1\x02")

(that is, append \x02 just like the other radios. This seems to make the radio respond with KG669V instead of a 1-char response.)

Also need to patch:

+    _model = "KG????"
+    _model = "KG669V"

(that is: the _model string is exactly the same as the other radios).

Unfortunately, I don't see any way for Chirp to unlock my radio.

Actions #35

Updated by Dan Smith over 12 years ago

Marco's patch will probably enable cloning with your radio, if you can stand by for it. He or I can also add support for the keypad lock fairly easily once we see if the patch allows cloning.

Actions #36

Updated by Ed Santiago over 12 years ago

It doesn't seem to be a keypad lock: from the brief note included with the radio, and the symptoms, it appears to be the Menu key that's locked. And I can't find any way to unlock it without their (Windows) software. Will "cloning", whatever that is, allow a way to see that value and change it?

One more data point: I (gulp) was able to make some changes using Chirp, upload to the radio, and I'm now able to transmit/receive on my SAR frequencies.

And, duh, I neglected to mention that my tests above all included the wouxun6_r4 patch (with manual tweaking when applied against hg tip).

Actions #37

Updated by Dan Smith over 12 years ago

Right, we'll just find the bit that restricts the menu key and add a switch in chirp that lets you flip that.

Dunno about the transmit thing. Were you able to do that before? I thought you had no way to program things into it.. maybe you were just in VFO mode? Maybe there's a band split setting somewhere?

Actions #38

Updated by Ed Santiago over 12 years ago

Dan Smith wrote:

Right, we'll just find the bit that restricts the menu key and add a switch in chirp that lets you flip that.

Oh please oh please oh please! :-)

Dunno about the transmit thing. Were you able to do that before? I thought you had no way to program things into it.. maybe you were just in VFO mode? Maybe there's a band split setting somewhere?

Sorry; I haven't communicated clearly. What I meant to say was that I have successfully used Chirp to download from my new radio, program in two local frequencies, and upload them back to the radio. Brief chronology:

  • 1650 UPS delivers radio
  • 1655 I read the prominent "your radio is locked" warning sheet, which indicates that I need Windows to unlock the Menu key
  • 1700 Decide to try Chirp anyway. Eventually get download working, using wouxun6_r4.patch + the edits in comment #34
  • 1830 Decide (gulp) to upload to radio despite risk of bricking. It worked. Menu key is still disabled, and the only thing I can do is switch between frequencies (i.e. I can't disable the annoying voice or use VFO mode), but I can transmit and receive on the frequencies I need for tomorrow's SAR practice. That's good enough for the time being.

I hope that clarifies. My apologies for not being more clear. And my thanks for Chirp and for your prompt replies.

Actions #39

Updated by Dan Smith over 12 years ago

Ah, I thought you said "can't transmit". Well, that's good news. I think we'll see a patch from Marco soon that makes chirp able to program both the old and new models. I'll take a look at the lock thing real quick and see if it's trivial.

Actions #40

Updated by Dan Smith over 12 years ago

Here's a patch. Applied on top of the current tree, it adds a RadioSetting (settings tab on the left, under Memories) that lets me toggle it on my UV2.

Actions #41

Updated by Ed Santiago over 12 years ago

Promising! But it doesn't seem to do anything: I can toggle it, but uploading to radio makes no difference. Menu key still has no effect. It's bedtime over here so I'm done playing for the evening.

Incidentally, I downloaded Marco's first image and diff'ed (using hexdump -C) against the original dump I saved from my unit when it arrived (pristine, untouched). They differ in some possibly-interesting fields, so I'm attaching Wouxun*pristine.img in case it's of use. Again, my model is UV6X instead of 6D.

Thanks again for all your quick work,
Ed

Actions #42

Updated by Dan Smith over 12 years ago

Hrm, yeah, your image doesn't have similar-looking stuff around the bit that my UV2 uses for the lock. Hopefully Marco can confirm that my lock bit patch doesn't work for his UV6, and similarly find where the lock bit is on hi UV6, which hopefully will be the same as yours. I think all the UV6* radios use the same programming software, so I'm sure we'll work it out.

Thanks!

Actions #43

Updated by Filippi Marco over 12 years ago

  • Chirp Version changed from 0.2.2 to daily

Patch has been sent to developer list.

Please test it!!!!

Actions #44

Updated by Filippi Marco over 12 years ago

  • Status changed from In Progress to Closed

Patch in daily build and no bug report

Actions

Also available in: Atom PDF