[chirp_devel] Fwd: Wouxun KG-UV8D
Hi Ron,
I looked at the port capture when I got my UV8D-A, and finally just figured out the checksums with the help of your email. Thanks! :)
The model I have is UV8D-A. It may be different than the non 'a' version. This is my ID capture:
000046: Write Request (DOWN), 12.09.2014 21:03:31.235 +0.0 (1. Device: Prolific USB-to-Serial Comm Port (COM3))Buffer size: 0x5 bytes
7D 80 FF 00 7F
}€ÿ.
000049: Read Request (UP), 12.09.2014 21:03:31.240 +0.005 (1. Device: Prolific USB-to-Serial Comm Port (COM3)) Buffer size: 0x30 bytes Status: 0x00000000
7D 80 00 2B 4B 47 2D 55 56 38 44 2D 41 00 01 02 62 5A 00 03 19 74 06 02 62 5A 00 03 19 74 06 00 CC 77 C0 01 0B 06 66 00 CC 77 C0 01 0B 06 66 9E
}€.+KG-UV8D-A... bZ...t..bZ...t.. ÌwÀ...f.ÌwÀ...fž
We may encounter some terminology 'friction', seeing as how you were likely taught proper English across the big pond from where I learned my wronglish. I apologize in advance...
On Sep 11, 2014 8:37 AM, "Ron Wellsted" ron@wellsted.org.uk wrote:
A Gotcha: the first identify packet returns a bad checksum, subsequent attempts return the correct checksum... (well it does on my radio!)
The factory software initially does two consecutive identify reads, with
the only difference being the checksums. I initially suspected the dual VFO nature of the radio, and you have since discovered that the first ID read checksums incorrectly. So, I wouldn't worry about that, just double ID in CHIRP, or don't bother to checksum the ID frame.
Channel memory structure sussed out so far: 0x0900:0x477f channel data 000:199, 0x10 length blocks, FF nulled. 0x4780:0x66bf channel names 000:199, 0x8 length blocks, 00 padded.
My send read request looks like this (and the breakdown): 7d 82 ff 03 09 00 40 cd chan001:004data
7d 82 ff read req 03 count
09 00 mem location 40 bytes requested cd checksum And the reply:
7d 82 00 42 09 00 ... 1d chan001:004 data
7d 82 00 read ack 42 count
09 00 mem location ... data payload
1d checksum When I get around to learning Python, I might be able to make something useful happen in CHIRP.
-Dana ks0rr@reasonablerepairs.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Dana,
Thanks for your message. My radio is also showing up as a KG-UV8D-A (I presume that the KG-UV8D-B will have the update firmware with the 2.5KHz step).
I have put my files up on to the website at http://chirp.danplanet.com/issues/1667
I have included a printout from the factory software of the settings that correspond to the capture files.
It looks like each memory slot is as follows: struct { u32 rx_freq; u32 tx_freq; u16 rx_squelch:2, rx_tone:14; u16 tx_squelch:2, tx_tone:14; u8 flags[4]; } memory[1000];
The rx & tx frequencies are stored as the frequency in Hz/10.
The 2 bit squelch field seems to be: 0 = no tone 1 = DCS 2 = CTCSS 3 = ?? The 14 remaining bits specify which tone/DCS (normal/inverse) to use. For CTCSS this is 10x the tone frequency
The 4 bytes of flags should be the other channel settings such as power, wide/narrow, etc.
On 13/09/14 09:18, Dana wrote:
Hi Ron,
I looked at the port capture when I got my UV8D-A, and finally just figured out the checksums with the help of your email. Thanks! :)
The model I have is UV8D-A. It may be different than the non 'a' version. This is my ID capture:
000046: Write Request (DOWN), 12.09.2014 21:03:31.235 +0.0 (1. Device: Prolific USB-to-Serial Comm Port (COM3)) Buffer size: 0x5 bytes
7D 80 FF 00 7F
}€ÿ.
000049: Read Request (UP), 12.09.2014 21:03:31.240 +0.005 (1. Device: Prolific USB-to-Serial Comm Port (COM3)) Buffer size: 0x30 bytes Status: 0x00000000
7D 80 00 2B 4B 47 2D 55 56 38 44 2D 41 00 01 02 62 5A 00 03 19 74 06 02 62 5A 00 03 19 74 06 00 CC 77 C0 01 0B 06 66 00 CC 77 C0 01 0B 06 66 9E
}€.+KG-UV8D-A... bZ...t..bZ...t.. ÌwÀ...f.ÌwÀ...fž
We may encounter some terminology 'friction', seeing as how you were likely taught proper English across the big pond from where I learned my wronglish. I apologize in advance...
On Sep 11, 2014 8:37 AM, "Ron Wellsted" <ron@wellsted.org.uk mailto:ron@wellsted.org.uk> wrote:
A Gotcha: the first identify packet returns a bad checksum, subsequent attempts return the correct checksum... (well it does on my radio!)
The factory software initially does two consecutive identify reads, with the only difference being the checksums. I initially suspected the dual VFO nature of the radio, and you have since discovered that the first ID read checksums incorrectly. So, I wouldn't worry about that, just double ID in CHIRP, or don't bother to checksum the ID frame.
Channel memory structure sussed out so far: 0x0900:0x477f channel data 000:199, 0x10 length blocks, FF nulled. 0x4780:0x66bf channel names 000:199, 0x8 length blocks, 00 padded.
My send read request looks like this (and the breakdown): 7d 82 ff 03 09 00 40 cd chan001:004data
7d 82 ff read req
03 count
09 00 mem location
40 bytes requested
cd checksum
And the reply:
7d 82 00 42 09 00 ... 1d chan001:004 data
7d 82 00 read ack
42 count
09 00 mem location
... data payload
1d checksum
When I get around to learning Python, I might be able to make something useful happen in CHIRP.
-Dana ks0rr@reasonablerepairs.com mailto:ks0rr@reasonablerepairs.com
- -- Ron Wellsted ron@wellsted.org.uk http://www.wellsted.org.uk Call Sign: M0RNW / Linux Counter No. 202120
participants (2)
-
Dana -
Ron Wellsted