Creating a driver for KG-805g

Hello,
I'd love some help creating a driver for the Wouxun KG-805g radio ( https://chirpmyradio.com/issues/11214). I've performed captures of all the settings, they can be found here: https://github.com/mildebrandt/kg805g
Looking at the trace files, I'm a little confused about the memory layout. I changed the R-CTC setting from "off" to "67.0" on channels 3, 4, and 13. Here are the differences:
CH03: change is at the 89th position <570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff <570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff50122646501226469e02ffff95ffffff5037264650372646ffffffff95ffffff
CH04: change is at the 121st position <570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff <570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff50372646503726469e02ffff95ffffff
CH13: change is at the 25th position <5700d0405087764650877646ffffffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff <5700d04050877646508776469e02ffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
My uninformed thought would be that I'd see the bytes change in the same position for the same setting on each channel, but they seem to be all over the place.
What does this mean for me trying to lay out the memory? Am I being fooled by the trace output...and it's being recorded out of sequence? I wouldn't think so since the ordering looks to be stable per channel.
I'll describe my setup in case there's something weird there. I have an Intel Macbook Pro with Fedora Linux installed. In Fedora, I have a qemu Windows 10 machine that's running the Wouxun software. I'm running tshark on the Linux side to capture the USB traffic.
Any pointers would be appreciated. I'm pretty far over my head, but hopefully I can help get this radio into chirp. :)
Thanks! -Chris

What program are you using to capture the trace? Wouxun typically encodes the data transfer to and from the radio so using the factory CPS shows the encoded data.
I have done more than 10 wouxun radio drivers and in all of them, the per channel tones are part of the 16 bytes of memory for each channel. In fact they have always been bytes 8 and 9 and bytes 10 and 11.
I would have you take a look at one of the drivers already in existence for clues....the 935G or the 980P drivers would show how a typical memory map is laid out for the recent wouxun radios. If you have images downloaded from chirp for the 805 I can take a look.
There is also the chance that the 805 uses a comm protocol that has not been decoded yet and it can be fooling you. The 916 and the S88 are radios that seem to use a comm protocol that is not as "predictable" as the 935G or the 980p.
Mel
On Sat, Mar 22, 2025, 8:43 PM Chris Mildebrandt via Developers < developers@lists.chirpmyradio.com> wrote:
Hello,
I'd love some help creating a driver for the Wouxun KG-805g radio ( https://chirpmyradio.com/issues/11214). I've performed captures of all the settings, they can be found here: https://github.com/mildebrandt/kg805g
Looking at the trace files, I'm a little confused about the memory layout. I changed the R-CTC setting from "off" to "67.0" on channels 3, 4, and 13. Here are the differences:
CH03: change is at the 89th position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff50122646501226469e02ffff95ffffff5037264650372646ffffffff95ffffff
CH04: change is at the 121st position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff50372646503726469e02ffff95ffffff
CH13: change is at the 25th position
<5700d0405087764650877646ffffffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
<5700d04050877646508776469e02ffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
My uninformed thought would be that I'd see the bytes change in the same position for the same setting on each channel, but they seem to be all over the place.
What does this mean for me trying to lay out the memory? Am I being fooled by the trace output...and it's being recorded out of sequence? I wouldn't think so since the ordering looks to be stable per channel.
I'll describe my setup in case there's something weird there. I have an Intel Macbook Pro with Fedora Linux installed. In Fedora, I have a qemu Windows 10 machine that's running the Wouxun software. I'm running tshark on the Linux side to capture the USB traffic.
Any pointers would be appreciated. I'm pretty far over my head, but hopefully I can help get this radio into chirp. :)
Thanks! -Chris _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com

Thank you for your reply Mel. I'm using tshark to capture the USB traffic. I've adapted the scripts attached to the linux sniffing page https://chirpmyradio.com/projects/chirp/wiki/DevelopersUSB_Sniffing_in_Linux into my own script https://github.com/mildebrandt/kg805g/blob/main/capture that automates the reading of the radio from the Wouxun software.
When looking online https://forums.mygmrs.com/topic/2111-wouxun-kg-805g-programming/ and talking to people around here, they had some success just using the 816 driver for the 805....but some people after a few writes, the radio would get into a weird state. I didn't get the exact details, so we'll have to be content with "weird state". :) They were able to use the official software to get the radio functional again. Looking at the code, the 816 has 199 channels and the 805 has 128 channels....so someone probably wrote channel data into their settings.
I was going to start with the 816 memory layout until I saw this weirdness in the captures I got, and thought I'd reach out.
You mentioned you could look at images downloaded from chirp. Does that entail just reading from chirp using a different driver like the 816 and saving it? FYI, I've actually never used chirp or interacted with radios much....so I'm really diving into the deep end. :)
In the meantime, I'm going to create a new class for the 805 which extends from the KG816Radio class, change the memory to 128 channels, and go from there.
Thanks! -Chris
On Sun, Mar 23, 2025 at 6:53 AM Mel Terechenok via Developers < developers@lists.chirpmyradio.com> wrote:
What program are you using to capture the trace? Wouxun typically encodes the data transfer to and from the radio so using the factory CPS shows the encoded data.
I have done more than 10 wouxun radio drivers and in all of them, the per channel tones are part of the 16 bytes of memory for each channel. In fact they have always been bytes 8 and 9 and bytes 10 and 11.
I would have you take a look at one of the drivers already in existence for clues....the 935G or the 980P drivers would show how a typical memory map is laid out for the recent wouxun radios. If you have images downloaded from chirp for the 805 I can take a look.
There is also the chance that the 805 uses a comm protocol that has not been decoded yet and it can be fooling you. The 916 and the S88 are radios that seem to use a comm protocol that is not as "predictable" as the 935G or the 980p.
Mel
On Sat, Mar 22, 2025, 8:43 PM Chris Mildebrandt via Developers < developers@lists.chirpmyradio.com> wrote:
Hello,
I'd love some help creating a driver for the Wouxun KG-805g radio ( https://chirpmyradio.com/issues/11214). I've performed captures of all the settings, they can be found here: https://github.com/mildebrandt/kg805g
Looking at the trace files, I'm a little confused about the memory layout. I changed the R-CTC setting from "off" to "67.0" on channels 3, 4, and 13. Here are the differences:
CH03: change is at the 89th position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff50122646501226469e02ffff95ffffff5037264650372646ffffffff95ffffff
CH04: change is at the 121st position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff50372646503726469e02ffff95ffffff
CH13: change is at the 25th position
<5700d0405087764650877646ffffffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
<5700d04050877646508776469e02ffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
My uninformed thought would be that I'd see the bytes change in the same position for the same setting on each channel, but they seem to be all over the place.
What does this mean for me trying to lay out the memory? Am I being fooled by the trace output...and it's being recorded out of sequence? I wouldn't think so since the ordering looks to be stable per channel.
I'll describe my setup in case there's something weird there. I have an Intel Macbook Pro with Fedora Linux installed. In Fedora, I have a qemu Windows 10 machine that's running the Wouxun software. I'm running tshark on the Linux side to capture the USB traffic.
Any pointers would be appreciated. I'm pretty far over my head, but hopefully I can help get this radio into chirp. :)
Thanks! -Chris _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com

I studied the USB transfers and I think the 805 is very similar to the existing drivers for wouxun radios.
Here is how I think you need to interpret the data transfers Using your example -- I have broken down the data into pieces The blue is likely the header which likely is the broken down into a start byte (57) the start address (0010) and then the number of bytes to transfer (40hex = 64bytes) then comes the 64 bytes of data . for this example you are starting at address 0010 and getting data for channels 1,2,3,4 Each 16 bytes of the data applies to a single channel broken down as follows Orange ( 4 bytes) = RX Freq Green (4bytes) = Tx Freq Purple (2bytes) = Rx Tone Light Orange (2bytes) = Tx Tone then 4 bytes of channel specific settings.that you will need to decode I think the mistake you are making is that you are assuming each data transfer line is a specific channel when in fact it is simply 64 bytes of data and what is stored in the data is dependent on the memory map location and address being transferred. For this region, each 64 bytes is 4 channels worth of information. I am not sure if this data is encoded or not - Likely not. You could confirm by checking the frequencies stored in the channels
based on this data I think you have the following Ch1 - 50622546 Rx Freq = 462.56250 MHz : little endian representation of the freq*100000 Ch2 - 50872546 Rx Freq = 462.5875 Mhz Ch3 - 50122646 Rx Freq = 462.6125 Mhz Ch4 - 50372646 Rz Freq = 462.6375 Mhz
also for Ch 3 you have 9E02 for the Rx tone which is little endian representation for 029E when converted to dec = 670. So it matches your tone setting of 67 when divided by 10.
If these are the freqs stored in the radio channels then the data transfers are not encrypted and you can accept the bytes as is. You would just need to read the complete memory and store the data in the proper addresses.to build the radio image. Take a look at the 816 driver and see how to do that. I think your captures are showing differences that are exactly as I would expect them to show.
CH03: change is at the 89th position
<57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 5012264650122646ffffffff95ffffff 5037264650372646ffffffff95ffffff <57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 50122646501226469e02ffff95ffffff 5037264650372646ffffffff95ffffff CH04: change is at the 121st position <57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 5012264650122646ffffffff95ffffff 5037264650372646ffffffff95ffffff <57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 5012264650122646ffffffff95ffffff 50372646503726469e02ffff95ffffff
On Sat, Mar 22, 2025 at 8:43 PM Chris Mildebrandt via Developers < developers@lists.chirpmyradio.com> wrote:
Hello,
I'd love some help creating a driver for the Wouxun KG-805g radio ( https://chirpmyradio.com/issues/11214). I've performed captures of all the settings, they can be found here: https://github.com/mildebrandt/kg805g
Looking at the trace files, I'm a little confused about the memory layout. I changed the R-CTC setting from "off" to "67.0" on channels 3, 4, and 13. Here are the differences:
CH03: change is at the 89th position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff50122646501226469e02ffff95ffffff5037264650372646ffffffff95ffffff
CH04: change is at the 121st position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff50372646503726469e02ffff95ffffff
CH13: change is at the 25th position
<5700d0405087764650877646ffffffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
<5700d04050877646508776469e02ffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
My uninformed thought would be that I'd see the bytes change in the same position for the same setting on each channel, but they seem to be all over the place.
What does this mean for me trying to lay out the memory? Am I being fooled by the trace output...and it's being recorded out of sequence? I wouldn't think so since the ordering looks to be stable per channel.
I'll describe my setup in case there's something weird there. I have an Intel Macbook Pro with Fedora Linux installed. In Fedora, I have a qemu Windows 10 machine that's running the Wouxun software. I'm running tshark on the Linux side to capture the USB traffic.
Any pointers would be appreciated. I'm pretty far over my head, but hopefully I can help get this radio into chirp. :)
Thanks! -Chris _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com

Wow, this is so helpful. You're right on the money that my thinking was each line represented a channel. Thank you for pointing out my mistake. I appreciate the color coding, the breaking up of channel data, and the explanation of how the frequencies and tones are represented.
I should have enough to start building out a driver using 816 as a base.
Thank you so much for your help! -Chris
On Sun, Mar 23, 2025 at 10:07 AM Mel Terechenok melvin.terechenok@gmail.com wrote:
I studied the USB transfers and I think the 805 is very similar to the existing drivers for wouxun radios.
Here is how I think you need to interpret the data transfers Using your example -- I have broken down the data into pieces The blue is likely the header which likely is the broken down into a start byte (57) the start address (0010) and then the number of bytes to transfer (40hex = 64bytes) then comes the 64 bytes of data . for this example you are starting at address 0010 and getting data for channels 1,2,3,4 Each 16 bytes of the data applies to a single channel broken down as follows Orange ( 4 bytes) = RX Freq Green (4bytes) = Tx Freq Purple (2bytes) = Rx Tone Light Orange (2bytes) = Tx Tone then 4 bytes of channel specific settings.that you will need to decode I think the mistake you are making is that you are assuming each data transfer line is a specific channel when in fact it is simply 64 bytes of data and what is stored in the data is dependent on the memory map location and address being transferred. For this region, each 64 bytes is 4 channels worth of information. I am not sure if this data is encoded or not - Likely not. You could confirm by checking the frequencies stored in the channels
based on this data I think you have the following Ch1 - 50622546 Rx Freq = 462.56250 MHz : little endian representation of the freq*100000 Ch2 - 50872546 Rx Freq = 462.5875 Mhz Ch3 - 50122646 Rx Freq = 462.6125 Mhz Ch4 - 50372646 Rz Freq = 462.6375 Mhz
also for Ch 3 you have 9E02 for the Rx tone which is little endian representation for 029E when converted to dec = 670. So it matches your tone setting of 67 when divided by 10.
If these are the freqs stored in the radio channels then the data transfers are not encrypted and you can accept the bytes as is. You would just need to read the complete memory and store the data in the proper addresses.to build the radio image. Take a look at the 816 driver and see how to do that. I think your captures are showing differences that are exactly as I would expect them to show.
CH03: change is at the 89th position
<57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 5012264650122646ffffffff95ffffff 5037264650372646ffffffff95ffffff <57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 50122646501226469e02ffff95ffffff 5037264650372646ffffffff95ffffff CH04: change is at the 121st position <57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 5012264650122646ffffffff95ffffff 5037264650372646ffffffff95ffffff <57001040 5062254650622546ffffffff95ffffff 5087254650872546ffffffff95ffffff 5012264650122646ffffffff95ffffff 50372646503726469e02ffff95ffffff
On Sat, Mar 22, 2025 at 8:43 PM Chris Mildebrandt via Developers < developers@lists.chirpmyradio.com> wrote:
Hello,
I'd love some help creating a driver for the Wouxun KG-805g radio ( https://chirpmyradio.com/issues/11214). I've performed captures of all the settings, they can be found here: https://github.com/mildebrandt/kg805g
Looking at the trace files, I'm a little confused about the memory layout. I changed the R-CTC setting from "off" to "67.0" on channels 3, 4, and 13. Here are the differences:
CH03: change is at the 89th position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff50122646501226469e02ffff95ffffff5037264650372646ffffffff95ffffff
CH04: change is at the 121st position
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff5037264650372646ffffffff95ffffff
<570010405062254650622546ffffffff95ffffff5087254650872546ffffffff95ffffff5012264650122646ffffffff95ffffff50372646503726469e02ffff95ffffff
CH13: change is at the 25th position
<5700d0405087764650877646ffffffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
<5700d04050877646508776469e02ffff95cfffff5012774650127746ffffffff95cfffff0050254600502546ffffffff95ffffff0075254600752546ffffffff95ffffff
My uninformed thought would be that I'd see the bytes change in the same position for the same setting on each channel, but they seem to be all over the place.
What does this mean for me trying to lay out the memory? Am I being fooled by the trace output...and it's being recorded out of sequence? I wouldn't think so since the ordering looks to be stable per channel.
I'll describe my setup in case there's something weird there. I have an Intel Macbook Pro with Fedora Linux installed. In Fedora, I have a qemu Windows 10 machine that's running the Wouxun software. I'm running tshark on the Linux side to capture the USB traffic.
Any pointers would be appreciated. I'm pretty far over my head, but hopefully I can help get this radio into chirp. :)
Thanks! -Chris _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com

I should have enough to start building out a driver using 816 as a base.
Please, please, subclass and re-use as much common code as possible. We have way too many drivers in the tree that duplicate another and make a few changes. It sounds from Mel's description that the cloning routines are similar so please refactor existing drivers to support multiple things wherever possible.
Literally every Icom (non-HF) radio uses the same base cloning code, and literally every Icom HF rig uses another base. Some (several?) of the existing wouxun drivers in tree have whole swaths of duplicated cloning code. When we had to convert everything from python 2 to 3 we were re-converting the same code over and over and over again. Please help by DRYing that stuff up :)
Thanks!
--Dan
participants (3)
-
Chris Mildebrandt
-
Dan Smith
-
Mel Terechenok