CHIRP

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.

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.

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... :)

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

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

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

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

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.

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

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.

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?

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).

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.

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.

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..

Dan,

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

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 .

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.

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.

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.

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).

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?

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.

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.

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!