Ongoing modifications to the GD-77 firmware

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

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 😉

10 Responses

  1. EvO
    |

    Thank you very much Roger for all your hard work and efforts!!!
    Please keep it up!

  2. Roger Clark
    |

    I’m trying to make the TG number entry available for Beta testing in the next 1 to 2 weeks.

    However, it won’t work correctly in Double Wait Double mode, as this would require many more changes and its not worth delaying the release for another few weeks just because of that limitation.

    I will also need to fix the possible problems with the new DMR ID system, but at the moment no one seems to have encountered the problem except @rootstar aka @forkoz.

  3. ken
    |

    omg sounds like a nightmare good luck

  4. Roger Clark
    |

    Yep. Far more difficult than I had imagined it would be.

  5. EvO
    |

    Thanks Roger.
    I can only guess the difficulties that you are encountering and the obstacles that you constantly overcome.
    In spite of the fact that you alone are doing everything by yourself, honestly I think you are really fast in fixing problems and defects that emerge along the way.
    I think that the fact that at the moment the direct entry of TGs from the keyboard does not work correctly by setting the transceiver in Double Wait Double mode is not a big problem as to preserve the charge of the batteries almost never the GD-77 is used in that way.
    Then if over the time it will be possible to improve the thing to make it work even with the Double Wait Double mode so be it.
    I think that thanks to your constant commitment and hard work the GD-77 has improved a lot to become unrecognizable compared to the factory firmwares released by Radioddity or who for them (TYT).
    In a short time you were able to fix and improve things that the manufacturer failed in years.
    Today thanks at you with the GD-77 it is possible to be able to do things until yesterday considered impossible.
    Using your firmware I have my GD-77 programmed with 992 channels and never a problem, everything works like never before.
    Already alone the fact that you managed to make the use of the RX Group list optional has greatly simplified the writing of codeplugs and it has canceled the limit of maximum 76 individual TGs imposed by Radioddity with his last firmwares (first the maximum limit of individual TGs was 128), which is really not a trivial matter and in the future things could even improve further.
    No longer having to be forced to associate each contact with an RX Group list make the writing of codeplugs a piece of cake and being able to read on the display of the transceiver the name of the correspondent as well as the name it is priceless.
    Thank you very, very much Roger, please keep it up!

    ps. What’s the problems with the new DMR ID encountered by @rootstar aka @forkoz?
    Thanks.

  6. Roger Clark
    |

    Re: Problems with the DMR ID

    I’m not absolutely sure.

    I think there is a potential problem if the callsign and name length is set to 16 and the callsign and name take all 16 characters.

    There is a bug in the official firmware, where the memory into which the callsign and name is not cleared prior to it being used.

    As far as I can tell, the memory seems to be empty for the first 16 characters of the 20 bytes of memory which are allocated for this purpose, but the last 4 seem to contain some data which is left over from the last time memory was used (for a different purpose, as the same memory gets reused for different things)

    The firmware needs to be modified to guarantee that the memory buffer is totally empty before its used for the callsign and name text

  7. EvO
    |

    Hi Roger.
    Thanks for the kind answer, good to know that.
    From my side I use the thing with a limit of 14 characters due to interference with the phone handset icon that stands on the display and it works like a charm without any problem for me.
    The only one, let’s call it annoyance, is that in some cases someone has registered with the callsign instead of the name, so on the display the callsign appears twice instead of callsign and name.
    This is another story, though.
    Thanks for your tireless work Roger, please keep it up!

  8. Roger Clark
    |

    I find the phone handset icon annoying as well, but its difficult to track down the part of the firmware which is displaying it.

    Ideally, I should be able to move it to the top right of the screen, or perhaps completely remove it, because the screen already displays the words “Group Call” or “Private Call” if there is an incoming call, so as far as I can tell the icon is completely redundant.

  9. Gary Walborn
    |

    Is your modified firmware available? If so, where? Also, I spoke with Radioddity marketing at the Dayton Hamvention. Based on our conversation, I have a question for you that is probably better asked in private. Is that possible?

    Thanks,

    Gary Walborn
    WB8LEA

  10. Roger Clark
    |

    Hi Gary

    I’ve sent you an email to the gmail account you put in your comment

Leave a Reply