GD-77 ongoing development of enhancements

posted in: DMR, GD-77, Ham radio | 4

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.

4 Responses

  1. ken
    |

    looking good, all i aminterested in is callsign and name, but thats just me,cheers

  2. EvO
    |

    Hi Roger.
    Honestly I had also thought of such a solution.
    From my side the replacement of the SPI flash would be very simple to implement, practically the so-called Columbus’s egg.
    I don’t understand anything about programming, but I get along very well with the welder.
    That would really be the simplest and cheapest solution.
    When it is I will surely implement it.
    Thanks for your great work Roger, please keep it up!

  3. Les Hazeldine
    |

    Many thanks for your ongoing work on the GD77. Personally I am happy with just name and callsign for Australia.
    All the very best,
    VK4TB

  4. Roger Clark
    |

    Hi Les

    I have 3 different levels of modification to the official firmware

    The first level just increases the number of characters per DMR ID record, and also doubles the memory available for the DMR ID storage
    The second level includes level 1 and also fixes the Rx Group = None problem, so that it uses the Tx Contact as part of the Rx Group checks, and hence you no longer need to use an Rx Group
    The third level add direct entry of Talk Group number via the keypad – However, the problem I found with this, is that there is a bug in the official firmware which causes the text of from the screen, where the channel name is normally displayed, to be saved back to the codeplug. And I use the space on the screen where the channel name is display, to show the TG number you enter.
    So the channel name keeps getting changed to “TG ….” depending on what number I enter.
    The only way I found to stop this, is to disable all saving to the non-volatile memory. But this has a big side effect, in that the radio no longer remember whether its in VFO or channel mode, and also won’t remember which channel in the zone, was last selected.

    Consequentially, this last version does not suit everyone, but a lot of people are willing to put up with the side effects, because they want direct TG entry.

    At the moment, I’m no longer working to try to enhance the official firmware, because it was taking more and more time, for less and less gain, and I have moved all my efforts to Kai’s open source firmware, which is progressing well, but is a slow process.

    I will be doing a post about the status of the open source firmware fairly soon, once we iron out some more of the bugs.

Leave a Reply