Whilst experimenting with multiple modes enabled on my duplex hotspot, uncovered a minor configuration issue which seems to apply to the default codeplug supplied by Radioddity.
When multiple modes are enabled (in Pi-Star), and the hotspot cycles though each mode, listening for one mode at a time, I found that the GD-77 would rarely connect to the hotspot.
Listening to the transmitted signal, on a FM receiver, I noticed that the GD-77 only made one attempt to connect to the hotspot, despite the GD-77 not giving the warning beep, for well over 1 second.
I discussed the problem with Colin G4EML, and he advised me that the setting which controls this in the CPS is on the Signalling System screen (aka Signalling Basic) and is called “Tx Wakeup Message Limit”
In my codeplug this value was set to zero (0), despite the minimum allowable value being 1.
A bug in the CPS (which I will fix in my version… Soon…), allows this value to be set to between 0 and 4 rather than 1 and 4.
In practice the firmware treats any value outside the rage of 1 to 4 as a value 1. So there will always be at least 1 “Tx Wakeup Message”, because if it didn’t do this, then values of zero, would prevent the GD-77 from connecting to any repeaters.
The DMR specification recommends 2 retries; which means on the GD-77 that the “Tx Wakeup Message Limit” value should be set to 3.
I think perhaps I should change the name of this menu to be “Tx Wakeup Message Retries” and subtract 1 from the value, as this would be a more sensible way of displaying the data, since its not possible to have zero Wakeup messages
I’m not too sure why my codeplug has zero for this value, because the default codeplug for both the official and my Community CPS have this set to 1.
I presume the value must somehow have become corrupt, when reading back from one of my GD-77.
Since the recommended value in the DMR specification is 3 tries in total, I will change the default codeplug in my CPS to this value.
Just for completeness…
I investigated how the Tx Wakeup Message Limit is stored in the codeplug, and its stored in 3 binary bits as part of one of the “flag”s in the Signalling data block
Its rather strange that Radioddity used 3 binary bits for this, since the value never needs to be zero and the recommend value for retries is 2. Hence even assuming this value is the Message count (Limit) and not retries, the recommended value would only be 3, and if this was used to store retries instead of tries, then the values of 0 to 3 (retries) would be adequate.
When I tried setting higher values (since 3 binary bits can store the values 0 to 7), the firmware seems to check this value, and always goes back to 1 (one) try for any values above 4.
Since this was for values of 5,6 and 7, this means that the firmware is not simply reading the lower 2 bits as a value of 7 should be the same as a value of 3 (ignoring the upper binary bit). Hence the firmware must be reading all 3 binary bits, but checking for values outside of the range 1 to 4, and defaulting to a value of 1 in that case.