Daniel has been doing a lot of work on the Hotspot mode, but his changes have not completely fixed the bugs in Hotspot mode, hence they will not be included into the "Latest" version until he tells me that they are ready for general use.
The new version can be downloaded from this link.
https://github.com/rogerclarkmelbourne/ ... latest.sgl
Changes in this version are :-
- Improvements to the Talker Alias data processing and display. Thanks to Daniel
- Language updates from various contributors.
- Bug fix for the Tx on incorrect TS problem. From Colin. (Note this fix is does not completely solve the problem, and we are working on a much larger number of changes to the DMR subsystem)
- Display of received TG name, lookup in the Contacts. From Alex
- Fix for channel name, missing from the Tx screen. From Daniel
There have also been some other technical changes to the firmware which will not be noticeable. Alex and I have done some work to make more of the RAM available to the firmware, which in the future could be used to speed up some of the codeplug data lookup operations.
The MK22 CPU (MCU) has 128k of RAM which is divided into 2 separate banks of 64k. Kai configured the firmware build system , to only use the upper 64k because a portion of the lower 64k RAM is used by the AMBE codec and is not under our control, as we are using parts of the official firmware binary for the codec.
However, I conducted some tests and the codec only uses just over 8k, roughly in the middle of the 64k, so Alex and I have now managed to divide the RAM into 4 sections. Lower_Base_RAM, Lower_AMBE_RAM, Lower_Top_RAM, and Upper_RAM, and reconfigured the compiler / linker to be use all blocks except Lower_AMBE_RAM.
The firmware still has a number of niggling problems on DMR, which are most likely being caused because we are not configuring the HR-C6000 DMR chip correctly and are also not reading data from it correctly.
As we have virtually no documentation on this chip, and have already learnt as much as we can from attempting to decompile the official firmware, I decided to take one of my GD-77 completely to pieces and solder some 0.25mm thick wires to the data connections between the MCU and the C6000 chip, and then connect those wires to a logic analyser so that I can capture the data traffic.
As you can imagine, soldering 0.25mm thick wires to the tiny pads on the PCB between the 2 chips was not easy, but I have now been able to collect data when the GD-77 is booted up and also when it receives a DMR signal and also when the channel is changed.
I will be putting the logic analyser capture files (in Saleae Logic data format) into GitHub later in case anyone wants to take a look.
Unfortunately this has given more questions than it has provided answers.
The official firmware seems to be writing to 4 undocumented "registers" in the C6000 during Rx, and it also seems to send a large amount of additional configuration data to the C6000 every time the channel is changed.
Its likely that the official firmware DMR Rx performance is better than the OpenGD77 DMR Rx, because we are not sending this data, and we will need to integrate this data into the C6000 setup.
However we are not likely to simply copy exactly what the official firmware does, because the official firmware is full of bugs, and often has unnecessary duplication. For example. Its unlikely to be necessary to send these blocks of configuration data to the C6000 unless the C6000 has been reset, as I suspect the configuration will be retained.
Additionally, the official firmware is reading data from undocumented registers during Rx, and even appears to be reading the DMR AMBE audio bytes from a completely different part of the C6000 !
I have done some quick tests, to attempt to read the AMBE data from where the official firmware reads it, but I didn't get any audio at all. So there must be some other differences in the C6000 configuration, which affects this.
Reading the currently active TS, during Rx, continues to be problem. Colin did a fix to improve the TS synchronisation under low signal conditions, however it looks like the official code may be using an undocumented register (number 0x57) as part of its TS synchronisation.
Kai was using register 0x57 but I found it was unreliable and changed the code to using the value in register 0x52, which is described in the limited data sheet we have for the C6000 as the place to get the TimeCode (TS number).
But it looks like the official firmware is reading both 0x52 and 0x57 at different phases of the DMR Rx, and we now need to look in more detail at the values in both of those registers, in an attempt to reverse engineer how to use those values to guarantee TimeSlot synchronisation.
In the medium term, I'm sure that we will be able to improve the DMR Rx and Tx, but I think that the next month will most likely be spent stabilising the code and bug fixing, rather than adding any major new features.
Edit.
I forgot to mention that I have also been attempting to remove unused screens from the OpenGD77 CPS, but its not a simple process and I have not had time to complete this work yet.
Also, I need to fix a legacy bug in the CPS where the frequency of a channel or VFO can only be set if its on a 25kHz step.
I need to completely remove this check from the OpenGD77 CPS.
And. I think I need to completely split the OpenGD77 source code from the Community CPS code, as its getting difficult to manage a combined codebase when the functionality is now starting to diverge.