[chirp_devel] Fwd: Wouxun KG-UV8D

[Ron Wellsted]

-----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 at wellsted.org.uk 
> <mailto:ron at 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 at reasonablerepairs.com
> <mailto:ks0rr at reasonablerepairs.com>



- -- 
Ron Wellsted
ron at wellsted.org.uk http://www.wellsted.org.uk
Call Sign: M0RNW / Linux Counter No. 202120
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJUFGbcAAoJEEtP/KMNOfRbGu8H/iXk4tFyEueCXhI5Zf6qgr4z
TD6HpMk0iT2GgDsJaXgH+LofE0IMLC4mkKJhiDvQLgdAdGIJdvSfI6KFNqJfb8Af
wMM+A9dpiRp55KBVYJSIrdpLa1cwRHRoJQ+z30EgCP7E82IXzXpH+9nurgWgfJhr
/ucu/Nh0I3KK3B/CRst9u253UbxKg3RZTx/hBNfHE7gEx1c/nSuKtN4vi8lz6U5e
Rr//k8Zc1ne4cPlAVXINrm8m4rLevMH1oEOVjMAMvUd+gc8K8SiTgDQj9N43mLOW
T208iSrVYRW1WTTKCLe0/lNHgBU0A54+WogbYPPbJ99qyqPZ2vysLbf9sVFxBqk=
=jCBC
-----END PGP SIGNATURE-----