Tony VK3CAT recently alerted me to a bug he found when using the GD-77 in VFO mode on DMR

The bug manifests itself if you change the frequency band that the VFO is using. The bug does not seem to happen absolutely all the time, but seems to be fairly easy to reproduce.

To see the bug, you just have to change the “band” that the VFO is using.

e.g.  if you have the VFO set to 439.200 and it was working OK, for both Tx and Rx, and then you enter the frequency of 144.800….

The GD-77 seems to stop transmitting audio.

The green LED on my receiving radio was illuminated when there is an incoming signal, and the display shows the DMR ID number and TG of the transmission, but there is no audio whatsoever.

Enabling the monitor mode does not seem to make any difference, nor does manually changing the Timeslot or the Color Code using the Set->Radio config menu

Tony reported if he power cycled the GD-77, that the problem was resolved, but this didn’t seem to fix it for me.

The only thing that seemed to work for me, was to go into the Radio Config menu, and set the channel type to FM, and then set it back to DMR.

Update.

I initially thought this was a Rx bug, but Jason VK7ZJA has done some testing and confirmed it a Tx audio bug, where the audio part of the data transmission appears to be empty.

Jason reported a workaround for the problem is to switch to memory mode and then back to VFO mode, but I’ve not confirmed whether it makes any difference if the memory is on the same band as the VFO.

Radioddity released a new version of the GD-77 firmware yesterday (31st Jan 2019)

This appears to be a firmware only change, and the CPS does not appear to be updated, and I expect the Community CPS will probably work OK with this firmware version.

However… There are only 2 changes listed in the “Update diary”

1. Lock frequency range to meet FCC rules
2. Solved GD-77 (INVERTED DISPLAY VERSION) screen flashing when turned on

And apart from those of you with a Inverted Display version of the GD-77 which has a black background with white text, there are no bug fixes in this release.

In fact this version removes some functionality (frequency range limiting) in order to comply with USA FCC certification.

I don’t have details of what limits have been placed on the operational frequencies, – I’m sure someone will be able to comment on this.

But since this version does not contain any bug fixes or enhancements for my GD-77, as its a normal non-inverted screen, I will not be installing it.

What is quite amusing, is that although this change has been made to comply with FCC regulations for hardware entering the USA, the Update Diary lists 2 methods to unlock the frequency range

 

Note: Two ways to unlock frequency range
I. Press “SK1” + “7” key to turn on the radio – Press “Menu” to select frequency range (after the selection, the radio will automatically restart)
II. Downgrade to old firmware version

However early reports that I have receive, seem to indicate there is a bug in the SK1 + 7 key method to unlock the frequency range, and that people had to downgrade back to 3.1.8 to reinstate the original operation.

I wonder whether by providing a way for users to immediately change their hardware to no longer comply with FCC regulations, will be judged by the FCC.

I remember reading the FCC directive ,when it was originally published, and I vaguely recall some language in the directive that seemed to indicate that that the radios should be designed in some way, that would make it impossible to transmit outside the authorised frequency range.
However this has always struck me as unworkable in practice, since radios like the MD-380 already have unlocked modified firmware which can be downloaded from the web, which let you do anything you like with the radio, and I have modified other radios (UV-82) and replaced the internal microprocessor with a different chip (STM32) which I can then load my own custom firmware, allowing full control of the RF hardware.

For anyone who wants to try the new firmware its available from Radioddity’s downloads page, and I have also archived into onto github

https://github.com/rogerclarkmelbourne/Radioddity_GD-77/tree/master/firmware

I’ve been experimenting with various ways to display information on my PiStar based hotspot, including the small OLED displays.

I found the the OLED is to far to small, so I splashed out and bought what I thought was an official Nextion 2.4 inch display, from a eBay vendor.

I was aware that there are clones of the Nextion, which don’t work with the official Nextion editor and don’t accept data files produced by the official Nextion editor.

But I specifically ordered a board which looked like a Nextion made by Itead and had a Nextion part number (beginning with NX)

The photo on the product I ordered looked like this.

When the display arrived, I noticed that the PCB did not match the photo in the eBay listing, but it did have the correct model number and also had what looked like the Nextion logo.

Clearly the board is completely different, despite seeming to have identical model numbers.

I became suspicious about whether this board was an authentic Nextion,  when I was unable to upload the “TFT” configuration files via SD card.

The upload always stopped whilst displaying “SD Card Update…..” rather than going on to copy the graphics and configuration data from the SD card.

Assuming there was something wrong with the “TFT” file I got from the web, tried connecting the display via a USB to serial converter to my PC,  and I managed to use the official Nextion editor to upload a set of screens I downloaded from the MMDVM github account (G4KLX)

The display then seemed to work OK with PiStar, but I thought I’d try a different screen layout, and this is when the problems started …

When I tried to upload the new layout using the Nextion editor and the USB to serial adaptor, I found that the Nextion editor would no longer connect to the display.

However, when I reconnected it to Pi Star, I found it was still working.

Not to be deterred, I thought I’d try to upload via SD card again, and after trying various micro SD cards, I eventually found an old 4Gb card, which was probably 4 years old, which was recognised by the display, and I was able to upload a different layout.

After removing the SD card and removing and reconnecting the 5v input to the Nextion, the new layout worked OK, but unfortunately this was the last time I was able to use the display.

Because I thought I’d try another different screen layout, and after uploading that layout using the micro SD card, when I removed the SD card and removed and reconnected the 5v input to the “Nextion”, I found it was no longer receiving any data from PiStar.

Just in case something had happened to my hotspot board, I connected the USB serial adaptor to the Nextion output on the hotspot and used a terminal program on the PC to confirm that the hotspot was still sending serial data to the display.

Currently I have no idea whether this board was an official Nextion or not. I didn’t buy it direct from ITead (my mistake), and instead bought it from an eBay vendor in China, via eBay, because the vendor offered free shipping.

The vendor claims it is an authentic Nextion, but offered $4 compensation, which I rejected because I’d rather give negative feedback on eBay and warn other potential buyers that these boards may not be genuine.

My advice to anyone who is thinking about attaching a Nextion to their PiStar hotspot, is to buy direct from ITead, even though its likely to cost $10 more (about 30% more) than from third party vendors, because you are guaranteed to get a genuine board, and are also likely to get support from ITead if you end up having the sorts of problems I’ve had.

Even if my board was not genuine, I still don’t understand why it failed.

What appears to have happened is that initially the serial Tx line probably stopped working, hence the Nextion editor would not connect to the display, but the display still seemed to work when I connected it to my hotspot, since PiStar only sends data to the display and does not expect a response from the display

Subsequently, I think the Rx line into the display probably also failed.

I’ve used STM32 microcontrollers a lot, and I’ve never had a problem before with the serial Tx and Rx lines, even if I connect them the wrong way around. So I find it surprising that the serial lines on this STM32F030 have failed one after the other.

I did not disconnect the serial Tx and Rx lines from the hotspot, when I removed and reconnected the 5v input wire, to the display, when I was uploading via micro SD card, but again I have never had a problem with other STM32’s with leaving input signals connected when the MCU is not being powered.

However perhaps the STM32F030 used on these nextion’s is not very robust, and leaving the serial wires connected when I power cycled the display was enough to damage them.

Now that I’m left with a “bricked” display, I’m going to try to connect to the 5 pads on the back of the PCB, which I presume are the SWD debugger / programmer connections, but I’m going to need to work out which pads are which connections, because the Nextion is not open source and there is no documentation about what these pads are connected to.

Hopefully I’ll be able to use the screen for something, but for the moment its going into my junk box

There is some great news for GD-77 owners…

Kai, DG4KLU has managed to crack the Radioddity GD-77 firmware encryption system, and has published his work on github.

https://github.com/talentraspel/GD-77

This includes unencrypted copies of all the firmware versions, which Radioddity has released for the GD-77, as well as tools to decrypt and encrypt, and some documentation.

In the short term, this will not make any difference to most GD-77 owners, as this is just another step in the very long road.

However in the longer term, this may allow the community to fix some of the long list of bugs, which Radioddity has been unable or unwilling to fix.

It may also allow some enhancements to the GD-77, similar to those available on the MD-380 , when using MD380-Toolz.

However, the GD-77 hardware is quite different to the MD-380, and has much smaller memory capacity, so its unlikely that its going to be able to hold the entire DMR ID database, like the MD-380 can.

I have know about Kai’s work for about a week prior to him publishing the files etc, but at Kai’s request, I’ve not disclosed anything.

Please also note, that Kai’s work is very experimental, and people use his files and tools at their own risk.

For example.

I took one of my GD-77 radio’s apart and have connected a hardware debugger to the PC and have erased the main CPU, however at the moment, neither Kai or I has been able to re-install the firmware onto a blank radio, because of hardware lock features in the firmware.

Using Kai’s tools to create new SGL firmware files is a bit less risky, but still carries a risk, so at the moment I’d only recommend that people experiment with this, if they are willing to sacrifice their radio

If anyone has software development experience, especially on Microcontrollers, who thinks they can help with this, please leave a comment or contact me directly.

Update.

I’ve managed to unbrick my GD-77, using Kai’s CPU ID key encoder tool.

The problem was the CPU ID I read from the MK22 MCU, using JLink Commander, was in Big-Endian format, but Kai’s data file requires the 32 bit chunks to be in Little-Endian format.

Strangely his unique CPU ID and my CPU-ID have 4 bytes with the same value. 2 of these are zero’s so are probably not relevant, but 2 of the bytes in the middle of the 16 byte ID number were also identical, which makes me think that the CPU ID is not as unique as it should be.

I double checked the Reference Manual document for the MK22FN512 processor and as far as I can see, there is no reason those 2 bytes should be the same.

So there is probably a bug in Freescale’s random ID generator

Anyway. This means I am free to experiment with the firmware and can upload using JLink or other programmers, and don’t need to worry about breaking the radio… Except perhaps if I do something nasty to the EEPROM data, since I don’t have a copy of that.

(And I’ll backup the Flash using FlashManager (again), just to be safe.

Since my last post, I have been trying to get to grips with the decrypted GD-77 firmware

One of the first things I did, was take the back off my GD-77 and solder wires onto the hardware debugger pads

The connections are Vcc,Gnd, SWCLK, SWDIO and reset. The wires are held in place using hot glue to act as strain relief, otherwise its likely that force from the wire could pull the pads off the PCB

Here is the full photo

I connected this to a STM32 based hardware debugger, and took the bull by the horns, and did a full chip erase on the CPU (MK22 Microcontroller).

A full chip erase was necessary because the MK22 MCU is read protected to prevent the firmware being read out via the debug port, and the only way to do anything with the MK22 once its read protected is to completely erase the chip.

The next step was to reload the whole MCU with the program data dump taken from Kai’s GD-77, but I found after programming the MK22 that my GD-77 was not working, and it seemed to be constantly rebooting.

Fortunately by the time I’d tried Kai’s firmware, Kai had worked out that the firmware dump from his radio would not run on any other GD-77’s because the firmware contains a hardware lock feature.

Both the bootloader and the main application check the unique ID number in the MK22 MCU (which is assigned during manufacturing of the IC), and if this does not match a “key” in the firmware, which is specific to each GD-77 (MK22), the GD-77 just reboots about once per second.

Fortunately Kai was able to track down where the “key” was stored in his firmware dump file, and was able to write a tool that allowed a new key to be generated for my GD-77.

To do this I had to read the CPU ID (16 bytes) using the hardware debugger, and use a utility written my Kai to generate 2 sets of keys (32 bytes), which are specific to my CPU ID

These “key” bytes then needed to be copied into Kai’s firmware dump, so that it would work in my GD-77.

Having a hardware lock in the firmware is actually completely pointless, and I’m not sure why Radioddity bothered to include it, because anyone with access to an unencrypted copy of the firmware, and enough programming knowledge, could find where the hardware lock code was located, and remove it from both the bootloader and the main application.

But the most expedient fix to get my GD-77 working again, was to install the “key”.

Having the correct key installed, also allows me to still upload any previous version of the firmware using the Radioddity firmware updater program, since the “key” value is not overwritten by the Radioddity firmware updater when it uploads an update.

Up to this point, I didn’t have the front panel on the GD-77, so I was unable to press any keypad buttons or see what was on the display. So I decided to cut a hole in the side of the front panel and start to install a socket, so I could connect to the hardware debugging pins.

I had hoped to be able to fit the socket completely inside the GD-77, but there wasn’t enough space between the back of the main PCB, and the PCB of the front panel keypad and display.

So my current plan is to glue the socket on the outside and just have the pins protruding inside the case.

However, I have not got that far yet, because I found small problems with the GD-77 after i refitted the front.

Firstly, I’d got some plastic dust on the inside of the display, which in the long term I will need to remove,

and secondly the RF connector seems to be slightly miss aligned and I was unable to fully refit the retaining nut.

I’m not sure why the RF connector is miss aligned, but I did remove and refit it, when I initially removed the main PCB from the back of the radio, only to find that it was not necessary to do this, since the hardware debugging connections were on the side of the PCB which is immediately accessible.

I had to unsolder the connector to remove it, and I think somehow, I have not refitted it correctly, despite it being secured by 2 small bolts.

Currently I have just threaded the hardware debuging wires, out though the hole, and connected them to the external hardware debugger.

One problem with this, is that because the Vcc and Reset wires are not connected to anything, they act as mini antennas, and the RF generated when transmitting, can cause the MK22 to reset.

In an effort to prevent this problem, I’ve temporarily turned down the PA power settings, by updating the calibration table in the GD-77’s external Flash memory. But in the longer term, I think I will need to decouple the ends of the wires. Or possibly just pull the Reset pin high, via a 10k resistor, and the other SWD pins with appropriate resistors to whatever supply is required.

One thing I have also noticed, is that the GD-77 should not have power applied to the Vcc pin on the debugging connections.

This is because the MK22 MCU seems to have its voltage supply controlled by some other IC, so that when the volume control is turned to the off position, the MK22 reads the ON/OFF switch and runs some shutdown code, before triggering its own power to be cut off.

Supplying power to the Vcc would feed voltage to the output of the power control circuit, which could potentially damage it.

Over the weekend I started to explore the internal data inside the MK22 when it was running, but I’ll write a separate post about this.

Now that I have a hardware debugger connected to my GD-77, and the processor is not read protected, I’ve been able to take some snapshots of the 128k internal RAM memory in the GD-77 by while the firmware was paused.

To make the files easy for anyone to read, I’ve exported the raw data, using the Hxd hex editor program, using its Editor View

These first 2 files, are where its in channel mode, and I’m changing from a channel on talk group 505 to a channel with the same frequency, but on talkgroup 3801

gd77_Channel_shs_5050_2_TG505_43912500_RAM

gd77_Channel_shs_5050_2_TG3801_43912500_RAM

The next to were both on the same channel,  but with and without monitor mode

gd-77_RAM_tg505_monitor

gd-77_RAM_tg505_normal

I had hoped to be able to spot which memory location holds the monitor mode flag, but the problem is that just turning on or off monitor mode, changes the display (briefly) and plays a beep sound, so that a lot of the memory is changed, not just the variable that contains the monitor mode setting. Hence I’ve not been able to find the monitor mode variable using this method.

Last, I took some snapshots of the RAM with the GD-77 in VFO mode, where I changed the frequency between each snapshot.

The frequency in the first snapshot was 439.125MHz and in the second one its 439.1375 Mhz

I think it should be possible to find where the current frequency is being stored, but I’ve not had chance to investigate this as yet.

gd77_VFO_TG99_43912500_RAM

gd77_VFO_TG99_43913750_RAM

Having a general look at the memory snapshots, there are some things to note.

1. I prefilled the RAM with 0xDEADBEEF, so any areas that still contain this pattern, do not seem to be used by the official firmware, and hence can hopefully be used for enhancements
2. A lot of RAM is filled with the word “kats” (over and over again). I don’t know why kats is used, but its 4 bytes long, which is a good size to use for a 32 bit processor as most variables and pointers will be 32 bits (4 bytes long).
   I suspect perhaps “kats” is the Chinese equivalent of DEAFBEEF but I’m not sure.
   I think that this pattern is used to somehow reserve memory, but again, I’m not sure how or why.
3. The RAM seems to contain what appears to be a history of some channels which I selected in the radio a few days ago. These are analog channels and not part of the Zone which I had selected for all the tests.
   I will need to look in the external flash, and also the EEPROM, because the RAM is volatile and would not have retained this information.
4. There appears to be other things in memory which I didn’t expect to me there, like what appears to be bitmap patterns for the display characters

Anyway, I though I may as well post this, in case anyone else can spot anything useful in the RAM

Update.

Following a very useful comment from @rootstar

I have recreated a binary dump using firmware 3.1.8, just after the radio has booted up. No buttons have been pressed etc

I’ve uploaded a zip of this RAM dump and also included my codeplug. The channel selected is in the DHS zone and is called DHS 505:2

TG is 505 on TS2, Tx freq is 431.800Mhz and Rx freq is 438.800Mhz

gd-77_3_1_8_TG505_RAM

I’m going to try using Ghidra to decompile version 3.1.8 and see if I can also import this RAM snapshot

m22_ghidra_psoec gd_77_ramdumpI suspect a lot of you are thinking, what on earth is Ghidra

Well, that was my thought 2 days ago, when I was informed by Kai, DG4KLU that a open source reverse engineering tool, developed by the NSA had just been released to the public.

For more details visit https://ghidra-sre.org/

This is great news in relation with reverse engineering the GD-77 firmware, because Ghidra has a lot of the features, previously only available in very expensive programs like IDA Pro.

Armed with Ghidra, I have started to explore the internals of the firmware.

There are multiple ways to attempt to understand what each function does in the firmware, but one way is to work backwards from the hardware registers in the MK22 MCU, which do things like send data to the AT1846 RF transceiver chip, and to the external SPI Flash memory, the external EEPROM and also the keypad and the screen.

The memory addresses of these registers is documented in the reference document for the MK22, but since there are over 1300 registers, manually correlating each memory address in found in the firmware back to its name and function in the reference, would take forever.

Luckily I found out that its possible to create a Processor Specification (PSPEC) file for any microprocessor and use it when the firmware binary is imported into Ghidra

However, getting data on all 1300 registers, from the PDF reference document into the XML PSPEC file required a number of stages of manual and automatic processing, which I won’t bore you all with at the moment.

But eventually, I was able to use my newly minted PSPEC file to annotate all the disassembled and decompiled firmware code.

For example here, is some code which interacts with the SPI interface (though at the moment I don’t know which SPI device or what its sending or receiving)

Ghidra is also capable of decompiling to C code, and even though this could could not be recompiled back into a working version of the firmware, its a great way to get a better idea of what each function does

(this is not the same function as show in the disassembly view in the image above)

And there are also graphic features available to show the hierarchy of functions

And also Function Graphs

Not to get anyone’s hopes up, because there is still a big mountain to climb, in terms of understanding the internal workings of the firmware, so that it can be enhanced or bug fixed, but it does look like things will be a bit easier by using Ghidra

Update.

As requested by various people. Here is my PSPEC file for the MK22 processor.

Note I just added the hardware registers. I have not had time to add processor specific ISR vectors, but they would be easy to add

MK22_PSPEC_NEW

Also. I’ve taken some more memory snapshots, including these 2, one during transmission and one when receiving a signal from VK4NBL

So here are those files

gd_77_ramdump

Note.

My DMR ID is 5053238 (and my callsign is VK3KYY)

I’m pretty sure VK4NBL’s id is 5054068

Note. To import the memory snapshots, you have to press ALT+I which then appends / merges the file to the existing memory map

Don’t forget to use offset 0x1fff0000 when importing the RAM snapshot

In firmware 3.1.8  

Using the memory dumps I have found a few interesting memory addresses

I’m now sure that the current channel data structure is located at 0x1fff3a04, or possibly a bit lower in the memory

0x1fff3a04 upper byte seems to be a flag, as its set to 0x05 when I’m on channel and 0x90 when I’m on a VFO

The next remaining 3 bytes are the Tx TG.

And the Rx Group list starts at 0x1fff3a08

If I change 0x1fff3a04 then press PTT it transmits on the TG I specified.

And…

It looks like the function at address 0x27b52 is called constantly,  and if the memory location pointed to by register r1 is contains 0x0F, it seems to indicate that a signal has been received.

So if you put a break point on 0x27b5a the code only halts when there is a new signal received.

Looking at what references the function at 0x27b52, I found this

PTR_LAB_00027b8c+1_00027f50                     XREF[1]:     FUN_00027b90:00027cd0(R)

00027f50 8d 7b 02 00     addr       LAB_00027b8c+1

00027f54 91 7b 02 00     addr       FUN_00027b90+1

00027f58 53 7b 02 00     addr       FUN_00027b52_event_loop+1

(I labelled the function at 0x27f58 with the extra text  “_event_loop” , to make it easier to find, but I should have probably called it “_task”, as it looks like these 2 functions are possibly the top level task list which is bring run by the RTOS.)

Update..

Jason VK7ZJA has kindly sent me a list of what all the pins on the MK22 MCU seem to be connected to.

You can download the text file from here MK22 connections GD-77

Hopefully this will help getting to grips with the firmware

Just a quick post to let anyone who’s interested know, that I have created a Wiki on by Radioddity GD-77 repository on GitHub, where I intend to document useful information about the GD-77 which may be of benefit to anyone reverse engineering or doing any other tinkering with the GD-77

See

https://github.com/rogerclarkmelbourne/Radioddity_GD-77/wiki

I’ve also uploaded all the datasheets and other documentation I have about the internals of the GD-77, as well as uploading the Processor Spec file I created to allow Ghidra to import the firmware binary, and to show the MK22 internal register names

https://github.com/rogerclarkmelbourne/Radioddity_GD-77/tree/master/docs

https://github.com/rogerclarkmelbourne/Radioddity_GD-77/tree/master/tools

If anyone has any other related documents that I don’t have, please let me know.

Thanks to the work of Kai DG4KLU and @forkoz aka @rootstar, and of course myself ;-)….

The work to reverse engineer the GD-77 is progressing…

@forkoz has done some great work to analyse the operating system used by the GD-77, which is called MQX, and has identified at over 100 functions associated with this, including the top level “Tasks” including

Plus a whole load of other things.

I have found the AMBE codec related functions, by decompiling the MD-380 firmware and cross referencing the “annotations”  list produced by the MD-380 toolz guys, to find any telltale mathematical constants associated with the codec, and by looking for the same constants and other patterns in the GD-77 firmware.

In the end, I found a 100% match between the functions in the MD-380 firmware and the GD-77 firmware, which means that Radioddity (aka TYT), used exactly the same source code for the codec in both radios, and probably used the same compiler (called IAR workbench).

I have also tracked down all the functions related to the AT1846 transceiver chip, using a similar technique; but this time, I looked for patterns of “register” use in the AT1846, because I knew that the registers to set the frequency are 0x29 and 0x2A.

Searching though the binary file of the code, I identified occurrences 0x2A and looked for close occurrences of 0x29, and when I found a match, I used the Ghidra decompilation to confirm that I had indeed found the function to set the frequency.

Once I’d found one AT1846S function it was relatively simple, although time consuming, to follow the hierarchy upwards and downwards, to find where the set_frequency function was used, and also what sub functions the set_frequency function used.

Then cross referencing the incomplete documentation of the AT1846, I was able to find this list of functions

I’ve also loaded RAM snapshots into Ghirda, and I have found the location of the active TalkGroup / PC ID, which I can change using the debugger, and have confirmed, changes the TG or PC that the radio uses.

I’ve also found the current Rx group list

Kai (DG4KLU) has been busy building some firmware from scratch, which will hopefully eventually become an alternative Open Source firmware for the GD-77, but just getting the radio to work on FM will require, hundreds if not thousands of hours of work.

Kai has also supplied information on the way the radio reads the keypad, and I have now identified 6 hidden commands that are activated by holding various keys down when the radio is turned on, as well as many other snippets of information.

PLEASE DON’T TRY THESE BUTTON COMBINATIONS ON YOUR RADIO, BECAUSE I DON’T KNOW WHAT THEY DO

Blue button and “3”

Blue button and “6”

Both look like they are doing something like resetting back to factory settings, as the radio seems to reboot after using these sequences.

However I could not see any difference to the codeplug in the radio after pressing these combinations

Also

Black button and “1”

Black button and “2”

Black button and “5”

Black button and “6”

See to set some internal configuration inside the GD-77, but I don’t know what these configuration do. They could potentially reset the codeplug or the calibration or anything.

Now that I know where the keyboard reading and decoding function is, I’m hoping to be able to patch the code to allow direct input of TalkGroup, but one complication is that the new TG would need to be added to the Rx Group list, so I think I first need to modify the Rx group handling so that the Tx  TG is automatically added to the Rx Group list.

IMHO the Tx TG should always be part of the current Rx Group list, as this is a gotya that catches people out when they select “None” for the Rx Group list on a Channel in the CPS and then find they can’t hear any audio.

So I want to patch the Rx Group list code, to also read the Tx TG, under all circumstances first – though this is easier said than done.

After that I want add a function, where pressing the  star key, will allow direct entry of a Talkgroup.

But I think it could be a few weeks before I manage to even get the initial change to the Rx Group handling to work.

What we really need is more people to help with analysing the GD-77 firmware, its only going to be slow progress with me and @forkoz doing the analysis

The lack of a decent Callsign + name lookup and display system on the GD-77 has always bugged me.

When the GD-77 was first released, the only way to be able to display the callsign, was to add stations to the Digital Contacts section of the CPS.

The big problem with this, is the maximum number of Digital Contacts is 1024, and this includes all the TalkGroups. In my case I have about 40 TalkGroups, which only leaves space for around 980 contacts.

Radioddity released an update to the firmware, where they added a separate feature to store around 10,000 callsigns. (I can’t remember when this was introduced, possibly version 3.0

This used a separate program, called ActiveClient, to download the DMR database and then upload it to the radio.

The actual maximum was 10920 callsigns. Its this number because the amount of memory they use for this is 128k bytes, ( 131072 bytes), and each “record” in the database is 12 bytes long. 4 bytes for the DMR ID and 8 bytes (characters) for the callsign.

131072 divided by 12 is 10922.6 but the block of memory has a “header” which contains a identified code if the letters “ID-V001” and also stores the number of records , so that the first “record” starts at an offset of 12 into the DMR ID memory.

So (131072 – 12 ) / 12 = 10921.66 and Radioddity limit this to 10920 in ActiveClient ,though they could have allows 10921.

However, this feature has some annoying problems.

1. Unlike Digital Contacts, the number of characters that were allowed per DMR ID was only 8, whereas Digital Contacts have 16.
This means that only the callsign can be displayed, and I like most other people find having the name displayed almost essential.

2. In a signal is received, the firmware checks the DMR ID database  before the Digital Contacts list.
So if the same ID is both the Digital Contacts and the DMR ID data, then the 8 character DMR ID data is displayed, rather than the 16 character (callsign + name) from the Digital Contacts

I suspect that Radioddity chose to use 8 characters for the callsign, because this would allow them to advertise that the radio could store “over 10,000” callsigns.

If they had allocated 16 characters for the callsign, to allow space for the name, the number of records would have been 6553, which would have not looked so good in their marketing materials.

But for me, I’d rather have 6000 callsigns + names then 10,000 callsigns on their own.

So for the last week I have been looking for the part of the firmware which handles the DMR ID database lookup, and I eventually found it, by tracking down the memory accesses to the part of the memory which we already knew contained this data

I’ve put the C decompilation of this function, created by Ghidra, at the bottom of this post.

The function is pretty easy to understand if you know that the value 0x0c is 12 in decimal. This value is both the offset from the start of the memory block and also the lenght in bytes of each record.

So calculations like

startOffset = iVar4 * 0xc + 0xc;

are calculating the position of an individual record within the data block.

In theory it looks as if its a simple change to the DMR ID to handle 16 characters per record, simply by changing occurrences of 0x0c to 0x14 (both numbers being in hexidecimal)

The slight confusion is that the offset value is also by coinsidence also 0x0c, and those must remain unchanged.

However, just changing the appropriate 0x0c values to 0x14 would not work.

The reason is that the firmware needs buffer space to store 16 characters, and it only has space for 8 characters.

Specifically these lines.

uint local_44;
undefined auStack64 [8];
uint local_38;
undefined auStack52 [8];
uint local_2c;
undefined auStack40 [8];

But unfortunately, its not possible to change these [8] to [16], because in Ghidra, and as far as I know, all other reverse engineering programs, the C decompilation is for viewing only, and it does not have a re-compile feature.

So the only way to change these values is to change the assembly level instructions; which are much harder to understand.

To cut a long story short; its taken me about 3 days to learn enough about the ARM microprocessor assembly language, and to analyse the machine code, to be able to modify the function and change these values to

uint uStack92;
undefined auStack88 [16];
uint uStack72;
undefined local_44 [16];
uint uStack52;
undefined auStack48 [16];

Note the names have changed, becuase they are partially reflective of the locations in memory (relative to the “stack”).

After changing the buffer size, I patched the firmware with this change, and uploaded it to the GD-77, and confirmed that the DMR ID was still working after the change to the buffer sizes.

The next step was to modify my CPS to optionally use 16 character DMR ID records (20 bytes in total), and also to modify the firmware to handle both the mathematics of the calculations for 20 byte records and also to read 20 bytes instead of 12 from the SPI Flash memory.

Finally, this evening, I’ve just finished both changes, and my new firmware now supports the extended DMR ID record length.

But, I still have some more work to do, because I need to change the firmware so it can handle both the old and the new record sizes, because initially after the firmware is updated, the GD-77 could have data in the old format, still in its memory.

I hope to be able to achieve this by, changing the header on the DMR ID data.

Radioddity’s programmers included a handy version number of “001” in the header, and currently the existing firmware checks the first 4 letters of this, to confirm whether any DMR data has been loaded at all

i.e the “ID-V” part (actually it also checks for “ID_V” )

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00030000 49 44 2D 56 30 30 31 00 83 0A 00 00 35 42 34 02 ID-V001.ƒ...5B4.

But because there is no space between functions in the GD-77 firmware, I can’t simply add some additional machine code instructions.

What I need to do instead, is to overwrite some of the existing check function, and probably use the area of the machine code which checks for the “-V’ or “_V”, and check whether the last digit of the number is 1 or 2.

i.e set the record length at 12, and then if the 7th byte is “2” then add 8 to the record length.

Once I’ve done this, I’ll encrypt the firmware and send it out some people who have spare radios, which they have told me they will be willing to use as test-beds for the new firmware.

Once beta testing is complete, I will of course publish the new version, so as they say… Watch this space…

———————– Decompilation of the DMR ID lookup function ——————————————–


undefined4 DMR_DB_lookup_000340c6(int iParm1,undefined4 uParm2,byte *pbParm3)
{
int startOffset;
uint uVar1;
int iVar2;
uint uVar3;
int iVar4;
int local_50;
char local_4c;
char local_4b;
char local_4a;
char local_49;
uint local_44;
undefined auStack64 [8];
uint local_38;
undefined auStack52 [8];
uint local_2c;
undefined auStack40 [8];
if (((((pbParm3[4] == 1) && (SPI_Flash_read_area_000263a6(4,0,&local_4c,8), local_4c == 'I')) &&
(local_4b == 'D')) && ((local_4a == '-' || (local_4a == '_')))) &&
((local_49 == 'V' &&
(SPI_Flash_read_area_000263a6(4,8,(undefined *)&local_50,4), local_50 != 0)))) {
uVar1 = (uint)pbParm3[3] |
(uint)pbParm3[1] << 0x10 | (uint)*pbParm3 << 0x18 | (uint)pbParm3[2] << 8; uVar3 = local_50 - 1U & 0xffff; SPI_Flash_read_area_000263a6(4,0xc,(undefined *)&local_44,0xc); if ((int)uVar3 >> 1 == 0) {
if (uVar1 == local_44) {
LAB_0003419c:
memcpy_0001f2c0(iParm1,(int)auStack64,8);
return 1;
}
}
else {
SPI_Flash_read_area_000263a6(4,uVar3 * 0xc + 0xc,(undefined *)&local_2c,0xc);
if ((local_44 <= uVar1) && (uVar1 <= local_2c)) { if (uVar1 == local_2c) { memcpy_0001f2c0(iParm1,(int)auStack40,8); return 1; } iVar2 = 0; iVar4 = (int)uVar3 >> 1;
if (uVar1 != local_44) {
do {
while( true ) {
while( true ) {
startOffset = iVar4 * 0xc + 0xc;
if (iVar4 == iVar2) {
SPI_Flash_read_area_000263a6(4,startOffset,(undefined *)&local_38,0xc);
if (uVar1 != local_38) {
return 0;
}
goto LAB_000341fa;
}
SPI_Flash_read_area_000263a6(4,startOffset,(undefined *)&local_38,0xc);
if (local_38 <= uVar1) break; uVar3 = iVar4; iVar4 = iVar4 + iVar2 >> 1;
}
if (uVar1 <= local_38) break; iVar2 = iVar4; iVar4 = (int)(uVar3 + iVar4) >> 1;
}
} while (uVar1 != local_38);
LAB_000341fa:
memcpy_0001f2c0(iParm1,(int)auStack52,8);
return 1;
}
goto LAB_0003419c;
}
}
}
return 0;
}

Its taken a bit longer than I thought, but I now have some patched firmware, which makes some minor changes to the DMR ID system.

I have also updated my CPS to use the changes to the firmware.

The firmware is very experimental at the moment and I am only distributing it via email to people who are willing to potentially brick their radio (though I think the chances of bricking are very low)

In the DMR ID screen in the CPS, there is a now a checkbox, which enables “Enhanced firmware mode” (Note i may change this name later)

When this is enabled, another drop down menu appears, which allows the number of characters per DMR ID to be selected.

As there is only a finite amount of storage in the GD-77, the total number of DMR ID’s that can be stored, is inversely proportional to amount of storage taken by each DMR ID item.

The main problem with the GD-77 is it does not have much memory to store the codeplug and the DMR ID etc.
It only has 1 mega byte of storage (Flash memory), plus an additional 64 k bytes of EEPROM.

The codeplug seems to be partially stored in the EEPROM and partially in the middle of the 1 mega byte memory.

The official firmware stores the DMR ID in the Flash memory from addresses 0x30000 to 0x4FFFF, which is 128k.
Each DMR ID consists of 4 bytes for the ID number (which is wastefully stored in Binary Coded Decimal), followed by 8 bytes for the callsign , which gives a grand total of 12 bytes per DMR ID record.

Since most callsigns are 6 characters long, only having 8 characters available does not leave any space to store the name

What I have done is modify the firmware, to increase the temporary storage memory in the firmware, which is used to search for the callsign,( for a give DMR ID), from 12 bytes to 20 bytes. This allows the number of characters for the callsign to be increased from 8 to 16.

However, I realised that some people may prefer to only display the callsign, but be able to store more DMR ID’s.

So I modified the firmware, so that the CPS can set the number of characters.

I also modified the firmware to use an additional 128kb of memory for the DMR IDs. This is in the range 0x50000 to 0x6FFFF.

Looking at a memory dump of the Flash chip, there is data in this area, however it appears to be things like copies of old codeplugs, and also was supposed to hold the backup of the calibration data.

Due to a coding mistake in the official firmware, the backup of the calibration data can’t actually be used, and is corrupted if a factor reset is performed on the radio.

So, as far as I can tell its safe to use this region of memory for the DMR ID, albeit will overwrite the backup of the calibration.

Note.
The Flash memory, including the calibration backup etc can download from the GD-77 using FlashManager. This is a much more sensible way to make a backup of the radio, since then even if there is a serious problem in the radio and the whole of the Flash memory gets erased or corrupted, the data can be restored using FlashManager.

The result of these changes is that if the existing 8 character length is used, the number of DMR IDs that can be stored, doubles to over 21000

The number of characters needed to store the callsign and name is between 13 and 15 for most names, and I am now using the setting of 14 characters, as this seems to fit most names.

Also the GD-77 seems to only be around 15 characters wide, and the 15th character is partially obscured by the “phone call” symbol that appears on the right of the screen when there is an incoming signal.

I am hoping that the volunteers will test the firmware today, and if it seems to be reliable, I will distribute it a bit wider via email.

Because I don’t have a production process for these firmware releases yet, I will not be publishing the file to my blog or elsewhere at the moment, but hopefully I will be able to sort out a way to do this soon.

PS. If risk takers out there want to give it a try, please let me know

Just a quick update on our ongoing work to enhance the GD-77

Thanks to @rootstar aka @forkoz for his help with this, and to Kai and Jason.

Currently the POC version with enhanced DMR ID, uses 256k instead of 128k of the external 1Mega byte flash chip, and allows between 6 and 16 characters for the callsign + name text. This give between about 12,000 and 20,000 DMR ID’s

The official firmware only uses 128k, for the DMR ID storage, but I found the 128k immediately above the area which Radioddity already use, is not actually used even though it appears to have data in it. Hence I used it.

The codeplug memory starts at 0x30000 and now extends for 0x40000 to 0x6FFFF.

What’s stopping me expanding further up into the memory, is first the upper half of the codeplug, which is situated at 0x70000 hex, and the calibration data at 0x8F000.

I thought the area of memory below the DMR ID (at 0x30000) wasn’t being used either, so I tried to move the upper half of the codeplug to 0x10000, but this didn’t seem to work.

However in hindsight, I think I probably failed to change all the places in the firmware which referenced the 0x80000 address range (actually this is referred to in the firmware as 0x70000 + an offset of 0x10000)

I’ll probably have another go at moving the codeplug another day.

The other thing that I’d need to move is the bitmap fonts, which are at address 0x90000, and I may be able to move this to address 0x00000 but at the moment FlashManager can’t access any addressed below 0x10000, so I’d need to understand why that’s happening, and change the firmware, before that can happen.

Even with all these changes, I’m never going to be able to store all 125,000 DMR IDs that are currently registered.

So one option would be to remove the 1Mb memory chip, and replace it with a 8Mb or 16Mb version.

The chip is a 16 pin SMD DIL package, and I have removed and replaced similar chips, by snipping the legs, removing the main body of the ID, and then unsoldering each leg, before cleaning the PCB with some desoldering wick, before soldering in another chip.

Its a shame the GD-77 does not have the 8Mb memory chip which is fitted to the MD-380, as this would allow all the DMR ID’s including callsign, name and location to be stored.

I’m not sure however, whether the location information is that useful or not, because of the latest changes to the RadioID.net database, it now just has country, and in the USA it also has the state.

On the GD-77’s display, there is probably room to move the callsign and name text up a few pixels and perhaps display the state / country on a line below the callsign.

I could probably move the text for the talkgroup name, up onto the same line as the text that reads “Group Call” if perhaps I remove the “Group Call” or shorten that text somehow.

I’m not sure how important it is to know its a group call vs a private call. Its normally fairly obvious by the Talkgroup name. Or perhaps an icon could be used to indicate this.

If possible I’d like some comments on how important having the entire DMD ID database inside the radio is, and how important the location text is.?

I’ve also started to investigate ways of doing direct entry of the talkgroup number via the keypad (like MD380Toolz has).

I think the best user interface for this, is to use the existing number entry system that’s used for Private Calls, by pressing the # key before entering the number.

But I’d need to use the * (star) key or possibly the # key as an Enter key, which would transfer the number entered, into the active talkgroup memory location.

In theory, this change is not too difficult, but the problem is that it requires extra firmware, and there is very little free space at the end of the existing software.

So we have been looking for places in the firmware which contain redundant data, and so far have only found about 16k of Chinese language support data, which we may be able to use as space for firmware functions.

Just isolating the 16k of Chinese language support information took several hours, and we’re not 100% confident we know the beginning and end locations in the ROM for this.

If we want to add more features, we’re definitely going to need to find some more places in the ROM to squeeze some code.

I did notice a few kilo bytes of debug messages associated which can probably be used for small chunks of functionality.

We have also been investigating the menu system, mainly so I can change the version number for my firmware releases, but strangely we can’t find the version number e.g. v3.01.08 in the firmware at all.

There is a piece of the ROM that contains the text v318, but this doesn’t seem to be the text that is displayed on the screen of the GD-77, but it may be sent back to the CPS if the codeplug is downloaded from the radio.

In order to figure out where the version number is stored, we have been investigating how the menu’s work.

By trial and error, I found the part of the firmware, which handles the creating of a text message, i.e the Menu -> Message -> New Message.

Whats interesting about this find, is that it led me to the understanding that most of the functions which Ghidra thinks are orphaned, and aren’t used by the firmware, are likely to be the functions which are part of the menu system.

I’ve now created a list of about 150 orphaned functions,  which may linked to the menu system. ( using Ghidra and a text editor and a spreadsheet)

Unfortunately the only way to determine which of each of the 150 functions is connected to which individual menu item, is to use the hardware debugger attached to the processor in my GD-77, and set it to trigger when any of the 150 functions is used.

However, I found that setting up that many breakpoints in the code, caused it to run unusably slow, and my only option is probably to look for 10 functions at a time, and repeatedly use all the menus and see if the debugger triggers.

I think as we find the of more and more of the menu functions, we should be able to work out how the menu system stores the memory address of each of the functions, but at the moment its still a mystery.

So… I’m investigating multiple things at the same time, and hopefully sooner or later, something useful will come out of all this research.

Just a quick post to let people know that I finally got around to making an installer for the GD-77 Flash Manager software, that allows the 1 M byte Flash memory in the GD-77 to be backed up and restored etc.

The installer can be downloaded from here

https://github.com/rogerclarkmelbourne/radioddity_gd-77_flash_manager/raw/master/installer/RadioddityGD77FlashManager.exe

I’m am also compiling an archive of backups that people have taken of their transceivers.

This is mainly to look at the variations in the calibration data stored at 0x8f000 and also the backup calibration at 0x51000

Jason VK7ZJA wrote some instructions on how to use FlashManager to fix problems with the calibration in his page

http://members.optuszoo.com.au/jason.reilly1/GD-77tune.htm

Which I will paste here, to save everyone some time

Step 1: Download Flash Manager and install.

Step 2: Turn off the corrupted GD-77, connect programming cable to the radio and to the PC. Do not turn on the GD-77 yet.

Step 3: Hold down the side blue key, green menu key (above left arrow button) and the * / lock key (just below the right arrow button) while turning on the GD-77. The radio will appear to power up normally.

Step 4: Launch Flash Manager.

Step 5: Read the entire flash. Set Start address (hex) to 0, and set Length (hex) to 100000 – that’s one followed by five zeroes. Click the Read button, and wait about 5-6 minutes for the read to complete.

Step 6: Export the read data to a file using the Save File button. Call the file something like YOUR_CALLSIGN_GD77_Flash_Backup.bin In Windows the file should show as being 1.0 Mbyte in size.

If anyone doesn’t have my email address and would like to send me their backup, please post a comment, (where there is a box to enter your email address) and I will send an email to you, which you can reply to.

Let me know if you are happy to share your backup publicly , as I will put them with the other files I have

https://github.com/rogerclarkmelbourne/Radioddity_GD-77/tree/master/wiki_attachments/external_flash

Thanks

I’ve just finished another modification to the GD-77

The modification allows the DMR channels to work, even when the Rx Group list is set to None, or if the Transmit “Contact” TG is not in the Rx Group.

The reasons I’ve made this change are…

1. I need the radio to be able to receive on the Tx TG, for when I modify the firmware to allow direct entry of the TalkGroup.
   Note. I’ve not even started to look at this, because the change to the Rx Group stuff has taken me several days to shoehorn into the existing software
2. I think the firmware should always have done this..
   It seems crazy that you can setup a channel with a Tx TG and can transmit, but can’t hear incoming signals on the same TG that you transmitted on.

For anyone interested in the technical details.

The official firmware has code which compares the incoming signal TG, with each Rx Group list TG in turn, and if there is a match it allows the signal to be received.

The change I made, additionally checks whether the incoming signal is the same as the Tx TG, and it does this check prior to checking the Rx Group.

The problem with this change, was trying to optimise the assembly programing, so that I don’t waste the precious space that is available in the ROM.

The ROM is already 99% full, and even if the Chinese fonts are removed, it only gives around 32k for all enhancements. This is not very much at all.

I noticed that the internal data structure , which is stored in the RAM of the GD77, has the Tx, TG in the memory location directly before the start of the Rx Group list.

So initially, I thought I’d simply change the code to start checking TG’s from the Tx TG memory location, and increase the number of locations it checked, from 32 to 33.

32 being the max number of TG’s in a Rx Group list.

However I found that the Tx TG, memory location, not only contained the TG, but also some other information, which is either the TG type i.e Private Call, Group call or All Call, or the data may also be the Timeslot (TS1 or TS2)

Regardless of what the additional data is, the problem is that this additional data encoded into the Tx TG memory location, stops me directly comparing the Tx TG with the incoming signal TG, as they won’t ever be the same number.

So I had to “mask off” the portion of the 32 bit memory location which contained the additional information.

I found there wasn’t space within the existing Rx Group checking code, so I had to make a sub routine (aka function), which stripped off the additional information before giving the sanitised TG back to the existing checking part of the code.

This worked OK, but I didn’t feel that it was an optimal solution, because the masking function was being run for the Rx Group list TG’s which didnt need to be masked, and would slow things down a tiny bit.

So I decided to program it correctly, and to check the Tx TG prior to the code checking the Rx Group list TG’s

Looking at the assembler code, I found the IAR compiler that Raioddity use, had 4 duplicate assembler instructions, which I could remove, from the core of the Rx Group checking system, and using this space, I was able to move all the prior instructions down, into the free space, which left me with 12 bytes to play with, to check the Tx TG prior to the Rx Group checking code.

It was actually quite time consuming to “move” the code downwards, as I had to retype about 50 machine code instructions into different locations, and also fix up the branch addresses to match the new code layout.

This too several hours.

Then with the 12 instructions prior to the existing code, I was able to “call” a new function, which loaded the Tx TG, and masked off the Call Type, and Timeslot data, so before returning the sanitised TG to the existing code.

And with the remaining 8 bytes, I could compare this TG with the incoming TG and take the appropriate action, i.e either accept the signal immediately, or get the program flow to continue onto the existing Rx Group checking code.

It took me about 3 or 4 attempts to get this new code to work, as I had a few minor bugs which prevented it from working at all.

But it finally worked OK.

I’ve sent this version via email to a few people to test, and I’m hoping to get some feedback over the next week.

And after a short break, I’ll start to look at the Direct TG entry system

Update Saturday 6th April

Rick, W1RHS  has alerted me to a possible side effect of this change.

On his hotpot, the audio amplifier does not seem to be getting muted during the tail of each transmission, when his hotspot continues to transmit, but there is no audio in the DMR signal.

I have tested this myself and I can’t replicate the problem, but it may depend on the hotspot settings.

My guess is that, the firmware doesnt think it needs to mute the audio, because it doesn’t think the amplifier was unmuted in the first place.

So I’ll need to hunt down the part of the firmware which handles the end of an incoming transmission and probably always mute when the incoming audio ends.

Since I last posted I have been very hard at work on the GD-77 firmware, but unfortunately don’t have much to show for my efforts

I’ve been putting most of my effort into the manual entry of the TG number, which has been very difficult to achieve

The problem has not been actually allowing the TG number to be entered, or initially making the transceiver receive and then transmit on the new TG, as well as updating the display to show the new TG.

The problem has been that the rest of the firmware keeps setting the TG back to the original value, from the codeplug, and even worse, the firmware has been saving the text I put on the screen, back into the codeplug memory, but has not been saving the TG number.

This has opened a can of worms around the functionality of the existing firmware, firstly about why it would read the text from the display and randomly write it into the codeplug.

I assumed that the codeplug would not be modified by the radio unless you specifically went into the Set->Radio Cfg -> Ch_Name to change the name.

However I found that the firmware is randomly re-writing parts of the codeplug just when you use the radio normally !

IMHO this a very bad idea, because if something goes wrong, the user will see the “No Channel” message, because before the codeplug can be updated, it needs to be erased and sometimes the original data is not restored during this process.

The other interesting thing I learned about DMR is how the original firmware keeps changing the Tx TG.

When the radio is turned on and a channel is loaded it sets the TG, which will be used for Tx.

When a call is received, this can be a Group or a Private call, the firmware puts that TG into the TG that will be used for Tx.

Hence if you have multiple TG’s in your Rx Group and receive a call/signal on a TG other than the TG currently set for the channel… If you press the PTT, within a short time of the call being received, you will transmit on the TG of the incoming call and not the TG set for the channel.

The same applies for Private calls. If you receive a PC and press the PTT while its still displaying the callers name or ID, you will transmit as a Private call back to that station.

If after receiving an in incoming signal / call, you don’t reply (by pressing the PTT), after a few seconds the TG in the radio will be set back to the TG assigned by the channel.

I’m not sure for Amateur Radio use, whether the system that calls back on the incoming TG is ideal. I know that it confuses a lot of people, and I did not understand what was going on when I first used DMR

This problem is worse on the GD-77 because the official firmware forces you to use a Rx Group, its a pain to have to create a Rx Group for each Tx TG, and also if using a repeater which supports multiple TG’s e.g. in my case 505 and 3808, it seems logical to set the Rx Group for that repeater to include both TG 505 and TG 3803.

This is further compounded on the GD-77 because of the Admit Criteria bug, where the only practical option for most repeaters, is to set the Admit Criteria to Always, since otherwise you have to wait for the repeater or hotspot carrier to stop being transmitted at the end of each over, before you can transmit, and that can take 5 to 10 second, or even longer.

Anyway. The TG restoration to the value assigned by in the codeplug for the current channel has been the most problematic, and I have tried 3 or 4 different ways to do this.

Ultimately, I think I now have the optimum solution, which works as long as Double Wait is not being used.

The solution involves modifying the code which sets the Tx TG to the channel TG, but only when the code is doing this in response to the user not pressing the PTT after receiving an incoming signal.

And in this case I found that the SET TG function in the code expects the data to be in the format its stored in the codeplug.

Whats crazy about this, is that the codeplug data is in BCD format, (Binary coded decimal), and also in BigEndian format. Where as the CPU in the GD-77 is an ARM processor an runs in LitteEndian format.

Hence If i want to set a TG of 00003803, need to convert this to  03380000

Note this is not simply a reversal of the digits, as that would be 30830000, its much more complicated, as each pair of digits needs to be swapped as well as the order of the pairs of digits needing to be swapped.

Hence it took me several hours to work out what was going wrong and how to create the number in the bizarre form that the SET_TG function wants it.

I also had to implement this feature, so that if the override TG code was 0, it was ignored, as the SET_TG only needs to be overridden when the user has actually entered a new TG via the keypad.

And, I need to reset the override TG when the user changes the channel, or changes the Zone (which will change the channel)

At the moment, I’ve only managed to clear the override when the user changes the channel, but I’ve not which of the 5000 unnamed code functions in the firmware binary, are run when the user selects a new Zone.

I think there may be other instances where the override needs to be cleared, but I’ll need to cross that bridge when someone tells me that the TG as not been cleared when it should have been.

So despite at least 2 weeks work on this, I’ve not got anything available for general testing.

I do have 2 people trying various versions of this, and they have been able to set the TG but those people have been willing to put up with the bugs caused by the TG not being cleared when they change zones etc etc

Additionally, I’ve been alerted to possible problems in the extended DMR ID lookup, and have noticed a bug in the official firmware, where when making a Private call to a ID thats in the DMR ID database, the display strangely displays a number in the bottom line.

I checked this bug, and it exists in the official firmware.

There also seems to be a potential bug, if the callsign and name take all the characters that have been allocated, e.g if perhaps only 12 chars were selected in the drop down menu in the CPS.

Again, this seems to be a bug  in the official firmware, as the memory buffer used to hold the callsign and name, does not seem to be cleared before being used, and this can result in this GD-77 trying to display random characters after the end of the name.

I think I know how I can fix this, but it requires changes to my modified DMR ID lookup code, and also it requires me to tidy up some inconsistencies in parts of the the official firmware which allocate the memory buffer for this text.

In hindsight, I suspect fixing the Admit Criteria bug may actually have been easier than adding what appears to be a simple new feature, but that’s the problem with hindsight

I noticed today that a new version of GD-77 firmware was listed on Radioddity’s web site.

The link didn’t work, but I was able to construct what the link should be, because the server returned an XML file which listed all the possible file downloads !

https://gd-77.s3.amazonaws.com/GD-77%20Firmware%20V3.2.2%20%26%20Software%20V3.1.1_20190425.zip

I looked in the “Update diary” document which is part of the download, but its not been updated to show what has changed in this version, so I’ve asked Radioddity to let me know what has changed.

Unfortunately its a 4 day public holiday in China, and I don’t think anyone will be back at work until next Monday.

To make the development work on the GD-77 firmware a bit easier, I’ve created 2 new utilities for anyone working on the GD-77 firmware.

The utilities are   bin2sgl and also the GD77_FirmwareLoader

Note. These tools, especially the firmware loader, have not been extensively tested yet, and should be used with caution.

Both are Command Line utilities, but the firmware loader also has a small GUI if its used without specifying a file name to upload.

bin2sgl converts an unencrypted firmware binary file into a SGL file which can be uploaded into the GD-77 using the official Radioddity “update.exe”

This is an amalgamation of Kai’s (DG4KLU) encrypter/decrypter tool’s functionality that not only encrypts, but also adds the header required by the official update.exe application.

The second utility GD77_FirmwareLoader, is a command line replacement for Radioddity’s update.exe, which is used to upload new firmware into the GD-77

As well as being able to upload the official .sgl update files, it also accepts unencrypted firmware (binary) files, and encrypts them before uploading.

The utility is primarily intended to be used by developers who can “script” their development environment to use the utility to automatically upload a binary or SGL file into the GD-77, without having to mess around running the updater and selecting a file and pressing the button to upload the firmware into the radio.

It can also be used to do a drag-and-drop update of the firmware. And it also has a small GUI, which allow the file to be selected if its run without a file being specified.

Its also smaller than the official Radioddity updater, because its self contained and does not use any external .dll files like the Radioddity uploader does

Additionally, if a second argument of “GUI” is specified e.g.

GD77_FirmwareLoader.exe gd77_vk3kyy_20190505.sgl GUI

The tool will show a small window containing a progress bar. I primarily added this feature so that when used with tools like Ghidra, the upload progress can be seen quite clearly.

Both new tools have been added to the tools folder in my Radioddity_GD-77 github repository.

https://github.com/rogerclarkmelbourne/Radioddity_GD-77/tree/master/tools

I’ve also created some Ghidra scripts to use these utilities but I’ve not had time to publish them yet.

I wanted to connect a hardware debugger into another of my Radioddity GD-77s, but didn’t want to drill a hole in the side like I did on one of the radios…

But I then realised that the rubber protector that goes over the 2 jack sockets in the side of the radio, can be removed, and this gives a handy hole, through which I can feed the Serial Wire Debug wires.

Inside the radio, the wires are soldered on 4 pads on the back of the main PCB, roughly in the area between the # and 0 buttons on the keypad.

To prevent the wires either breaking off where they are soldered or worse, pulling the pads off the PCB (which is a common problem), I have used hot glue to secure the wires close to where they are soldered to the PCB

Taking the GD-77 this far apart is relatively easy, as its actually only held together by 2 screws near the base of the radio, and also by the 2 ring nut’s around the SMA connector and the volume / on/ off knob.

The 2 obvious solder pads just in from the 2.5mm jack socket are the speaker connections, which I have temporarily unsoldered as the wires to the speaker are very short.

The white and black connector on the left in the photo is for the flexible ribbon cable for the display / keypad PCB which screwed to the front of the radio.

To detach the ribbon cable, you have to separate the black part of the connector from the white part, using a small flat blade screwdriver.

The trickiest thing when re-assembling the radio is re-inserting the ribbon cable and then pushing the black part of the connector across so that it crimps the ribbon in place.

But I’m becoming a dab hand at doing this as I’ve repaired server GD-77’s for members of the local radio club, where they received GD-77s where the ribbon cable was not securely clipped or the cable was not pushed in far enough, so that over time the display became partially disconnected.

BTW.

Some eagle eyed readers will notice that I pealed off the Radioddity logo, because I wanted to see if anything was underneath. As you can see, nothing is…

It may however be fun to make another label to replace the Radioddity one, but I’m not sure yet, the best way to do this.

Another small note…

To erase the CPU, it needs to be halted by the debugger, which requires the Reset pin to be connected. In my case that’s the purple wire.

However once the CPU has been erased once, the Reset is no longer required, so I could in theory open the GD-77 again and remove that wire.

But Its not causing too much hassle at the moment, so I simply leave it disconnected, or connect it via a resistor to +3.3V from the debugger, to prevent RF pickup on the reset pin which can cause the radio to reboot if you transmit with 5W, or sometimes even with 1W!

Unlike the “Jumbospot” most duplex MMDVM hotspots are not sold in a case.  You simply get the “modem” board and normally need to buy a Raspberry Pi and case separately.

I’ve tried making my own case from laser cut perspex, but it ended up being quite bulky, and I prefer to put RF devices into metal boxes, so I started to look for a suitable case which could be modified and eventually found this one.

As links to online vendors go dead very quickly, I’m not going to post any links, but if you search for   Aluminium case Raspberry Pi 3   you should find cases which look like this .

My initial concern with using a metal case, was that the WiFi would not work very well, but somehow the 2.4GHz WiFi signals must be able to leak out of the case, because I found that the WiFi connectivity was not a problem at all, and it even worked where I thought my WiFi router signals were quite weak.

There are 2 main problems with fitting the hotspot into the case…

1. The antennas
   With this box, I was able to drill holes in the top which were just big enough to insert antennas that normally come with the hotspot board.
2. Securing Raspberry Pi to the case and still being able to secure the hotspot board to the raspberry pi.

With this box. The Raspberry Pi board is only secured by one screw,  which attached to the post in the lower right corner of this photo.

Additionally the end of the RPi which has the USB sockets rests on a shelf which is part of the end cap, and the USB sockets are a reasonably tight fit, which overall seems to retain the RPi board well enough.

What the case does not have however, is any way to access the bolts that I use to secure the hotspot board to the RPi.

There are several different ways to secure the hotspot to the RPi, and I normally use 2.5mm bolts (about 30mm long), with plastic or metal tubes between the hotspot and the RPi on the side of the hotspot furtherest from the connector.

The other way to do this is to use threaded pillars, and small screws, however I couldn’t find any suitable pillars which didn’t bump into the USB power socket on the RPi, but I had some thin metal tubing.

So my solution was to drill 3 access holes in the base of the box, though which I could insert the hotspot securing bolts, after the RPi had been bolted in place.

Note. Its not possible to access the securing screw if you try to pre-assemble the RPI and hotspot together, because the hotspot gets in the way.

I guess it could be possible to cut the corner off the hotspot board, to allow access to the securing screw, but I don’t mind having some holes in the base of the case, as it helps a bit with ventilation

Here is the case, with the RPI fitted and secured by the single screw, which can be seen in the upper left corner of the board in this photo.

I’ve also fitted heat sinks to my RPi 3B because my shack often gets to 30+ degrees C in the summer, and a little extra cooling does no harm.

With the RPi in place, the 3 bolts that secure the hotspot can be inserted though the access holes in the base of the case

And then fed through the metal tubes, before being secured by a nut

(In this photo I removed one end of the case so that the tube could be seen)

To stop the nuts working loose, I put some clear nail varnish on them, because its quick drying, and cheaper and easier to get hold of than threadlock.

You’ll have noticed that my hotspot seems to have 3 extra wires which go down though into the RPi.

These are the wires which I use to control the hotspot using a 2 position switch, and connect to a RPi GPIO pin which is accessible on the hotspot board.

At the moment, I don’t have a small switch which is suitable for this case, but I didn’t want to unsolder the wires, so I’ve simply pushed them out the way to stop them shorting onto anything.

And this is what the final case looks like.

Note. I’m using right angle adaptors on the antennas. This is for several reasons…

I think that having both the Tx and Rx antennas in the same polarisation , in very close proximity to each other is not a good design idea, and I always use right angle adaptors so that I can orient the antennas away from each other.

And… I find its handy to be able to stand the case on its end, and have the antennas as “bunnies ears”,

And.. I can almost completely fold the antennas away, but unscrewing then a bit and rotating them to be along the length of the case.

Unfortunately the antennas are slightly longer than the case, but only by a few millimetres.

My next upgrade will be to refit the switch, as I think I will be able to remove the end cap at the SD card end of the RPi and fit a small toggle switch, which I can then use to easily switch between either it being a Simplex or Duplex hotspot, or use it as a network switch between BM and DMR MARC, or possibly use it as a frequency switch for instances where I’m in proximity with another hotspot on the same frequency.

I’m also hoping to make a display that I will fit to this case, but that’s a far bigger project

As regular readers will know, Kai DG4KLU cracked the encryption on the Radioddity GD-77 DMR radio firmware back in March.

This has allowed the official firmware to be decrypted, modified and uploaded to the radio again, and also allows non-Radioddity firmware to be loaded onto the radio.

Initially after Kai cracked the firmware, my main focus was on attempting to understand how the official firmware functions, and to make changes and enhancements to the official firmware. This included removing the requirement that every DMR channel needs to have an Rx Group assigned to it, enhancing the DMR ID callsign / name lookup system, and more recently attempting to add direct TalkGroup numerical entry.

However, making more than minor modifications to the official firmware, proved to be an incredibly complex and time consuming process.

So when Kai told me, about 4 weeks ago, that he had some experimental open source firmware which was able to receive both FM and also DMR, I was keen to take a closer look….

Kai’s firmware is hosted on github in a sub folder of Kai’s other GD-77 related work, which includes his decryption and encryption tools

https://github.com/talentraspel/GD-77/tree/master/GD-77_new_firmware

Everything is open source, except that DMR audio codec, which is merged as a binary inclusion from the official Radioddity firmware.

Kai’s initial firmware, featured 4 VFO’s, and can be set to receive either DMR or FM (aka analog), and looked like this.

I was amazed at the progress Kai had made in only 2 months, because DMR decoding and reception is a very complex task.

His progress wasn’t helped by the fact that the main Digital Signal Processor chip in the GD-77, which both demodulates the 4FSK signal and converts to a DRM data stream, is a Chinese made IC that does not have any English language data sheets or other documentation.

The DSP is a HR-C6000, and the data sheet isn’t even publicly available;  and we have Andrea Contini to thank for managing to obtain a copy of the Chinese language data sheet.

Kai’s firmware was able to receive DMR relatively well, with some occasional lockups, and strange noises from time to time.

In the following couple of weeks, Kai refined his DMR decoding software, which greatly improved the reliability and there are now hardly any lockups or unexpected noises.

At this point I realised that my time, effort and skills would be better employed helping Kai to write his Open Source firmware, than only continuing to modify the official firmware, especially considering that the official firmware was proving to be very difficult to modify, for numerous technical reasons which I won’t elaborate on at the moment.

Kai asked me to write the source code to communicate with the 64k EEPROM and also the 1Mb Flash memory, and also to write a better display driver for the 128×64 pixel back and white LCD screen.

Again, I won’t bore you with the technical details, but it took me about 2 weeks to write these 3 blocks of functionality, which Kai then merged into his main codebase.

I also suggested to Kai, that full blown menu system was needed for his firmware, and I’ve spent most of the last 2 weeks, building the menu system, and then implementing a number of new screens and new functionality, which Kai merged into his master code-base yesterday.

With the result being these screenshots, which are in this blog.

For those of you with more than one GD-77, or the very adventurous with only one GD-77, Kai has uploaded the firmware files to his git repository here

https://github.com/talentraspel/GD-77/tree/master/GD-77_new_firmware/firmware_binaries

With the latest version being downloadable from this link   https://github.com/talentraspel/GD-77/raw/master/GD-77_new_firmware/firmware_binaries/firmware_V0_1.sgl

Please note.

This firmware should be viewed as experimental, and you use it at your own risk.

And currently it is Receive Only

After booting up, the software enters its VFO screen.

There are 4 VFO’s which can be accessed by cycling through using the left and right arrows.

The modulation mode is toggled between DMR and FM aka Analog, by pressing the star * key

The frequency can also be entered manually, like in the official Radioddity firmware.

Pressing the Red menu key, while on the VFO screen, toggles to the Channel display screen, and from the Channel screen the Red menu key takes you back to the VFO screen.

(Note. This functionality differs from the official firmware, which uses the Right arrow, because both the VFO and the Channel screen use the Right arrow key for their functionality

The Channel screen attempts to read the codeplug data that is already in the Flash memory of the radio.

I say attempts, because the official codeplug format in memory is a fragmented mess, and we have decided that there is ultimately no point in attempting to continue to use the official codeplug format within the radio.

The legacy codeplug support which I’ve written is primarily just so that, people can take a look at Kai’s firmware, before we write a new CPS.

The Channel screen differs from the official version, in that it displays the Channel name, in this case “Duplex HS” (for duplex hotspot), and also the TalkGroup to use on that channel ( frequency ).

The TalkGroup is derived from the Rx Group list which is assigned to the channel.

In my case, I made a copy of my existing codeplug, and removed all duplicate channels which were the same frequency, and only differed because they had a different TalkGroup assigned to them.

I also updated my Rx Groups, so that each group contained all the TG’s I want to use with a channel (frequency).

e.g.

I now have RxGroups for DMR MARC Australia, which contains TG’s 505, 3801 – 3810 and TG9, 113 and 123, which are the TG’s supported by the repeater network.

I also have another Rx Group for Brandmeister Australia, which includes TG 505, 5050, 5051, etc, which I use in conjunction with the channel for my hotspot.

Hence I now have need far less channels, and the term “channel” goes back to its more conventional meaning of  “frequency”, rather than being a combination of frequency and other settings (mainly TalkGroup)

To change TG on the same Channel (frequency), I press either the Right or Left button, to cycle through the TG’s in the Rx Group.

For example, I change to TG 3801 by pressing the Right Arrow, since in my Rx Group list for DMR MARC Australia the second TG in the list is 3801.

Just a quick note about TimeSlots. Currently Kai’s firmware is receive only, and does not filter either by TG or even TimeSlot.

i.e It will receive any traffic on any TimeSlot on the chosen frequency.

Obviously in the future, when the firmware is able to transmit, the TimeSlot will have to be catered for.

BTW. I’ve renamed the Rx Group, as a TRx Group, since it will both set the Tx TG as well as the Rx TG.

In terms of the TimeSlot, I can think of at least 2 different ways that this can be handled.

1. Each TG is assigned a TimeSlot from within the Digital Contact screen in the CPS.

2. Or.. When a TG is assigned to TRx Group, the user will also select which TimeSlot to use for this entry in the TRx Group.

I don’t know if there are any situations where the same TG is used on both TimeSlots on the same repeater, but if this is used somewhere in the world, this could be catered for, either by adding the same TG into the TRx Group twice, once on TS1 and once on TS2, by allowing the user to toggle between TS’s on the Channel screen.

In fact, there will definitely be an option to toggle between TG on the channel screen, possibly using the star “*’ key

Looking at the menu system which is now in Kai’s firmware…

Pressing the Green menu key, access the menu system in the same way as it does in the official firmware, but as you can see in the photo below the menu options are not the same

And.. Rather than 2 menu items on the screen at a time, I’m displaying 3, with the centre menu option being the one which will be selected by pressing the Green key again.

Here I pressed the up arrow, to move the Zone to the middle of the screen, then selected it

Looking at the Zones screen, its very similar to the official Zone menu, except it displays 3 zones

Note. My codeplug reading code, seems to not be able to detect zones which have been deleted, so you will see the zones visible in the CPS but also old zones which have been removed from the CPS.

I’m sure I will be able to find out how the CPS stores which zones are active and which have been deleted, but at the moment, this is a known bug with the firmware.

Selecting a zone, transfers its frequency and mode into the Channel screen, even if you are in the VFO screen. This is the same functionality as the official firmware, but it strikes me that perhaps if you select a zone whilst in the VFO, then perhaps the radio should be switched into Channel mode.

Virtually all the rest of the menu options are for new functions,  in Kai’s firmware.

The first new screen is the RSSI, (Received Signal Strength Indicator)

This screen is experimental, and works in both DMR and Analog mode, and displays the RF signal strength, and also a paramater, in the receiver chip (AT-1846S), called “Noise”.

The numerical values which are displayed, still need to be calibrated, and are the raw values from the receiver chip.

Noise appears to be the audio level of the demodulated FM signal.

Hence when there is little of no signal, the Noise value is at its highest of around 60.

When there is a DMR signal, e.g in this case from my hotspot, the RSSI increases to its maximum value, which seems to be approximately 70, and the noise decreases, because its the 4FSK of the digital transmission.

If I transmit using an FM transceiver on the same frequency, the noise is very low, because its a clean carrier with no audio. In my case as you can just about makeout, the value is changing between around 7 and 8.

And the RSSI is again 70, i.e the maximum.

In the fullness of time it should be possible to calibrate the RSSI  e.g. 70 probably equates to 60dB over 9.

The next new screen is the battery voltage, which has some nice large text of the voltage, and also includes a bar graph representing the voltage of the battery, in this case 8.3V is 100% capacity

Next on the list are the display options.

I’ve added PWM (pulse width modulation) control to the LED backlight on the display, so that it can be dimmed, either for continuous operation while in the shack on a charger, or perhaps for night time operation.

I’ve also added a control for the LCD contrast, because I found that the contrast value used in the official firmware, which for the record is 15, is a bit lower than is optimal for my radio’s display, and I have set the default in Kai’s firmware to 17, but I normally adjust it to about 20, which makes the text even easier to see.

Its hard to see in photo’s since my camera compensates for the light level, but here is the display at bightness of 1

And here it is at 60%. Note that the radio and background of the photo are darker, because the camera is adjusting for the light produced by the display.

Reducing the contrast makes for a “washed out” display.

But increasing it too much, causes the background pixels to start to become visible, hence you have to strike the best balance for your own radio.

Another new feature is the “Last Heard” screen.

This operates like the PiStar dashboard, and keeps track of any DMR stations which are heard, and automatically adds new stations to the top of the list, or moves a station already in the list, to the top of the list when they transmit.

In this case I made a CQ call and Alex VK2PSF relied and was speaking when I took this photo.

After speaking to Alex, Peter VK4NBL called me, and I was speaking to him via another GD-77 when I took this photo.

Of course the Channel screen displays the current TG and callsign as in the official firmware.

I forgot to mention, that Kai’s firmware is currently setup to read the DMR ID database which I already loaded into the radio prior to installing Kai’s firmware, and uses virtually the same search method that the official firmware uses; except I found a more efficient algorithm on Wikipedia, hence the callsign lookup takes up less of the CPU’s time and resources.

Before I almost finish this blog post, I must thank Kai again, for his amazing work handling the complex low level part of the operation of the transceiver, which is extremely technically challenging, as well as building the overall software project including the use of a RealTime Operating system (FreeRTOS), and all the other complex technicalities of configuring a microprocessor to run at all.

And what’s next…

Well, my understanding is that Kai has now started work on DMR transmission, but I think this is likely to be an even more challenging task than DMR Rx, so I have no idea of how long this will take him.

I think Kai is better placed to write the Tx functionality, since he has written the Rx functionality, and my time is likely to be better spent doing other things, like writing a new CPS or perhaps implementing things like Text Message reception and Talker Alias reception etc.

The new CPS will definitely be able to read most of the data from the existing codeplug, one way or another, since I know people have invested a lot of time and effort into their existing codeplugs.

But some changes will be needed when moving to the new CPS paradigm, which will almost certainly need to be made manually.

The new CPS will probably be a Windows exe written using C#, so that I can re-use a lot of the screens etc from the community CPS, but I will make sure it runs under Wine on Linux, unlike the Community CPS which unfortunately has inherited some traits from the official CPS which means it won’t run using Wine.

I also have some other interesting ideas of enhancements for both Rx and Tx functionality, but I won’t post about these until I have made some progress with these.

One final thought…

If anyone else out there who has a GD-77, and can program in C is interested in helping, there is still loads of functionality that needs to be written, so please contact me, and I can send you details of the IDE and toolchain etc, (in addition to the information Kai has documented about this in his github repository)