CHIRP

Also, I am willing to "beta test" any software for the KG-UV9D.

i Have a KG-UV9D that i can loan. Would love it on CHIRP.

I'm working on define the comm properties of this radio, but the logs on the issue are #2861 are not from the portmon tool and it's hard to clean it to get a clean comm protocol picture.

Can anyone try to get a download / upload logs with portmon [[[https://technet.microsoft.com/en-us/sysinternals/portmon.aspx]]] and post it here?

Remember portmon work just under 32bit Window OS

This is to get an download/upload script as a starting point to another developer who want to follow the development with a radio.

Cheers.

Tell me what I need to do. I'll help, but I haven't done any of this before.

Hi James,

Users can contribute to the development of new models in various ways, posting logs, testing new drivers and borrowing equipment.

At this stage the logs are fine to determine the comm details, another log will not hurt so here comes the instructions:

Go to Sysinternals at Microsoft and download the portmon tool [[https://technet.microsoft.com/en-us/sysinternals/portmon.aspx
]] into any 32bit Windws PC.

Extract and start portmon, start capture. (magnify glass icon)

Connect interface and cable to you radio, start the default software for it.

Start a download with the default software (reading data) of the radio, you will see activity on portmon; at the end use the save utility of portmon to save the log to a file, name it download.txt

Clear the log in portmon.

Repeat this step but uploading (writing data) the data you just downloaded, in portmon save the log to a file named upload.txt

Post the acquired logs to this thread.

If you don't have a 32 bit machine at hand (portmon only runs on 32bit) download any freeware/try-period serial monitor/sniffer software.

In the last weekend I was playing with the logs of this radios, comparing and testing... it has some similar comm procedures with the KG-UV8D, but have a few differences and the checksum, seems like using a different algorithm; also the data in the read commands has no logic using KG-UV8D paradigm or other simple communications

It seems that this radio's comm procedures will be a tough one to break.

Little progress on this, but more knowledge acquired.

This weekend I build a windows & linux compatible script from the kg-uv8D driver base, and run it against the data you gently provided, but no joy.

Lessons learned:

• The comm protocol is "almost" the same. (there is no logic yet on the address bytes)
• The ident of this radio has not the explicit name of the radio on it.
• The ident has some variations from byte 28 until end.
• The checksum algorithm for this radio is unknown.

This last is the rock on the way, until we manage to know what checksum algorithm are they using we are stuck on this.

I will keep investigating this issue but any help is welcomed.

Cheers from Pavel, CO7WT.

I had confirmed one of my fears: data communication in encoded/encrypted, as Ron Wellsted comment in #1489 about the Wouxun KG-UV950...

Until this issue is resolved (very unlikely without the help of Wouxun itself) this driver development is stuck.

73

Hi all,
I've been using CHIRP for a while but haven't contributed before. I got my hands on a Wouxun KV-UV9D this summer in Europe (I live in Arizona). Assuming I can use the RTDI cable I use for programming my Baofeng UV-82HPs, I'd be happy to help develop the driver. As it is, the radio is great for monitoring ATC, and is overall an excellent unit, but without the ability to program it, I default to using my Baofengs for actual communications.

I've read through the history here and have a basic idea of where things stand, but it's my first time at this. If anyone can help me understand what would be needed to move this process forward I'll do what I can.
73,
-Rafael KG7YWU

Well,
it seems the issue is to find the method with which the checksum of the communication is calculated - which is different to older wouxun models.

I figured out one thing so far:
It seems the upper nibble of the checksum is always identical to the upper nibble of the last databyte.

The lower nibble is even for messages TO the radio, and odd for messages FROM the radio.

That's as far as I got.

Maybe someone else has some ideas .....

update:
my statement on "even" and "odd" seems wrong, so the calculation of the lower nibble is open ....

I don't run Windows – any serial sniffer tools I can use on OS X or Debian?

I found one! http://www.w7ay.net/site/Applications/Serial%20Tools/index.html. Now to figure out how to get some useful data out of it.