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