I’ve just finished another modification to the GD-77
The modification allows the DMR channels to work, even when the Rx Group list is set to None, or if the Transmit “Contact” TG is not in the Rx Group.
The reasons I’ve made this change are…
- I need the radio to be able to receive on the Tx TG, for when I modify the firmware to allow direct entry of the TalkGroup.
Note. I’ve not even started to look at this, because the change to the Rx Group stuff has taken me several days to shoehorn into the existing software
- I think the firmware should always have done this..
It seems crazy that you can setup a channel with a Tx TG and can transmit, but can’t hear incoming signals on the same TG that you transmitted on.
For anyone interested in the technical details.
The official firmware has code which compares the incoming signal TG, with each Rx Group list TG in turn, and if there is a match it allows the signal to be received.
The change I made, additionally checks whether the incoming signal is the same as the Tx TG, and it does this check prior to checking the Rx Group.
The problem with this change, was trying to optimise the assembly programing, so that I don’t waste the precious space that is available in the ROM.
The ROM is already 99% full, and even if the Chinese fonts are removed, it only gives around 32k for all enhancements. This is not very much at all.
I noticed that the internal data structure , which is stored in the RAM of the GD77, has the Tx, TG in the memory location directly before the start of the Rx Group list.
So initially, I thought I’d simply change the code to start checking TG’s from the Tx TG memory location, and increase the number of locations it checked, from 32 to 33.
32 being the max number of TG’s in a Rx Group list.
However I found that the Tx TG, memory location, not only contained the TG, but also some other information, which is either the TG type i.e Private Call, Group call or All Call, or the data may also be the Timeslot (TS1 or TS2)
Regardless of what the additional data is, the problem is that this additional data encoded into the Tx TG memory location, stops me directly comparing the Tx TG with the incoming signal TG, as they won’t ever be the same number.
So I had to “mask off” the portion of the 32 bit memory location which contained the additional information.
I found there wasn’t space within the existing Rx Group checking code, so I had to make a sub routine (aka function), which stripped off the additional information before giving the sanitised TG back to the existing checking part of the code.
This worked OK, but I didn’t feel that it was an optimal solution, because the masking function was being run for the Rx Group list TG’s which didnt need to be masked, and would slow things down a tiny bit.
So I decided to program it correctly, and to check the Tx TG prior to the code checking the Rx Group list TG’s
Looking at the assembler code, I found the IAR compiler that Raioddity use, had 4 duplicate assembler instructions, which I could remove, from the core of the Rx Group checking system, and using this space, I was able to move all the prior instructions down, into the free space, which left me with 12 bytes to play with, to check the Tx TG prior to the Rx Group checking code.
It was actually quite time consuming to “move” the code downwards, as I had to retype about 50 machine code instructions into different locations, and also fix up the branch addresses to match the new code layout.
This too several hours.
Then with the 12 instructions prior to the existing code, I was able to “call” a new function, which loaded the Tx TG, and masked off the Call Type, and Timeslot data, so before returning the sanitised TG to the existing code.
And with the remaining 8 bytes, I could compare this TG with the incoming TG and take the appropriate action, i.e either accept the signal immediately, or get the program flow to continue onto the existing Rx Group checking code.
It took me about 3 or 4 attempts to get this new code to work, as I had a few minor bugs which prevented it from working at all.
But it finally worked OK.
I’ve sent this version via email to a few people to test, and I’m hoping to get some feedback over the next week.
And after a short break, I’ll start to look at the Direct TG entry system
Update Saturday 6th April
Rick, W1RHS has alerted me to a possible side effect of this change.
On his hotpot, the audio amplifier does not seem to be getting muted during the tail of each transmission, when his hotspot continues to transmit, but there is no audio in the DMR signal.
I have tested this myself and I can’t replicate the problem, but it may depend on the hotspot settings.
My guess is that, the firmware doesn’t think it needs to mute the audio, because it doesn’t think the amplifier was unmuted in the first place.
So I’ll need to hunt down the part of the firmware which handles the end of an incoming transmission and probably always mute when the incoming audio ends.
Update – Saturday 7th April
I’ve tracked down the noise problem, and it wasn’t what I thought it was…
The problem was the vocoder, trying to process empty data frames at the end of an Over, which caused the “aaaaa” sound that sometimes happens in the middle of an over if there is some sort of interruption in the signal.
The problem seemed to be that the Rx Group list, was still being used at the end of an incoming Over, so I took another look at the code and to my surprise I found another 4 places where the Rx Groups were checked.
But rather than centralizing the RxGroup checking functionality, the programmers had simply cut and paste the same 5 lines of C code (about 25 lines of assembler), in 5 different places.
This is really sloppy programing, even if you have the C source code, which I don’t, because it means that if there is a bug in those 5 lines of C code, you have to remember to fix it in 5 places not 1.
Also its wasteful, as it takes around 200 bytes extra of ROM space. If they have been this wasteful elsewhere in the firmware, I’m not surprised that the GD-77 uses around 99% of available ROM space for its firmware, and this could probably be reduced by 10% at least.
Anyway. I’ve now rewritten the RxGroup checking into its own sub-routine (also know as a Function), and patched the places that had the duplicate lines of programming, to all use this one central function.
I’ve sent the file to a few people and they have confirmed that the bug now seems to have been fixed.
If I get any time during the week, I’ll start to look at the Direct TalkGroup entry system.