In my quest to improve the GD-77 CPS, I have been investigating the way the CPS and also how ActiveClient (which manages the DMR-ID system) communicates with the GD-77 and I have found that that both programs use identical protocols.
Radioddity seem to have invented their own, very simple protocol for reading and writing the codeplug and DMR-ID data.
The comm’s consist of an initial setup (wakeup) phase, where the GD-77 sends back its model number
Note. Values are in hex, and the text in brackets are the ASCII characters if in the range 0-9 A-Z
SendData 0250524F475241 (PROGRA)
ReceiveData 41...
SendData 4D02 (M)
ReceiveData 4D442D37363050FF563330360004800400 (MD-760PÿV306..€.)
SendData 41
ReceiveData 41
The CPS then sends a request (command 0x52, the letter ‘R’) for address 0x0100 for 8 bytes long
SendData,52010008
and the GD-77 sends back an echo of the command and then the flash memory for that address, which in my case is 0xFFFFFFFFFFFFFFFF
ReceiveData 52010008FFFFFFFFFFFFFFFF
The CPS then ends the current communication by sending and the GD responds with 0x41 which seems to be the equivalent of OK or ACK
SendData 454E4452 (ENDR)
ReceiveData 41
For a codeplug Read, the CPS then starts the whole process again e.g. sends
SendData 0250524F475241 (PROGRA)
etc
And then starts requesting individual blocks of codeplug data e.g.
SendData 52380020
ReceiveData 52 380020564B33524D4E204132FFFFFFFFFFFFFF005068140050621400000000FF005
The eagle eyed among you may have noticed something missing from this protocol…
The address is limited to 2 bytes, which would give a maximum address range of 64k, but the codeplug is 128k.
I found the answer to this, is that the protocol has a command to set an Offset address.
To do this the CPS sends the text
CWB followed by a 32 bit offset
e.g. to access the upper 64k of the codeplug, the CPS sends
CWB
00010000
The GD-77 responds with 0x41
Taking a closer look at the CPS, I also found that it does not read all 128k of he codeplug.
It does not seem to read the first 128 bytes, and there are also other sections of the GD-77 codeplug storage which it may not be reading.
The CPS seems to make separate requests to read each of the parts of the codeplug, e.g. Channels, Zones, Contacts etc, and keeps reading until it receives empty data (containing 0xFF bytes)
I think it does this to speed up the download, as its surprisingly slow – and something else I will investigate if I have time…
As the GD-77 contains a 1Mb SPI Flash memory chip on its PCB, and the main processor Flash memory size is only as large as the firmware file, its safe to say that the codeplug and DMR-ID and other information is stored in that chip.
In fact, Jason VK7ZJA has connected a STM32F103 running Arduino and a Flash reader to the Flash chip on his (broken) GD77S and has read out its data and confirmed that at least on the GD-77S that the codeplug is stored in there.
Anyway, as the external Flash storage is 1Mb, I wrote a utility / test function inside the CPS for me to read the entire 1Mb flash via the CPS and save it to a file.
But the results were somewhat disappointing, as only the lower 128k range seemed to contain any data 
As a further experiment, I put the GD-77 into DMR-ID mode (hold down button2, Green Menu button and Hash key while turning on…)
And this did yield some interesting data…
In this mode, the DMR-ID data can be read from address 0x00030000 to 0x0004FFFF, but in this mode the codeplug address range of 0x00000000 to 0x0001FFFF just contained zeros (0x00), so the GD-77 firmware imposes strict limits on the CPS / DMR-ID communications depending on which mode the GD-77 is booted into.
This is a shame, as it would have been good if the CPS could have read and written the DMR-ID data without having to hold down that stupid key sequence.
It would be possible, to integrate the DMR-ID feature, into the CPS, to replace ActiveClient.exe, but after the user would still need to do the button pressing on the GD-77
And… As DMR-MARC have posted that they are removing the option to download a datadump csv a completely new system would need to be written to handle this aspect of the GD-77, and at the moment I don’t have time to do this.
One final experiment I did was to cause the GD-77 to do a factory reset, when running firmware 3.0.6 and I downloaded the codeplug data, and then I installed firmware 2.6.6 and downloaded the whole (128k) codeplug again, and finally upgraded back to 3.0.6 again and downloaded the whole codeplug data
This showed some interesting things..
Firmware 3.0.6 makes a real mess of the codeplug data, when it applies its factory settings, it seems to fill parts of the data with random patterns of bytes, which may be part of the device’s firmware or perhaps just other parts of the external Flash memory, and the data at the beginning of the codeplug seems to be pushed up a bit, like there is an address offset missmatch.
I’m still investigating these downloads, so watch this space as I hope to post my findings in a subsequent article.