CHIRP

The S88G uses a different communication protocol than the other Wouxun radios that are supported by Chirp. To date, the protocol has not been decoded to enable Chirp or other 3rd party programmers to communicate with the S88G radio.

I'm interested in this as well. The stock software is horrendous, and it's a nice little superheterodyne GMRS radio.

It's worth noting for anyone interested, the USB-C charging doesn't seem to be PD and might require USB-A power even though the connector is -C.

Any update ?

Steve Mahler wrote in #note-3:

Any update ?

No change. Protocol still not decoded.

I've done a bit of research and wanted to document my findings thus far.

The radio's serial settings are 9600 8N1. I have no idea why such a low bit rate was chosen; even the venerable Radioddity GM-30 uses 57600 8N1.

Each "read radio" operation goes roughly this way:

1. The handshake's command / response transaction always starts out the same way:

C: 02 52 57 49 54 46 FF FF | R: 06

After this, the radio's physical buttons are locked (presumably to prevent changing the config while it is being read).

1. Then things get a bit wierd. A command / response transaction is sent of the form:

C: A5 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx | R: xx xx xx xx xx xx xx xx xx xx xx xx

For those not wanting to manually count, thats a 16-byte command followed by a 12-byte response.
The command bytes appear randomized following the A5 byte.
The the response bytes appear to have some kind of structure and they do change with the config. Maybe they include a checksum?

1. Next comes an (apparent) ACK from the host followed by yet more random-looking data from the radio:

C: 06 | R: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

That is an 18-byte response which appears to be fully randomized.

1. Next, single ACK bytes are exchanged:

C: 06 | R: 06

and this appears to end the initial handshake.

1. Now comes what appear to be the real data transfers, which take this form:

C: 57 xx xx xx xx | R: 57 aa aa aa aa aa bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb

Thats a 5-byte command and a 21-byte response. There are over 600 of these for a radio that has 400 configurable channels and the responses do appear to have some kind of structure.

1. Finally a single command is sent which does not elicit a response from the radio:

C: 54 | R: <none>

after which the radio reboots. This also clears the keypad lockout.

Some notes:

• Entire recorded serial transactions can be replayed assuming the radio config has not been changed. Command / response bytes do not vary in this case.
• The 'bb' bytes in step 5 are, in many cases, all 00. Likely there is no encryption taking place in this step. Maybe not anywhere? But if so, why the apparent randomness in the initial handshake?

The initial handshake does seem to have a bit less randomness than I initially thought:


1 - C: 02 52 57 49 54 46 FF FF | R: 06
2 - C: A5 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx | R: 50 40 00 47 90 40 00 47 90 xx 00 22
3 - C: 06 | R: xx 06 00 47 90 40 00 47 90 xx xx xx xx xx xx xx xx 00
4 - C: 06 | R: 06


Steps 2 and 3 in particular do appear less random than I initially thought.

To interrupt an unfinished read session, send 57 21 43 25 BA (which will also cause the radio to reboot).

I can also reconfirm the comm parameters: Baud rate=9600, Data bits=8, Stop bits=1, Parity=None. It appears that the radio is DTR/DTS capable as well.

Does anyone know whether there are any existing / supported radios with similar communication patterns?