OpenGD77 update

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

Work is continuing slowly with the OpenGD77 and anyone using the Tier2 Alpha, should avoid using the Last Heard screen until I do another release.


I’ve updated the Tier 1 version, with a fix for this, as well as making some changes to the Tier1 version UI to unify the functionality with the Tier2 version.

This includes using Function + Star key to change from FM <–> DMR mode

Also a new feature that will be introduced in the next Tier2 Alpha 2, where during DMR Rx, if the transmit TG does not match the incoming Rx TG, the TG number is displayed in inverse video, (white text on a black background).

In the next Tier2 version, pressing Function when the TG is being shown in inverse video, will change the Tx TG to match the currently received TG.
Note. I don’t have time to put this function into the Tier1 version, as its a large duplication of effort and I am personally no longer using the Tier1 version unless I need to run the GD-77 as a hotspot.


I have also made some improvements to the ID display and most of the time the radio only shows the callsign or ID for stations on the selected TS.


Unfortunately, I have a number other serious problems with the Tier2 version which are currently preventing me from releasing a new version.
There seems to be a problem with the RAM getting overwritten by either part of the OpenGD77 firmware or possibly by the AMBE codec binaries. This problem seems to manifest its self on some people’s radios more than others, and not on my radio at all – which makes it very hard to track down.

Also, there seems to be a problem with the EEPROM access, so that sometimes the CPS can’t upload a new codeplug, and I suspect the codeplug data is sometimes getting corrupted when the settings are saved when radio is turned off.

There is also a bug where occasionally the radio transmits on the wrong timeslot.

And the Tier2 version seems to suffer from audio garbling more often than the Tier1 version. My guess at the moment is that this has something to do with CPU load and perhaps the CPU is not managing to decode the AMBE audio data quickly enough, especially if the BER is high or possibly if some audio frames are actually missing.


Memory bugs are notoriously difficult to track down, especially on a complicated piece of firmware like in the GD-77, likewise real-time bugs like the audio garbling are also hard to replicate and hence hard to bug fix.


So overall, I think its unlikely that I will be able to release a new Tier 2 version in the near future, unless some other developers come onto the project and can investigate the bugs in parallel with my work.

Whilst working on the Tier2 version, I noticed that the Last Heard screen was completely crashing the radio, and on further investigation I found a bug which also effected the Tier1 version.

18 Responses

  1. Cesar Silva

    Even if doesn’t work in a near future , i have to thank you, all the work you did until now!! i’m sure you will find a way to resolve this problem!!many thanks Roger!!keep up the good work!! 🙂

  2. ken

    thank so muvh for all your hard work

  3. Rick

    If Tier is giving such problems, maybe it is easy to activate the single frequency repeater mode to Tier 1 and mmdvm-gateway operation.

  4. Roger Clark

    SRF is a Tier2 protocol

  5. Ingo Buennemeyer

    Hi Roger, thanks for your hard work on the Tier2 firmware. I wish i had the skills to help you investigating the bugs. Concerning the “audio garbling” I found out that it appears when some audio frames via a repeater are missing and seems to be independently of the signal strength. When the garbling appears, I switch down to a FM-channel and then back to DMR so that the audio is okay again. Maybe these hints can help you investigating the garbling issue.
    Thank you again for your really hard work on the firmware. Greetings from germany!

    Vy73 de Ingo, DB4BIN

  6. Roger Clark

    Thanks Ingo

    When I get time, I’ll add some debugging code to monitor whether frames seem to be missing.
    Each DMR frame has a “sequence number”, so hopefully I should be able to check if a frame is missing. However I don’t know if the frame number is sent as part of the signal being transmitted by the repeater, or whether the sequence number I can read from the C6000 DMR chip is just a counter which it increases every time a DMR frame is received.

    If frames are missing, I will need to work out the best way to handle this.

    I think the C6000 generates Timeslot interrupts even if the frame is missing from the repeater, because it seems to go into a sort of unsynchronised / free running mode if the signal is lost.
    So in theory I could possibly maintain a counter in the TimeSlot interrupt handler which is initially synchronised to the sequence number, and if these numbers differ, then a frame of audio data must be missing.

    Either way, I think I would just need to insert silence into either the AMBE compressor input, or probably a more efficient way is simply to fill 60mS of silence into the output WAV audio buffer that the firmware maintains, (which is normally filled by the AMBE decoder)

  7. Mike

    AFAIK the DVMEGA had some similar issues in the beginning when DMR mode was added with later firmware versions. I remember that Guus told somewhere in the changelogs, that he simply repeated the last good frame to fill-in, when a lost frame was recognized for better audio quality.

  8. Rick

    Hi, ok, maybe “SFR” runs under Tier2 in the book. But technically, also as Alister Chapman described on 23/08/2019 at , I think all user devices operate in “direct mode”, unaware of the SFR and without any of the Tier2 protocol needs, like waking up a repeater. It’s not the same but similar to transmitting “direct mode operation” DMR frames over an analog two frequency repeater for smooth migration. The SFR allows for ad-hock support for DMO devices to communicate across some mountains in the field without requiring any reprogramming or channel switching on the user devices.

  9. Roger Clark


    Technically the Tier1 release of the OpenGD77 firmware is not actually Tier1 at all.

    It’s a subset if Tier2 functionality, where the Tx will only work in Tier2 “Active” mode, where the radio acts as the sync master.
    So in this release the Tx does pulse on and off every 30mS.

    However it can not receive in the intervening 30mS, because the entire code structure does not support this.
    Also, the code structure was not able to respond quickly enough to the microsecond timing requirements of anything other than this subset of Tier2 Active.

    I had to completely restructure the code and make radical changes to support Tier2 Passive operation, where the repeater is the synchronisation master.

    Hence SFR will never work with the original “Tier1” firmware.

  10. Roger Clark



    I will eventually investigate how to handle missing frames etc, however at the moment the code is not stable and crashes on some older radios

    There are some underlying problems with memory corruption, even in the “Tier1” release, which are now becoming more of a problem as the RAM usage increases and there is more chance of an important bit if RAM containing some variables becomes overwritten.

    In the “Tier1” release Kai had to disable all compiler optimisation, as this seemed to fragment the memory map and the bugs went into hiding.

    However this is not a satisfactory solution anymore, because Tier2 “Passive” requires more processor power to handle the increased loading of both slots being active and the higher resolution of timing that is required, hence running the code without optimisation , hence making it run more slowly is not really a viable option.

    Hence I now need to spend a lot if time tracking down these legacy problems

  11. Rick

    Thank you for explaining. I can now much better understand your original post, considering cpu load problems can be the cause for many problems with time slot relevance.

    Not sure how sophisticated you’ve made the code already. So probably an idea you already had. Could you make the firmware only do other things than the high priority time relevant tasks, after the priority tasks have completed (or its time allocation timed out) and the task toggled some semaphore to start processing the pending lower priority tasks in the time remaining until the next frame? (Make stream processing slow down all other things, but memory management.)

  12. Rick

    > I now need to spend a lot if time tracking down these legacy problems

    But solving the timing things should be beneficial in any case. So, there are good grapes. I mean even in Tier 1 the flexible “double capacity” direct mode, using a prefered or the next-free-timeslot for TX, and RX on both, has been out there for some time.

  13. Roger Clark

    Its all beneficial, but from the outside it looks like there is no progress, because the firmware works fairly well for most people

  14. Rick

    Therefore, thanks again, your explanations are wonderfully appreciated! 🙂

  15. Roger Clark

    No worries

    Through having to write the firmware to control the HR-C6000 DMR DSP chip and also to write Hotspot mode, I’ve realised that DMR is quite a complicated protocol and that most operators are oblivious to the underlying complexity.

    Also, I’ve not found an easily readable technical description. Either the descriptions are totally over simplified to make things vaguely understandably, or at the other end of the scale is the ETSI specification documents which are both hard to read and also lacking in details of how to implement the protocol.

    Additionally the DMR spec does not actually mandate a particular audio codec etc, but the key commercial players chose to use AMBE.
    I have a feeling there are probably other aspects of the DMR protocol which have been dealt with in the same way

  16. Rick

    > I have a feeling there are probably other aspects of the DMR protocol which have been dealt with in the same way

    Agree, the timeslot handling in Direct Mode seems to be another example. Fixed separation of logical timeslot channels (based on a sync master or peer election), versus sharing the channel (capacity) by flexible timeslot usage (possibly only relative to current rx timings).

    The protocol difference may be rather DMO vs RMO than tier1 vs tier2, and then maybe infrastructure managed (channel) operation (tier3).

  17. David

    Hi Roger and thanks for all your work.
    Is there any possibility to create an option to change the appearance of the display, making the screen normal or reverse? You know black or white 🙂 Thanks again.

  18. Roger Clark

    Its only partially possible to do this.

    The part of the screen which has the pixels can be swapped, in fact I think the display chip has setting to enable inverse video for the whole screen.

    But there would be a white border around the outside of approximately 5mm, because the pixels of the display does not go completely to the edge, also the blackness would not be as dark as the GD-77 with an inverted display, because they use a completely different LCD panel in that radio.

Leave a Reply