CHIRP

Unless a developer has the exact radio model you have and/or is willing to spend time on it, I dont think there is much that can be done. Your radio may look like a Wouxun KG-UVD1P, but it clearly does not identify/communicate the same as a genuine UVD1P based on your report. To be able to support your radio with a driver, a developer would have to work with and test with the model radio you have to confirm proper operation without breaking support for true UVD1P radios.

Also, just because Wouxun CPS reads the channel memory correctly, it does not mean it can read and decode the other radio settings correctly. Most Wouxun radios use very similar data storage for channel memories....however the other radio settings can vary greatly radio to radio even between radios in the same family like the 8H, 935G and 935G+, or the 950P, 980P, 1000G and 1000G+. For the same settings, these radios use different encoding methods to get the correct value. On top of that, the Wouxun CPS rarely confirms the model of radio connected matches the radio CPS version. Meaning, the 980P CPS Sw will talk to the 1000G or 1000G+ or 950P but will not set all settings correctly.

Dear Mel, I thank you for your time to study and comment on my issue. I agree/ do not object/ take on board your comments here and on Facebook

• The current driver would work well with the version of Wouxun KG-UVD1P that it was tested on, maybe a decade ago
• There might have been minute changes in handshake protocol and radio identification over the years, these would be non documented. There are reports on CHIRP and elsewhere with same errors that I got earlier and that makes we feel they have the same model as I do.

https://chirp.danplanet.com/issues/10230
https://chirp.danplanet.com/issues/5503
https://chirp.danplanet.com/issues/6419

Since Wouxun official software worked perfectly in every way, I am now convinced that my "KENWOOD TK-UV3" is some version of Wouxun KG-UVD1P with no firmware change. Only the sticker on the HT and the design on the box was changed.

I downloaded a USB SERIAL SNIFFER and peeped into :
Traffic when Wouxun KG-UVD1P software from their web site interacts with my "KENWOOD TK-UV3"
Traffic when CHIRP interacts with my "KENWOOD TK-UV3" using the Wouxun KG-UVD1P driver

I chanced upon some documentation of protocols and data map of Wouxun KG-UVD1P driver on OWX at http://owx.chmurka.net/
(Handshake protocol is described in protocol.txt which is hidden on the zipped file on that site)

and https://web.archive.org/web/20160614064436/http://www.baseciq.org/tools/wouxunmemmap

and I realized that the version of Wouxun KG-UVD1P that they described seems to match the one in my hands. I checked the code in wouxun.py and could then understand why my HT and why some other original Wouxun KG-UVD1P reported the errors that I too had received.

I then manually rewrote (hardcoded) the initial handshake routines as follows:

    def _identify(self):
        """Do the original wouxun identification dance"""
        #Vivek manually rewrote the initial identification routine
        # sometimes when there is an error and 0 length string is returned, unplug/plug cable at USB end helps
        self.pipe.write(b"HiWOUXUN\x02")
        resp = self.pipe.read(9)
        """ Radio should have replied with a \x06"""
        self.pipe.write(b"\x02")
        resp = self.pipe.read(9)
        """ Radio should have replied with a \x06 KG669V \xF8 """

        if resp[1:7] != b"KG669V":
                raise Exception("I can't talk to this model (%s) %s" %
                                ( resp[1:7], util.hexprint(resp)))


    def _start_transfer(self):
        """Tell the radio to go into transfer mode"""
        self.pipe.write(b"\x06")
        time.sleep(0.05)
        ack = self.pipe.read(1)
        if ack != b"\x06":
            raise Exception("Radio refused transfer mode")

The previous initial handshake errors vanished after these mods. I could download from the radio and see the channel data on CHIRP. I'm still not confident enough to write from CHIRP to my "KENWOOD TK-UV3"

What's still missing is:

Proper handling of initial conditions for VFO A and VFO B
Ability to show and mod frequency ranges
There is some error in calculating Offset

I will study the data map as shown on OWX site and as implied by the serial data traffic when the original Wouxun software interacts with the "KENWOOD TK-UV3".

But help would be more than welcome. Its been 30 years since I was actively involved in assembler, coding, debugging of imbedded systems, POS communications, Gas station pump communications etc

PS: It would help if I could law my hands on an authentic img file created by the version of Wouxun KG-UVD1P that works seamlessly with CHIRP. Thanks !

Dear Mel, I thank you for your time to study and comment on my issue. I agree/ do not object/ take on board your comments here and on Facebook

• The current driver would work well with the version of Wouxun KG-UVD1P that it was tested on, maybe a decade ago
• There might have been minute changes in handshake protocol and radio identification over the years, these would be non documented. There are reports on CHIRP and elsewhere with same errors that I got earlier and that makes we feel they have the same model as I do.

https://chirp.danplanet.com/issues/10230
https://chirp.danplanet.com/issues/5503
https://chirp.danplanet.com/issues/6419

Since Wouxun official software worked perfectly in every way, I am now convinced that my "KENWOOD TK-UV3" is some version of Wouxun KG-UVD1P with no firmware change. Only the sticker on the HT and the design on the box was changed.

I downloaded a USB SERIAL SNIFFER and peeped into :
Traffic when Wouxun KG-UVD1P software from their web site interacts with my "KENWOOD TK-UV3"
Traffic when CHIRP interacts with my "KENWOOD TK-UV3" using the Wouxun KG-UVD1P driver

I chanced upon some documentation of protocols and data map of Wouxun KG-UVD1P driver on OWX at http://owx.chmurka.net/
(Handshake protocol is described in protocol.txt which is hidden on the zipped file on that site)

and https://web.archive.org/web/20160614064436/http://www.baseciq.org/tools/wouxunmemmap

and I realized that the version of Wouxun KG-UVD1P that they described seems to match the one in my hands. I checked the code in wouxun.py and could then understand why my HT and why some other original Wouxun KG-UVD1P reported the errors that I too had received.

I then manually rewrote (hardcoded) the initial handshake routines as follows:

    def _identify(self):
        """Do the original wouxun identification dance"""
        #Vivek manually rewrote the initial identification routine
        # sometimes when there is an error and 0 length string is returned, unplug/plug cable at USB end helps
        self.pipe.write(b"HiWOUXUN\x02")
        resp = self.pipe.read(9)
        """ Radio should have replied with a \x06"""
        self.pipe.write(b"\x02")
        resp = self.pipe.read(9)
        """ Radio should have replied with a \x06 KG669V \xF8 """

        if resp[1:7] != b"KG669V":
                raise Exception("I can't talk to this model (%s) %s" %
                                ( resp[1:7], util.hexprint(resp)))


    def _start_transfer(self):
        """Tell the radio to go into transfer mode"""
        self.pipe.write(b"\x06")
        time.sleep(0.05)
        ack = self.pipe.read(1)
        if ack != b"\x06":
            raise Exception("Radio refused transfer mode")


rf.memory_bounds = (1, 130) # was 1,128

The previous initial handshake errors vanished after these mods. I could download from the radio and see the channel data on CHIRP. I'm still not confident enough to write from CHIRP to my "KENWOOD TK-UV3"

What's still missing is:

Proper handling of initial conditions for VFO A and VFO B
Ability to show and mod frequency ranges
There is some error in calculating Offset

I will study the data map as shown on OWX site and as implied by the serial data traffic when the original Wouxun software interacts with the "KENWOOD TK-UV3".

But help would be more than welcome. It's been 30 years since I was actively involved in assembler, coding, debugging of imbedded systems, POS communications, Gas station pump communications etc

PS: It would help if I could lay my hands on an authentic img file created by the version of Wouxun KG-UVD1P that works seamlessly with CHIRP. Thanks!

The Wouxun KG-UVD1P handshake protocol "protocol.txt" file I found at OWX site http://owx.chmurka.net/ (inside the zipped file on that site)

This matched the traffic I saw when Original Wouxun software read my "KENWOOD TK-UV3"

/* $Id$ */

Wouxun protocol information.

File written by SP5GOF using information reverse-engineered by SQ5LWN.

Communication parameters are 9600 8n1, with flow control disabled.

After you connect, you must send: "HiWOUXUN" (without quotes and null) 
and 0x02. Radio will acknowledge by sending back: 0x06. After that you 
send 0x02, radio acknowledges with 0x06 and sends back it's ID string 
(6 bytes, "KG669V") and 0xF8. We're not sure what 0xF8 means - maybe 
some kind of software revision or similar?

After this handshake you can download (read) and upload (write) memory 
pages by sending 4-byte commands:

1 byte: command
2 bytes: address (little endian)
1 byte: size

For reading, use command 'R' and size 0x40. For writing, use command 'W' 
and size 0x10. After write command send 16 (0x10) bytes in raw binary.

After you send write command, radio will acknowledge it with ACK byte 
(0x06).

After you send read command, radio will acknowledge it by re-sending your 
command string back to you with command reversed, so 'R' becomes 'W'. 
After this 64 (0x40) bytes of raw binary data will follow. After receiving 
you must send ACK (0x06) byte and radio will reply with 0x06 byte.

Wouxun memory map can be found on SQ5LWN page:
http://www.baseciq.org/tools/wouxunmemmap

Original URL is dead so we rely on archive.org
https://web.archive.org/web/20160614064436/http://www.baseciq.org/tools/wouxunmemmap