Radioddity GD-77 DMR transciever – initial observations

posted in: Ham radio | 26

I received a Radioddity GD-77 Digital Mobile Radio, handheld transceiver, as a Christmas present, for use with Ham radio,  and have spent several weeks setting it up, and working around its various quirks, so I thought it would be useful if I documented some initial observations.

 

Before I describe the potential problems, I’d like to say that so far, after 3 weeks of use, I really like the radio. Its RF performance seems great, on both Tx and Rx, and people keep telling me that the audio quality is excellent.

The radio currently have some things which could be improved, but as most of these are related to the firmware, I think that they will eventually get fixed.

e.g. Squelch only has 2 levels, normal and tight; and even “normal” is actually too tight, because if I switch to “monitor mode’ on FM, I can hear stations just fine, which are below the “normal” squelch level.

The PC software is very clunky, and there is only a PC version, but again, over time I’m sure this will be improved and other people may write replacement PC software, in the same way that CHIRP is used in preference to most manufacturers own software other transcievers.

 

Anyway. Lets get started with some important things that you should know.

 

Before the radio can be used the channels and a myriad of other settings need to be configured. I think it may be theoretically possible to set everything up using the numerical keypad on the front of the radio, but this would be totally impractical; hence the radio some with some PC software and a USB programming cable, which allow the settings (called a Codeplug) to be configured and uploaded to the radio.

The Codeplug can also be read back from the radio if required.

The Codeplug can also be saved to disc and opened from disk. The format of the Codeplug (.dat) file is binary… More on this later.

 

The first thing to note, is that the PC software (aka CPS), is matched with the firmware inside the radio, hence if you update the firmware, you also need to use the matching CPS.

Also, for the versions of CPS I tried, the Codeplug data file is matched to the PC software. i.e the new CPS will not read the old Codeplug 🙁

 

I would recommend that the best thing to do after receiving the radio is to update to the latest stable version of firmware and also to use the matching CPS software. Otherwise you will end up spending ages building a Codeplug file, only to find you can’t use it after you update.

 

At the time of writing the latest firmware for the GD-77 is 3.0.6 and the CPS is 2.0.5. I don’t know why Radioddity chose to use different version numbers for this. It would make more sense for them both to be 3.x.y, even if the .x.y bit didn’t precisely match between the firmware and the CPS

 

Problems with firmware update

 

I’ve been told my several people that after having updated the firmware, that the transmitter would no longer work. They could receive, but the transmit power was virtually zero, as if the PA had failed.

This sometimes gets referred to as “TX inhibit”

The fix for this appears to to downgrade to the previous version of firmware (2.6.3) and use the previous version of CPS to upload a minimal code plug, with just one Analog (FM) channel. This seems to clear some settings inside the radio and Tx works.

The firmware can then be updated to 3.0.6 again, and things apparently work OK.

Note. Performing a factory reset with version 3.0.6 installed does not fix the issue, nor does loading a code plug from someone else’s GD-77 that works fine for them.

It looks like the factory reset does not adequately reset all internal settings and whatever is causing the TX inhibit issue is not data that is inside the Codeplug.

 

I did not personally experience this problem, as I updated to 3.0.6 fairly soon after receiving the radio, and its possible that a the people who reported the issue were using firmware versions 2.6.9 and 2.6.8  which may have had a bug – as I noticed that Radioddity removed those versions from their website.

At the time of writing the stable firmware versions seem to be 1.1.6, 2.6.3 and 3.0.6

 

 

USB Charger is NOT a 5V USB charger !!

Not something I discovered myself, but its important to note, that the “USB charger” power adaptor, that is supplied with the GD-77, outputs 12V on the USB connector!

I measured the voltage as 11.7V on the one I have.

To avoid problems in the future by accidentally attempting to use this PSU / Charger to charge a USB device e.g. a mobile phone, Its important to make it impossible to detach the cable from the power adaptor.

The simplest way to do this is probably just to put some tape around it, but gluing the plug in place would also be a good solution. I have some glue sticks which are black rather than the normal transparent versions, so I’ve used black hot glue to hold the plug in place, as it looks a bit neater, but anything that can stop the plug being removed would work.

 

Also, the power supply has 2 round mains pins, which means for most people they’ll need to use the mains connector adaptor which is supplied. This is often a very dangerous item as well, because its possible to only plug in 2 of the 2 pins, leaving the other pin exposed, and that pin will have mains voltage on it.

I have glued the power supply into the adaptor plug.

 

Charger is only a charger

Its important to note, that the charger can be damaged if you try to transmit while the GD-77 is the cradle and on charge. I heard from VK3TY (Nick) saying that his charger was damaged, when he accidentally pressed the PTT while it was on charge. I have pushed PTT several times when my GD-77 was on charge and have not had this problem, but I suspect perhaps my GD-77 had a fairly full battery at the time, hence the total current required was less than the buck converter could supply.

I think potentially this problem is being caused by RF injection back into the power supply, which may cause the charge current limiter to malfunction, and hence demand more current than can be delivered.

Either way, its probably best to avoid transmitting while plugged into the cradle.

 

I’ve also heard reports that the cradle creates a lot of RF noise on the supply which can make the GD-77 somewhat deaf. Again, this is not not something I have personally experienced, but I have not tested to see if it makes any difference to low signal strength reception

 

The charger is known to have other problems, like charging the batteries to 8.55V rather than 8.4V, however I’ll write a separate post about the charger.

 

Edit.

I have double checked my charger, and I the LED turns green when the voltage to the battery gets to 8.39V (probably 8.4V assuming my meter is not super accurate).

So it does not look I need to make the modification as described on this page http://radioaficion.com/news/tyt-md-380-battery-charger-modification/

The component values seem identical on my PCB to those in the linked article, so perhaps the problem is related to tolerances of the resistors and the buck converter.

 

PC software quirks (v 2.0.5)

The PC software appears to have a number of quirks. Including erasing the Contacts inside some of Rx Group lists. In one instance I read back from the GD-77 and some RX Groups lists appeared to be empty, yet the radio was receiving perfectly OK using those lists. So I’m not too sure whats going on.

I suspect the software is simply not displaying the data in the Codeplug file correctly, rather than the RX Group list being empty

 

Monitor function

The monitor function, is a new feature, which I think was added in firmware version 3.0.6, On Analogue channels, it opens the squelch, and on digital channels its supposed to enable promiscuous mode,  where the RX Group list assigned to the channel is ignored and all traffic on the selected Timeslot on the current channel will open the squelch and be audible.

 

I have additionally found another thing which the Monitor feature may be doing. On Analogue channels, it looks like the receiver recognises when there is digital data on that channel (frequency) and does not open the squelch. However pressing the monitor button seems to open the squelch so the digital data tones can be heard. I’m not 100% certain that this is what its doing, as its possible that the signal I was receiving was below the squelch threshold even though it seemed to be a very clear and strong signal, so I’ll need to do some more testing, but that’s my initial impression of what its doing.

 

Extending the operational frequency range

The GD-77 is listed as having a maximum operating frequency of 470Mhz, however I read in various placed that this is a semi artificial limit and the maximum frequency is set in the codeplug .dat file

 

Note. Changing these settings may potentially damage or “brick” your radio, so you do so at your own risk.

 

The values are stored in a strange format and the location varies depending on the PC software version.

In version 2.0.5 the values are stored from byte location 0x000080 like this,

00 04 20 05 36 01 74 01

 

Where the 04 00 means UHF lowest frequency 0400 Mhz

In my case I have modified the file, so the next two bytes are 20 50 =  0520 Mhz

Then 36 01 is 0136 (136Mhz) VHF lowest frequency and 74 01 is 0174 (174Mhz)

 

However, if you open the Basic Information screen in the PC software after having edited the Codeplug, the values will get set back to the defaults for the software e.g. max frequency 470Mhz

 

So, rather than editing the Codeplug, I thought I’d try and find where in the PC software, the max frequency limit is stored, and to cut a long story short, the value is stored in Little Endian format, as a 16 bit number in locations 0x3e6ef and 0x3e6f0

I’ve changed  my values to 0x08 0x02 as this raises the limit to 520Mhz. I have not tested whether the transceiver works at 520Mhz as the VFO may not lock on all radios.

But I have successfully tested into a dummy load on the Australian CB frequencies of 476Mhz, so I think this is a valuable addition to the GD-77 capabilities for emergency use etc.

 

For those who want a bit more detail, I used HxD to search the exe file looking for possible candidates for where 470 was stored, I looked for the same bytes as stored in the Codeplug, but could not find them, or if I could… changing them did not change the limit.

So I then looked for 470 as a binary number in Intel format, but found around 20 occurrences in the exe of those two bytes. By doing a global search and replace to change all of them and lower the limit by 1Mhz, I was able for confirm the data was stored in one of those occurrences, however this also cause the program to crash and was just a quick test to see if I was on the right track as obviously the other 19 occurrences should not be changed as they perform some other purpose, and are potentially executable code.

So I had to go though the file, changing each occurrence, one at a time until I found precisely the one that it uses to store the max frequency value.

 

The location of these bytes is likely to change in future versions of the software, so I’ll need to do the same thing all over again when a new version is released, but it may be easier next time, as I can potentially search for a longer byte pattern, as I know the values of the bytes that surround this data.

I don’t know where the lower limit for UFH is stored, but is likely to be close by, and I can see an 0x90 0x01 at locations 0x3e698 which is a potential candidate. but there is also the same pattern at 0x3e6d2

 

 

I have more information about the PC software and the Codeplug data file and the changer etc, but I’ll write information about those in separate posts

26 Responses

  1. EvO
    |

    Hi Roger,
    Thank you for your really interesting examination!
    The battery charger of mine GD-77 required the 390kohm additional resistances.
    Very good, please go on like this!
    Many thanks Roger.

  2. Roger Clark
    |

    No worries.

    One other snippet of information someone told me, was that they tried to use a 10V power supply, instead of the 12V one from Radioddity, but the charger didn’t work.

    It would be interesting to know the upper limit of voltage, as it may be possible to make a simple cable to charge from a car lighter socket; however cars often charge their batteries to between 14V and 15V in some cases, which could potentially damage the charger.

  3. Jakub
    |

    Hallo, please I have a bigger problem than I hoped for. When I upgrade to FW v3.0.6 from radioddity website (direct from v2.6.8), the radio did not transmit a signal or transmit but very weak and very disturbed. Then I downgrade back to FW v2.6.8, but the radio has the same problem – it transimt only a very weak signal. Before I upload FW, I have always done a factory reset. Radios with problem have SN: 1708A02xxx and 1709A05xxx. Please, have you got a some tip for repair?

  4. Roger Clark
    |

    I had the same problem caused when I uploaded a faulty codeplug.

    From what I can remember, I reloaded firmware version 2.6.6 then updated back to 3.0.6 and it was OK after that

    You may need to reload 2.6.6 then upload an empty codeplug using the matching CPS, then update to 3.0.6

    Note. Radioddity have removed many versions of the firmware from their website

    https://www.radioddity.com/radioddity_download/#

    I can now only see version 2.6.6 and 3.0.6 on that download page. However the confusion is that they have multiple download pages and some seem to contain out of date information and old versions of firmware with serious bugs in them

  5. Jakub
    |

    Thank you very much for the rescue. I thought I had only two bricks. Now it looks like they’re working properly. It is strange that the update goes just from v2.6.6. I must be careful in the future with update. Thank you very much Roger.

  6. Roger Clark
    |

    No worries

    I had to downgrade my GD-77 back to version 2.6.6 again yesterday when I accidentally uploaded a codeplug with a problem in it.

    The problem is really the bug in version 3.0.6 of the firmware, where its internal Factory Reset parameters are badly wrong.

    I presume sooner or later Radioddity may fix this.

    In the mean time various people are investigating if we can fix the firmware ourselves, but unfortunately its encrypted, so its going to be very difficult, and potentially impractical / impossible to get an encrypted copy of the firmware which we can patch to fix this.

    BTW.
    I’ve been working on an improved CPS that fixes some other known issues…

    But I’ll do a separate blog post about this.

  7. Roger Clark
    |

    Michael

    I looked on my hard drive and found some files relating to the ID100HR and I’ve zipped them up and put a link in the end of this blog post.

    Note this code is probably a bit of a mess as its really just intended for me to get a basic idea of how to run code on the watch.

    The files may or may not work for you.

    The main problem is that back in 2016 I would have been using the Core written by RedBearLab and I recall having to modify it and use my own version, which I put on github.
    That core is now obsolete as its been superseded by Sandeep Mistry’s core.

    The code seems to use SFE_MicroOLED.h which is part of RBL’s core (at least in a backup / archive copy I have of that core)

    So I’m not sure how much use the code is going to be.

  8. Hi Roger
    I have problems with the VFO section of CPS for GD-77, I can not preprogram any channels in VFO-A or VFO-B Rx freq will be blank when switching between them.

    Regards Roger de SM0LTV

  9. Roger Clark
    |

    Hi Roger

    Is this bug in the official CPS as well as my version, or is this a new bug in my version.

    Can you explain a bit more about the bug… as I don’t really understand what you mean .

    Thanks….

  10. Jakub
    |

    Hello Roger,
    I think, this bug is in FW, no in CPS. Because when I setup VFO in CPS (using original) and then I will go into VFO in TRX, VFO is always on 400 MHz. But no matter what I was set up in CPS.

  11. Hi again!

    In the bottom part of the tree view, there are VFO VFO A and VFO B, but I can not enter the Rx and Tx frequency in them so that they are saved. When I click VFO B and back to VFO A, Rx is empty and Tx 400,00000.

    Regards Roger de SM0LTV

  12. Roger Clark
    |

    OK.

    I have not seen that bug.

    Do you mean if you set VFO A to Tx and Rx of 433.00000 then upload to the GD77 that the VFO still displays 400.00000 ??

  13. If i set VFO A Rx/Tx to 433.00000 and clik on VFO B and set Rx/Tx to 145.0000 an then go back to VFO, then Rx is 000,00000 and Tx 400,00000

    //Roger

  14. Roger Clark
    |

    Which key do you press to change from VFO-A to VFO-B ?

    I have not managed that

  15. Anonymous
    |

    This is in the CPS before i send to the radio. I can not set the freq. An it is s@me in the orginal CPS.
    On the radio i use the right arow to ch@nge to VFO mode, and there is always 400,00000

  16. Roger Clark
    |

    Thats strange

    I think perhaps your codeplug is corrupted

    Try the default code plug in my version and see if it has the same issue in the GD77

  17. Roger
    |

    I don’t knew how to change betwen A and B on the radio, what i explai is in the CPS, and ocure on both original and yor’s CPS. I Use right arrow to switch to VFO mode and it always is 400,00000 fom the begining.

  18. Roger Clark
    |

    OK

    Try uploading the blank codeplug that is opened by default by the CPS., and upload that.

    It has VFO A on 145 and VFO B on 430

  19. Ok Roger, i will do that. Tnx

  20. Fabio Bueno - PY2FI Brazil
    |

    Roger – I did not upgrade it or change something. After 5 times using the radio, the VHF band is with low power – around 100 MW. UHF looks like to be OK. It was a very deep deception and was the first time I am facing problem with a brand new radio. I will try to proceed the game with the firmware but the symptom is different comparing you have described – low power in both bands and after firm. upgrade.

  21. Roger Clark
    |

    Usually the power loss caused by the factory settings bug in firmware 3.0.6 causes power to be virtually zero, e.g. perhaps 1mW.

    You should try downgrading to firmware 2.6.6 then update to 3.0.6 again, but if that fails it sounds like you have a hardware fault

  22. Jeff DeLucenay
    |

    After upgrading the QD-77 from V2.06.06 to v3.06.01 to v3.01.01 the transceiver only transmits a carrier no audio modulation. I have restored to the v2.06.06 then back to v3.01.01 in all cases there is no modulation when I transmit. At present I have only tried in the FM mode.
    The unit worked before the upgrades. Any ideas on the issue? It appears to be a hardware failure.

  23. Roger Clark
    |

    This is a known bug where the calibration data gets corrupted.
    See the various other posts on this site and other sites about how to fix it. Or complain to Radioddity as despite knowing about this problem for months they can’t be bothered to fix it

  24. Brandon
    |

    Is there any way to lower the squelch sensitivity? Like you mention early in the post the squelch is too tight. Its making some of the local repeaters basically unusable with this radio because I can’t receive at all.

  25. Boris Krupenin
    |

    HI. I wonder is it possible to charge from a quick charge 3 powerbank that supports USB output 12V 1.5A?

Leave a Reply