Now that the Hotspot mode functionality is relatively stable, I’ve switched my efforts to supporting DMR Tier 2 in the OpenGD77 firmware.
Kai (DG4KLU) told me a couple of months ago, that he had been working on the Tier 2 functionality, but was unable to get it to work correctly, and that he no longer had any spare time to work on the OpenGD77 firmware.
Colin G4EML had some time recently to help with the OpenGD77 firmware, did some tests to try to understand how we could move forward with the Tier 2 functionality, but came to the conclusion that there appeared to be fundamental problems with the existing DMR Tier 1 programming code. These problems mainly related to the inaccuracy of the timing control, or possibly because different triggers from the HR-C6000 DMR DSP chip could be processed in the wrong order by the existing DMR programming code.
So I set about doing a major overhaul of Kai’s original DMR code, to resolve the potential problems which Colin had found.
The biggest change was to move all of the code that relates to handling the interrupts from the HR-C6000 from being processed as part a “task” in the Realtime Operating System (RTOS) which the firmware uses, to being handled by Interrupt Service Routines.
To roughly explain what this means in layman’s terms, the RTOS is set to run the DMR code, once per millisecond. This code checked if the HR-C6000 had flagged that it needed some attention, and then processed that request.
The problem with this system, is that the worst time delay between the HR-C6000 flagging it needs to be dealt with, to it actually being deal with, could be as much as 1 millisecond, and with a protocol like DMR, a 1 millisecond delay may be too much.
Moving the code from the RTOS task to an Interrupt Service Routine, is not just a matter of cutting and pasting the code, because the time that can be spent in an ISR is very small, so that for example its not possible to run the AMBE audio codec from inside the ISR. Also the ISR can’t use any RTOS system functions which are intended to prevent resource conflicts e.g. 2 parts of the firmware accessing the same hardware at the same time, so any potential hardware conflicts need to be handled some other way.
The hardware in question is the HR-C6000 DMR DSP chip its self, which has 3 digital interfaces, ( two SPI buses and a I2S bus), and in practice the only way to prevent bus contention on was to move all the SPI related functionality inside the ISR. Well, actually the initialisation code is not in the ISR, and nor is the code which initially configures the HR-C6000 to go into transmit mode when its completely idle, but when its idle I was able to briefly disable the interrupts so that I can use the SPI bus outside of the ISR’s.
This radical modification of the code took me about two weeks, and at the same time I had to modify a lot of other code related to operating in duplex mode, including changing the Tx / Rx switching system to completely be able to change from Rx to Tx every 30mS while the radio is transmitting, as well as being able to change the Tx / Rx frequencies at the same time, and switching the PA off and pre-amps on etc etc etc.
I finally got the simplex functionality working again, but in the process I broke the Hotspot mode functionality, and it took another day to get that working again. Currently Hotspot mode may not be 100% stable, as I had a report that it crashed while transmitting after about 6 hours of use. However , since Hotspot mode works OK in the old Tier 1 firmware this is not a priority for me at the moment, and anyone wanting to use Hotspot mode can old the older stable Tier 1 firmware.
After the overhaul, I found I was able to transmit to my duplex hotspot, as long as I woke-up my hotspot using GD-77 running the official firmware.
Strangely I found that I was also able to wake up my local Motorola based repeater, if I transmitted for around half a second and then released my PTT, whereas continuing to hold the PTT and keep talking failed to wake the repeater. In theory the firmware should not be waking the repeater at all.
Kai has now sent me some code he wrote which is designed to wake up a repeater, so I will attempt to integrate his code into my new structure and see if it works, or if I need to make modifications or perhaps write it again from scratch.
What I can’t get working at the moment is the Timeslot selection.
The existing DMR code, which Kai wrote, seems to somehow be locking onto the currently active Timeslot, so that if someone wakes up the repeater by transmitting on Timeslot 2, I’m normally able to have a QSO with them on TS2. But is someone wakes up the repeater and starts to have a QSO on Timeslot 1, the firmware is only able to communicate with them, and not to put a call out on Timeslot 2.
In theory there are several “registers” in the HR-C6000 to determine the current Timeslot that is being received, but these are not working for me, and I suspect that they don’t work unless the HR-C6000 correctly initially locks onto the DMR frames based on their TS code correctly.
Overall, I’m very optimistic that Tier 2 will definitely be possible in the OpenGD77 firmware, but its hard to know now long its going to take me to resolve the remaining issues, as currently I am the only person actively working on the project.