Since I last posted I have been very hard at work on the GD-77 firmware, but unfortunately don’t have much to show for my efforts
I’ve been putting most of my effort into the manual entry of the TG number, which has been very difficult to achieve
The problem has not been actually allowing the TG number to be entered, or initially making the transceiver receive and then transmit on the new TG, as well as updating the display to show the new TG.
The problem has been that the rest of the firmware keeps setting the TG back to the original value, from the codeplug, and even worse, the firmware has been saving the text I put on the screen, back into the codeplug memory, but has not been saving the TG number.
This has opened a can of worms around the functionality of the existing firmware, firstly about why it would read the text from the display and randomly write it into the codeplug.
I assumed that the codeplug would not be modified by the radio unless you specifically went into the Set->Radio Cfg -> Ch_Name to change the name.
However I found that the firmware is randomly re-writing parts of the codeplug just when you use the radio normally !
IMHO this a very bad idea, because if something goes wrong, the user will see the “No Channel” message, because before the codeplug can be updated, it needs to be erased and sometimes the original data is not restored during this process.
The other interesting thing I learned about DMR is how the original firmware keeps changing the Tx TG.
When the radio is turned on and a channel is loaded it sets the TG, which will be used for Tx.
When a call is received, this can be a Group or a Private call, the firmware puts that TG into the TG that will be used for Tx.
Hence if you have multiple TG’s in your Rx Group and receive a call/signal on a TG other than the TG currently set for the channel… If you press the PTT, within a short time of the call being received, you will transmit on the TG of the incoming call and not the TG set for the channel.
The same applies for Private calls. If you receive a PC and press the PTT while its still displaying the callers name or ID, you will transmit as a Private call back to that station.
If after receiving an in incoming signal / call, you don’t reply (by pressing the PTT), after a few seconds the TG in the radio will be set back to the TG assigned by the channel.
I’m not sure for Amateur Radio use, whether the system that calls back on the incoming TG is ideal. I know that it confuses a lot of people, and I did not understand what was going on when I first used DMR
This problem is worse on the GD-77 because the official firmware forces you to use a Rx Group, its a pain to have to create a Rx Group for each Tx TG, and also if using a repeater which supports multiple TG’s e.g. in my case 505 and 3808, it seems logical to set the Rx Group for that repeater to include both TG 505 and TG 3803.
This is further compounded on the GD-77 because of the Admit Criteria bug, where the only practical option for most repeaters, is to set the Admit Criteria to Always, since otherwise you have to wait for the repeater or hotspot carrier to stop being transmitted at the end of each over, before you can transmit, and that can take 5 to 10 second, or even longer.
Anyway. The TG restoration to the value assigned by in the codeplug for the current channel has been the most problematic, and I have tried 3 or 4 different ways to do this.
Ultimately, I think I now have the optimum solution, which works as long as Double Wait is not being used.
The solution involves modifying the code which sets the Tx TG to the channel TG, but only when the code is doing this in response to the user not pressing the PTT after receiving an incoming signal.
And in this case I found that the SET TG function in the code expects the data to be in the format its stored in the codeplug.
Whats crazy about this, is that the codeplug data is in BCD format, (Binary coded decimal), and also in BigEndian format. Where as the CPU in the GD-77 is an ARM processor an runs in LitteEndian format.
Hence If i want to set a TG of 00003803, need to convert this to 03380000
Note this is not simply a reversal of the digits, as that would be 30830000, its much more complicated, as each pair of digits needs to be swapped as well as the order of the pairs of digits needing to be swapped.
Hence it took me several hours to work out what was going wrong and how to create the number in the bizarre form that the SET_TG function wants it.
I also had to implement this feature, so that if the override TG code was 0, it was ignored, as the SET_TG only needs to be overridden when the user has actually entered a new TG via the keypad.
And, I need to reset the override TG when the user changes the channel, or changes the Zone (which will change the channel)
At the moment, I’ve only managed to clear the override when the user changes the channel, but I’ve not which of the 5000 unnamed code functions in the firmware binary, are run when the user selects a new Zone.
I think there may be other instances where the override needs to be cleared, but I’ll need to cross that bridge when someone tells me that the TG as not been cleared when it should have been.
So despite at least 2 weeks work on this, I’ve not got anything available for general testing.
I do have 2 people trying various versions of this, and they have been able to set the TG but those people have been willing to put up with the bugs caused by the TG not being cleared when they change zones etc etc
Additionally, I’ve been alerted to possible problems in the extended DMR ID lookup, and have noticed a bug in the official firmware, where when making a Private call to a ID thats in the DMR ID database, the display strangely displays a number in the bottom line.
I checked this bug, and it exists in the official firmware.
There also seems to be a potential bug, if the callsign and name take all the characters that have been allocated, e.g if perhaps only 12 chars were selected in the drop down menu in the CPS.
Again, this seems to be a bug in the official firmware, as the memory buffer used to hold the callsign and name, does not seem to be cleared before being used, and this can result in this GD-77 trying to display random characters after the end of the name.
I think I know how I can fix this, but it requires changes to my modified DMR ID lookup code, and also it requires me to tidy up some inconsistencies in parts of the the official firmware which allocate the memory buffer for this text.
In hindsight, I suspect fixing the Admit Criteria bug may actually have been easier than adding what appears to be a simple new feature, but that’s the problem with hindsight 😉