OpenGD77

I am not sure the word ‘Waiting’ is needed as it could be confusing.

Maybe just blank or ‘........’ ?

G4EML wrote: ↑

Fri Dec 20, 2019 6:42 pm

I am not sure the word ‘Waiting’ is needed as it could be confusing.

Maybe just blank or ‘........’ ?

I have this question in my pull request.
So any suggestions for '.....' ?
But maybe the green LED with a blank screen is info enough.

Alex, thanks for all your efforts to track the TG: 0 and ID: 0 issue down. As Mike said, this was a big one for those of us who use DMR resources outside of the brandmeister system. It has been working fine for the past 4 hours here.

73, Rob W1AEX

Working well here too, the only thing that looks strange is I had the 999999 ID show back up one more time, I do not know if that is a mistake or if someone has that entered into there radio. It was just a quick click on a talk group, no one talked and I saw it once this morning and again this afternoon early. Other than that all seems to be working well.

I would think that if there is no ID or TG to display then it should just be blank. Displaying 'Waiting' makes sense while debugging but doesn't achieve anything in normal use.

Perhaps it’s best to not change the display at all until the DMR ID is received.

What I don’t understand is why it would take any time for the ID to be received, because the ID is sent in the Voice Header Link Connect data, which is normally transmitted 6 times by the other station.

It sounds like in these cases where it’s taking a while to display the TG and ID, that it’s probably getting the ID from the subsequent audio frames, as the Link Connect data is embedded in small chunks across groups of 6 audio frames.

But even if you have to wait for the embedded data , it would only take 360mS. Hence a maximum of 720mS after receiving the signal.

The main problem was an extra check for the field FID (Feature Identifier) to be 0. But I think the repeaters where this problem persists do not send a value of 0.
So the DMR code discards the voice header, but receives the Talker Alias header. But the TA header does not include TG or PC.
The TA header triggers the last heard code which uses the TA header but without a valid ID. Depending on what happens before an old last heart entry is reused or a new one with TG 0 is created.

Now this only happens if the voice header for some reason is 'scrambled' and the embedded date has to be used.

The 'Waiting' was for me to debug and I updated the PR without it.

Ok.

I was going to say, that if the repeater has TA enabled, and both the initial Voice Header LC and the first audio frames were also not decided, then the next frame may be TA it would not have the data either.


BTW.

I had problems with the CRC flag not being set correctly.

I will email Kai to see if he remembers problems about the CRC flag

But there is no TA info on DMR+ repeaters is there?

If there is a problem with crc we will get bug reports with 'No TG or ID on receiving'.