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