GD-77 8M byte memory hardware hack

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

Just a quick post on a hardware hack that’s possible, but quite difficult, on the GD-77 to increase the internal memory from 1M bytes to 8M bytes


The GD-77 memory consists of these 2 chips


(Photo curacy of Jason VK7ZJA’s website, since I forgot to take a “before photo”)



The chip on the left is a Winbond 25Q80, 1M byte (aka 8M bit) SPI flash memory

The chip on the right is Atmel 24C512 (or possibly a equivalent device) which is a 64k byte EEPROM.

The EEPROM is used to store half of the codeplug (things like the basic settings and the Zones)

The 1M byte Flash chip is used to store the top half of the codeplug, and the calibration data, as well as one of the display fonts, and also the DMR ID


The 1M byte Flash chip is almost 100% utilised and there is no room left to store, either more codeplug data or more DMR ID data.


The main limitation is the DMR ID data, because even in the version of the official firmware which I modified, I could only store around 15,000 callsigns + names, whereas the entire DMR ID database is now around 130,000 callsigns.


Looking at what other flash memory chips were available, I found that Winbond make devices with more memory, which are software compatible with the 25Q80, but unfortunately are not in exactly the same physical package.


However it is possible to bend the legs under the larger package and solder the 25Q64 in place of the 25Q80, and upgrade the radio to 8M bytes (aka 64M bits) of main memory.



Or course, just increasing the memory size does not make any difference unless the firmware is also changed, so that the addition 7Mb of memory is used.


So I modified the official firmware, so that the DMR ID data was stored. Rather than address 0x30000 (hexidecimal) I changed it to 0x100000 (i.e the 1Mb point).

I also changed the DMR ID maximum size from 128k to 7M bytes.


The next thing to change was the DMR ID section in the Community CPS, to upload the data to the new location, and to remove the data size limit.


With these changes in place to the hardware, the firmware and the CPS, I was able to download the DMR ID for multiple regions, and in the end I found that the data from, (which I use for the DMR ID system in the community CPS), seemed to only show around 60,000 active callsigns on DMR in the last 12 months.

So I uploaded that data to the GD-77; rebooted it and used my hotspot connected to Brandmeister to listen to various TG’s around the world, to test whether the DMR ID system was indeed storing 60,000 callsigns…..


Which it was.


So far so good except for two problems. 🙁


  1. The official CPS upload speed is very slow, both for the codeplug and also for the DMR ID, because it uses the same system to transfer the data.

    The speed to upload data appears to approximately 10,000 IDs per minute.

    Hence it too between 6 and 7 minutes to upload the 60,000 IDs, and for the full 130,000 DMR ID’s which I could download from, it would take approximately a quarter of an hour to upload to the radio.

  2. The data that the Community CPS uses, is downloaded from, because I use the filtering available on their servers, to select which region’s ID’s to download. For example all ID’s starting with 505 for Australia.

    I’ve found that its not practical to download the entire DMR ID data for all regions from ham-digital, because it seems to take too long, and the download times out.
    And.. even when I managed to download data on all regions, from ham-digital, by downloading each region separately e.g. all ID’s starting with 1, then all ID’s starting with 2 , etc.  I found the total was only 60,000 rather than the expected total of at least 120,000

    So to make use of the additional memory, I would also have to change the CPS to download from, including changing the CPS to read the different format in which the data is delivered.


Unfortunately, I don’t think I am going to be able to modify the official firmware so that it uploads any faster, because this is intrinsic in the way the firmware operates, using a Real Time Operating System to handle the USB, which it does in thousands of small 32 byte transfers.


So currently, I think this modification would only be useful some time in the future, using Kai’s firmware.

And with Kai’s firmware, the extra memory may not be absolutely necessary, since the codeplug size is likely to be much smaller, since it does not need multiple duplicate channels, and won’t store the font etc in the Flash memory.

This would probably allow around 700k to be allocated to DMR ID storage, which could allow for around 60,000 ID.


Also, if more radio’s start being able to transmit DMR “Talker Alias”, the DMR ID system may eventually be redundant, because “Talker Alias” allows 31 characters of additional data to be sent with the transmission, and this would be plenty to store the callsign, name and some other information e.g. location locator.



So although this was an interesting technical exercise it appears to be a a bit of a dead end at the moment

7 Responses

  1. Hugo

    With the new software, will it be compatible with changing the memory in the gd-77? Would it be possible, for example, to increase the number of channels and the number of DMR IDs? Otherwise, it’s useless to make the change in the hope that this brings a real change

  2. Roger Clark

    I’ve experimented with using the extra RAM for DMR ID’s on both the OpenGD77 and a modified version of the official firmware, and it worked OK.

    With the OpenGD77 firmware, since you don’t need to have 1 channel per TG per frequency, I would be surprised if you need more than the 1024 Channels that the existing codeplug format can accommodate.

    Before using the OpenGD77, my codeplug had around 500 Channels in it. And now has around 100 channels.
    And that includes 40 UHF CB channels which are receive only.

    Assuming you have 10 TG’s per channel (I have 12 TG’s the local repeaters support), the number of DMR channels you need is only 10% of what you need with the official firmware.

    In the longer term we may migrate the OpenGD77 to its own codeplug format, which would allow each section to have a variable number of items e.g. a variable number of channel, variable number of channels per Zone, and variable number of channels per Rx group, and this would allow for more efficient use of the 1Mb memory, and expansion into the 8Mb.

    At the moment the OpenGD77 firmware does overwrite any part of the Flash memory which the official firmware uses. Hence its possible to reload the official firmware back onto the radio at any time.

    However, in the longer term, we will probably begin to make use of the memory that the official firmware needs but which the openGD77 doesn’t, eg the display bitmap fonts are stored in the 1Mb flash chip in the official firmware but we use bitmap fonts compiled as part of the firmware to save space in the Flash.

    Since the codeplug only takes 128k of the 1Mb flash, and the only other thing that the OpenGD77 needs from the Flash memory is the calibration data, which is only around 256 bytes.

    896k of the Flash could be allocated for the DMR ID and if we employed some mild compression to the callsign and name texts (which are a max of 15 characters long).

    This would allow the Flash to store around 60,000 DMR ID’s (Callsign and name)

    Also, on Brandmeister the DMR ID database is partially redundant because the OpenGD77 supports reading the callsign from the Talker ID data, which is sent as part of the DMR data or signal.

  3. Hugo

    Do I understand correctly that there is currently a modified version of FW 3.2.2 that allows at least to have more DMR IDs?
    On the other hand the channels will be identical (1024).

    A variable number of channels per zone would be really appreciated.
    Same thing when there is conversation on a TG, we would only need to make a PTT and it is recorded. Same thing during a scan, when you do a PTT, the scan stops at the place where there is a signal and records the TG allowing to transmit immediately.

    It would be equally interesting to allow the increase of the channels and to add more DMR IDs if the change is made.

    Or to get more DMR information by scrolling the information on the screen …

    Many ideas;)

  4. Roger Clark


    I’ve emailed you my modified version of the official 3.1.8 firmware.

    See the email about the benefits but also the disadvantages of using that version.

    Re: Scanning

    Various people have told me about that problem.

    However I’m no longer working on modifying the official firmware, because its extremely hard to made modifications without breaking any of the official functionality.

    100% of my effort is now on the OpenGD77, and I will be able to implement the scanning feature, which will do things correctly.

    But I have a huge stack of things on my OpenGD77 ToDo list before I get to scanning functionality, and I never personally use scanning.

  5. Hugo

    Thank you for sharing.
    On the other hand, when scanning, it would be interesting to give only one PTT shot so that it stops on the frequency instead of having to select it. In mobile it’s more safer …
    But I understand that it is better to work on the new FW than to modify / hack the old one ….

  6. gruetzkopf

    Hi, i just got myself one of these radios. The largest memory in the 208mil SOP8 package (as your 64MBit chip) from the W25Q series of flashes is the W25Q256 – 32MByte! Accessing the upper 16 MBytes can either be done using 4-Address-Bytes-Commands or – maybe more interesting – by setting a bit in some config register ! (May be useful for A/B codeplug selection at boot)
    What i’l like to to in that case would be to move all calibration data to the i2c eeprom (maybe even replacing that too), so you can recover from blank SPI flash easily.
    Do you have the codeplug memory maps written up somewhere?

  7. Roger Clark

    Jason VK7ZJA posted a memory map.
    Try looking in his

    gd-77 tuneing


Leave a Reply