Starting to investigate the GD-77 USB connection

Starting to investigate the GD-77 USB connection

posted in: Ham radio | 2

Like many other hand held radios, the Radioddity GD-77 comes with a programming adaptor cable, which has 2 jack plugs at one end, and appears to have a USB interface in the USB plug end of the cable.

However unlike radios like the Baofeng UV-82, and many others; nothing happens when you initially plug the cable into the PC, unless the other end of the cable is plugged into the GD-77 and its turned on.

Radios like the Baofeng UV-82, have a USB to Serial adaptor built into the USB plug/dongle, however as nothing happened when I plugged the GD-77 cable into the computer, I suspected that perhaps the USB interface was directly handled by the GD-77, and that the plug/dongle did not contain any active electronics, except possibly some buffering or protection circuit.

The plug / appeared to be a sealed unit, so I started to use a junior hacksaw to cut along the side of the plug, and found fairly soon that I was able to lever the 2 halves of the casing apart fairly easily, to reveal a small circuit board inside.

 

 

In hindsight, the casing can probably be opened by levering carefully along the join line, down the side of the plug, using a sharp knife
However, I had not cut too much away and it will be easy to reassemble and glue it closed, without any noticeable damage.

 

Looking at the PCB, my suspicions were confirmed, as the dongle contained even less than I thought it would; it didn’t even contain any buffering or protection circuit.

The next thing I noticed was that the cable to the GD-77, dual jack plug, only had 3 wires, which using the conventional colour coding, would be Positive 5V , USB D- and Ground (0V), but I know that the outer 2 pins of a USB plug are power and ground and the inner 2 are the data pins. So this wiring is all wrong.

Double checking with my volt meter and the official USB plug pinouts, confirmed that the cable to the GD-77 does not conform to the conventional colour codes at all.

In this cable, the red wire is being used for Negative (0V), the white wire is being used for USB D+ and the black wire is being used for USB D- !!!

 

Checking the other end of the cable, which has 2 jack plugs.

  • The USB D- (black) wire, is connected to the tip of the 3.5mm jack plug,
  • The GND (red) wire is connected to the outer of the 2.5mm jack plug, and
  • The USB D+ (white) wire is connected to the middle section of the 2.5mm jack plug.

 

The only logical reason I can think of for this colour scheme, is that the part of the cable with the mounded dual jack plug section, and the wire/cable are a standard item, used in some other device; and that to save costs Radioddity (Tytera) are using an off the shelf cable.

 

The next step was to investigate the USB data that is being sent and received by the GD-77, so while I had the dongle apart, I thought I may as well connect a logic analyser and capture a data transfer, by temporarily soldering some pins onto the PCB, after first scraping back some of the insulation layer on top of the tracks.

 

 

Although I was able to capture a transfer where the PC software, read the 128k “codeplug” data from the GD-77, I didn’t find the data particularly useful even using the protocol analysis feature that comes with the logic analyser;
because the analyser captures things in too much detail and produced a 22Mb file, with lots of redundant data, where the GD-77 kept sending NAK packets back.

I tried to remove the empty NAK packets and also started to remove the packets to which the GD-77 returned NAK, but there were thousands of them and I could see this was not the best way to investigate the USB protocol.

 

I then tried a trial copy of a product called USBlyzer, but it was not able to capture the any detail of the protocol; it only seemed to record the opening and closing of the USB device.
Looking at the USBlyzer website, it has not had any updates since 2016, and also it seems to only handle mainstream protocols.
So it was no use.

 

As another approach, I used WireShark to record when the PC software (aka CPS), reads the “codeplug” file. However attempting to analyse a unknown USB protocol from scratch is very time consuming, so…

 

Changing tack, I looked at the device manager on the PC to see what new USB devices appear when the GD-77 is turned on, and in normal operation it appears as this

 

HID device (vID=0x15a2, pID=0x0073, v=0x0002);

FREESCALE SEMICONDUCTOR INC.; MCU MOUSE DEMO,

 

I also tried the other 2 boot modes on the GD-77, firstly the firmware update mode, where both side buttons are held when while turning on the radio, and also the “DMR ID” upload / download mode, where the blue button on the side, the green menu button and the hash key (on the keypad) need to be held in while turning on the radio; and in all 3 instances, the radio seems to enumerate with the same VID and PID values as a USB HID device, even though the operation when in these modes is completely different e.g. when in “DMR ID” update mode, the CPS (codeplug) PC application is unable to communicate with the radio.

 

The fact that the radio enumerates using a FREESCALE SEMICONDUCTOR INC vendor ID is not that surprising, because the main MCU (processor) used in the GD-77 is the Freescale NXP  MK22FN512VLL12

Doing some research, the same VID / PID combination is listed as the “NXP Kinetis bootloader”, which is a more likely match to the VID/PID number, though whether the GD-77 is using the full Kenetis bootloader seems unlikely, because looking at the PC software which communicates with the GD-77, there are some interesting files;

specifically  STDFU.dll and STTubeDevice30.dll

 

This seems to indicate, that although the code for the Kinetic booloader (or for a Mouse)  has been used, that the high level protocol that is used by the CPS (codeplug transfer software), and the firmware updater, both probably use a version of STM’s DFUse (Device Firmware Update) protocol.

This is even more likely, because another Tytera radio, the MD-380, is also known to use a modified version of STM’s DFU for its USB transfers.

I’ve done some initial tests with the md380-tools created by Travis Goodspeed, but unfortunately the GD-77 does not seem to work in the same way was the MD-380 and those tools don’t seem to work, simply by changing the USB VID/PID from the value used by the MD-380.

I think its likely that Travis’ tools can be modified to partially work on the GD-77, but its too early to say whether they could be made to perform all the functions they do on the MD-380, and specifically whether the same bug exists in the GD-77 firmware which allowed Travis to read the bootloader firmware on the MD-380

 

I now have 2 possible approaches to investigate this protocol, and hope to continue both in the forthcoming weeks and months, and I will publish any results as an update to this blog entry as I find them.

 

2 Responses

  1. Andre
    |

    Nice! Was looking into this myself a bit, but looks like you’re way ahead here 🙂
    The GD-77 software is attrocious and knowing the protocol would allow for writing a nice script that can just upload channels etc. without the “write complete”, “save complete” pop-ups etc 😀

  2. Roger Clark
    |

    Yep. The CPS is terrible

    I now have a lot of docs about the format of the codeplug file and we know that it just sends the raw file to the transceiver, but I’ve not managed to figure out the USB traffic

    I have some WireShark captures if you know how to read them but they didnt make much sense to me 🙁

Leave a Reply