GD-77 Official firmware v3.2.4 seems to have major problems

posted in: GD-77, Ham radio | 23

I’ve been hearing reports for a few weeks about problems with the ham bands being locked in the latest official Radioddity GD-77 firmware, but I assumed these were isolated incidents possibly caused by problems with the codeplug.

However I received an email this morning from Jason VK7ZJA who has done an analysis of the new firmware and he has concluded that there are potentially quite serious problems with this firmware.


After installing the official firmware version 3.2.4 the ham bands are locked,but it should be possible to unlock them by holding down some keys when the radio is powered on.
A text file that is part of the installation package has the following text in it


Note: Two ways to unlock frequency range
I. Press “SK1” + “7” key to turn on the radio – Press “Menu” to restart
II. Downgrade to old firmware version (before V3.2.1)


However with firmware version 3.2.4 pressing SK1 and 7 does not seem to fix the problem people are encountering, where the radio displays the message “Tx disabled” when the PTT is pressed.

Jason did some analysis of the EEPROM and Flash memory in the radio after firmware 3.2.4 had been installed, and found that the memory locations normally used for the RF calibration data appear to have been overwritten with part of the DMR ID database.

Jason could not find a full copy of the calibration data elsewhere in either the EEPROM or the Flash memory.


If the RF calibration data has been corrupted this is a serious problem, with no perfect way to recover unless the owner of the radio had previously backed up their EEPROM and Flash memory either by using FlashManager or my installing the OpenGD77 firmware and using the backup facility in the Community CPS.


My recommendation would be to NOT update to version 3.2.4

For those who have already updated and potentially partially bricked their radios, there is a potential way to recover the radio by loading someone else’s calibration data into the radio, but since each radio is supposed to have different calibration parameters, this isn’t guaranteed to work.

Also, of course prior to loading someone else’s calibration data the radio should be loaded with an older stable version of the official firmware, for example version 3.1.8


23 Responses

  1. ken

    thanks for the info

  2. K7XRL

    I’ve been afflicted with this unfortunate v3.2.4 issue. I ordered a new GD77 and I am going to try to copy the calibration data from the new radio onto my old one using the flash tool when the new one arrives. I guess I will need to install the same firmware version the new one ships with before making the attempt. I know the calibration won’t be the same for each radio but I am hoping it is closer than the default values. For now my radio works on v3.2.2 but I haven’t done much transmitting.

  3. Roger Clark

    I keep a library of calibration data, which I can email to you.
    Actually its complete backups of the Flash from various people’s radios, but its possible to just upload a 64k section of the 1Mb which has the calibration data in it.

    I’ve compared the calibration data between several radios and there’s not usually much difference between them
    The main differences are ..

    The power level , which is never accurate and not that important
    The master clock frequency. This varies a little form radio to radio but not much
    The DMR FM deviation levels. This changes a bit, but again not very much

    I find with one of my radios, that when I use my OpenGD77 firmware that I it works better if I just go with the firmware default values, and I don’t read anything form the calibration data.
    But normally the radios work better when they have the correct calibration values

    Either way, I’m sure it will be possible to get the radio going again.

    I’d also recommend that unless there is something specific in firmware 3.2.x that you need. That you go back to an old stable version like 3.1.8

  4. Bruce Albert

    One of the problems that was supposed to be fixed in 3.2.4 is that in 3.2.2, choosing a talkgroup from the contact list over contact #256 will revert to an under 256 group, and I had noticed that, and it made the radio about useless. Roger, I believe you mentioned elsewhere that you had a modified 3.1.8 that allows for entering TGs manually; is this publicly available? At least until OpenGD-77 supports SMS, which I do need and use. Thanks.

  5. Pardo Vitulli

    Unfortunately, I have been one of those affected… I tried going back to 3.2.2 and 3.2.1. As you stated; “Tx Failed…”

    I will find the 3.1.8 and see what happens but I suspect I will need to flash a calibration data set… Will need to figure out how to do that. Then I may ask someone for either the default values or the most common.

    Who knows. Maybe Radioddity will eventually post a fix?

  6. Roger Clark

    I better write a blog post or do a video about how to recover from this problem.

    I got more information from Jason VK7ZJA. The calibration data definitely gets corrupted, so Radioddity would not be able to release firmware to totally fix the problem

  7. Roger Clark

    Someone else asked me the same question and I already posted a reply, but it must be a reply to a different blog post

    The file is available, it’s in my Radioddity GD77 repo on github in the firmware folder in a sub folder called “modified official”

    I will do a separate post about it, explaining what it does and the one small disadvantage of using it

  8. K7XRL

    Got this from Radioddity support this morning:

    Dear Ronald,

    Thanks a lot for reaching out to Radioddity support, I am Vevina.
    I apologize in advance for my late reply due to the weekend break.

    I forwarded your feedback on the latest firmware to the technical team, being told that the bug you mentioned is being urgently fixed now. We will upload the new firmware after the bug has been resolved.

    To better use your GD-77 radio, please downgrade to firmware to the old version.

    If there is anything I can do for you, please do not hesitate to contact Radioddity support to get timely help.

    Radioddity Customer Service

  9. Roger Clark

    I don’t think downgrading will work.

    They appear to have corrupted the main RF calibration data with this firmware.

    They will not be able to do a firmware fix for it, unless the firmware puts some average data into the RF calibration memory locations.
    And even then it would not be guaranteed to work.

  10. K7XRL

    I received this message from Jason last night:

    “Ron I just checked your flash backup, and your RF alignment table hasn’t been trashed. You’re all good to go. The VOX issue might be fixed if you set the VOX sensitivity to a higher value? (it’s a bit counter-intuitive, the higher the value, the less sensitive the VOX is). Zeroing in on the byte causing the “be inhibited” issue… looks like it’s byte $FC (specifically bit 3 of that byte) in the codeplug. Problem is, the MCU intercepts any attempted changes to that bit and prevents it from being modified! Going to be a tough one to crack, I think.”

    However I can’t remember if I tried v3.2.4 again after having sent him the .bin file he examined. I hope not, but I don’t want to bug him sending another .bin file to look over. In any case the radio does appear to be working on earlier firmware.

    The VOX issue still persists, regardless of firmware version or VOX level setting. I suppose it could be a hardware problem but It doesn’t make sense as this radio has been stored on a cool dry shelf indoors since I bought it. If it’s a hardware failure, it has to have been this way from the factory.

  11. Roger Clark

    Hi Ron

    You are lucky.

    Jason said it had trashed his RF calibration data

  12. Jason

    I think my experience with this upgrade represents the extreme worst case scenario. The pre-existing conditions with my GD-77 were that the flash memory had been filled with a simple test byte pattern to determine what memory was free and potentially available for future use to store more DMR IDs. That included a test byte pattern where backups of the RF calibration data would normally be (I had my own backups, so that is OK). All operational data in flash memory remained as is, of course.

    Others who have not had their upgrade go smoothly have forwarded dumps of their flash memory to me, and their calibration data block remained intact, as did the typical internal backups. Their main problem is the “TX inhibit: be disabled” error message, which can then be resolved by downgrading firmware version.

    I believe bit 3 of byte 0x00FC in the codeplug is the culprit for this “be disabled” error, going on analysis of the EEPROM and flash memory contents. Manual manipulation of this bit and then writing to the radio does not appear to work, the firmware intercepts any attempt to change that bit (and a few other bits in the same byte) and prevents any changes from being made. The only way I was able to change that value was via a memory reset where the radio copies it’s last known good codeplug into active memory. Or, as mentioned above, downgrade firmware to an earlier version where that bit’s value is ignored for TX functionality.

    So I do hope that the erasure of my calibration data block represents the very worst case scenario of what could go wrong with v3.2.4 firmware upgrade. I’m lucky in that I can easily recover from that. Given the potential for this to occur, as well as the “be disabled” TX error, I think that should give every GD-77 reason to reconsider attempting to make use of this version of firmware.

    It seems Radioddity are of the belief that their official versions of firmware for the GD-77 are reaching a state of maturity (present bugs excepted!) and the next firmware update from them is likely to be the last we’ll see, in my opinion. OpenGD77 development continues apace, something that has been written from the ground up with efficiency and functionality in mind – this is the cutting edge for the GD-77 radio, and is definitely a worthy alternative to the ‘official’ offering.

  13. Roger Clark

    I’m not sure I’d personally want to risk upgrading to this version unless I’d already taken a backup of all the Flash memory

    Also… I think you’ve indicated that this latest official firmware does not seem to fix some of the bugs they claim it fixed.

  14. Noni

    I had the same problem and I (somehow blindly) solve it by downgrading to 3.1.6, which did not unlock tx, followed by a factory reset and the upgrading again to 3.2.4. It worked, no setting or memories were lost.

  15. Roger Clark


    Sounds like it doesn’t always overwrite the RF calibration data

  16. IU1INZ

    How do you find out that calibration was erased (without looking at the flash dump, of course)? What are the symptoms? I have spurious VHF transmission, much more than UHF. My BER on UHF hotspot is steady.

  17. K7XRL

    In case anyone is interested in the VOX issue, I discovered last night that the VOX works as long as you have “double wait” (dual standby/dual watch) enabled. When you disable it, the VOX exhibits the odd behavior where it turns the transmitter off and on repeatedly. This VOX malfunction also happens when you select “single wait”.

    I emailed Radioddity tech support this new info and they responded and said they would forward it to their tech team.

  18. Roger Clark

    I think if the calibration data gets trashed, the RF is broken on both UHF and VHF.

  19. Chris

    Hi Roger

    I followed the process Noni’s process and managed the recover my GD-77 with no ongoing issues.

  20. Torben

    Seems that Radioddity has released firmware 3.2.6

  21. Roger Clark

    Thats strange.

    I had reports of people receiving radios with version 4.02.05 installed on them, and AFIK a version 4 of some kind had been sent to Radioddity’s Beta testers

  22. F1CXG Thierry

    I recovered a GD 77 in 3.2.4 with the problem “Tx disabled”.
    I installed the latest version of OpenGD77 and my code plug and
    the GD77 works normally, the calibration data
    seem ok and conform to the “standard”


  23. Roger Clark


    Your calibration data must be OK.

Leave a Reply