UID Not Keeping Up

[Dewey3]

I don't know if this is just my setup, so I'll ask here. I've noticed since the v4.3x versions, that the unit IDs are not keeping up on the P25 - Phase II TDMA system that I monitor (https://www.radioreference.com/apps/db/?sid=6341) as well as they used to on the older versions. I know that when responding units/dispatchers reply almost immediately, not even my Uniden SDSs will not keep up, but instead show the same UID. For me, the pre v4.3x versions of Trunk-Recorder were extremely good at catching the UID for the currently transmitting unit, no matter how fast the reply. With the v4.3.x versions, many times I'm seeing the same UID across the complete back and forth transmissions unless there is a long enough pause that either the transmission jumps frequencies or the pause between the two units is long enough that the UID for the first transmitting unit no longer displays. Just curious if anyone else has noticed the same thing ... again, maybe it's just my setup.

[e850205]

It's not just you. I've been having the same issue for a few months. In recent releases I've noticed more frequent "-1" units rather than just completely missing the unit.

[taclane]

It's not just you. I've been having the same issue for a few months. In recent releases I've noticed more frequent "-1" units rather than just completely missing the unit.

As of a few releases ago, -1 is what gets reported back when trunk-recorder records a transmission, but did not see a UID. Even if it shouldn't generally be in use, UID 0 has some reserved meanings in P25, so -1 is used instead.

[tadscottsmith]

When you say it's "not keeping up" and "displays" it makes me think you're talking about rdio-scanner or a different playback app. But, I've been investigating transmissions bleeding together and I wonder if that's what your seeing. When this occurs, if you look in the JSON file, are there less "transmissions" than you know should be present?

[Dewey3]

Correct, and sorry for my ambiguity. I am reviewing recordings in Rdio-Scanner and what I mean by not keeping up is oftentimes, the Rdio-Scanner displayed UID fails to change when either the dispatcher answers, or a unit is answering the dispatcher. In those cases, the UID displayed by Rdio-Scanner will still be the previous unit or dispatcher (PG Co, MD: https://www.radioreference.com/db/sid/6341). I've looked at a small sampling of the TrunkRecorder json files and am seeing the minus 1 on those occasions. I also see far more occasions where the UID is not being captured at all.

For the last couple weeks, I've gone back to my latest v3.x copy of TrunkRecorder, but still use the newest copy of Rdio-Scanner and everything has been spot on. Unfortunately for me, the v4 versions of TrunkRecorder appear to decode the Charles Co, MD Smartnet fsk4 mixed analog and digital system (https://www.radioreference.com/db/sid/2847) better than the last v3 version that I'm currently using.

Concerning the "bleeding together" transmissions, I am noticing that as well, but again, that is using the v3.x copy of TrunkRecorder.

[Dewey3]

I built the latest copy of TrunkRecorder today and ran it for an hour or two. I cannot explain why, but v4 only catches (logs) about 75% of the UIDs that the later copies of v3 catch. Most v4 UID "misses" happen when the dispatcher and/or field units key up immediately at the end of the previous transmission. I mostly see this on the very busy PG County, Maryland system; https://www.radioreference.com/db/sid/6341.

[Dewey3]

After reading some of the later comments in "P25 Transmissions Bleeding Together" (https://github.com/robotastic/trunk-recorder/issues/701), it is very possible that this is a result. Closing ...

[Dewey3]

After talking and working with @tadscottsmith concerning https://github.com/robotastic/trunk-recorder/issues/701, it looks like this may be a separate issue. Reopening ...

[tadscottsmith]

@robotastic I got access to @Dewey3's test system and it seems that P25P2 SRC IDs never update after the initial grant/transmission.

[2022-06-19 23:52:57.009526] (info)   [2A8]     4747C   TG:         25  Freq: 770.356250 MHz    - Transmission src: 2532687 pos: 0 length: 10.2
[2022-06-19 23:52:57.009638] (info)   [2A8]     4747C   TG:         25  Freq: 770.356250 MHz    - Transmission src: -1 pos: 10.2 length: 4.16
[2022-06-19 23:52:57.009711] (info)   [2A8]     4747C   TG:         25  Freq: 770.356250 MHz    - Transmission src: -1 pos: 14.36 length: 6.16
[2022-06-19 23:58:16.015241] (info)   [2A8]     4798C   TG:         55  Freq: 770.356250 MHz    - Transmission src: 2530356 pos: 0 length: 1.32
[2022-06-19 23:58:16.015357] (info)   [2A8]     4798C   TG:         55  Freq: 770.356250 MHz    - Transmission src: -1 pos: 1.32 length: 7.56
[2022-06-19 23:58:16.015440] (info)   [2A8]     4798C   TG:         55  Freq: 770.356250 MHz    - Transmission src: -1 pos: 8.88 length: 2.16

I've got a branch that seems to be tracking P2 sources much better if you want to review. Let me know if you want a PR, but I know there is a lot going on and I don't want to gum up the works.

https://github.com/tadscottsmith/trunk-recorder/tree/p25p2-uid

[robotastic]

ohh... that branch looks pretty good! so there were a few messages types there were not implemented for TDMA? That would explain it. Looks like SRC ID was also there in a few cases and not being captured. I am going to go merge this in...

[Dewey3]

@robotastic I really appreciate all that you're doing! Unfortunately, the version released today is still doing the same thing. I don't know the difference, but I believe that @tadscottsmith just about knocked out the source (unit) IDs not keeping up with the transmissions. This could be part Rdio because I'm seeing source ID changes in the log, but there's still a number of misses. Additionally I get a lot of the below listed errors. I don't know how common these errors are since I was running v3 for my production units...

errors.txt

[robotastic]

Thanks @Dewey3 - I just switched things around, so it will only update to the Src ID from the Control Channel if it hasn't't been set yet. I think it might be working now.

@tadscottsmith I ended up having some problems with that branch. It looked like it was creating some weird control channel messages. I wonder if some of those messages were not being processed correctly? The Talkgroup Numbers seemed to be off and this was for a Phase 1 system.

[Dewey3]

Thanks again Luke. It's not as bad, but I am still getting it on the very quick back to back transmissions. I did just think about one change that I have made. I moved to using the 64-bit version of Raspberry Pi OS (Debian) for the last 2 or 3 builds, do you think that may have an impact (I'm not seeing any errors during the TR installs)? Here's two json files from where it happened on this build:

{ "freq": 770356250, "start_time": 1656877640, "stop_time": 1656877646, "emergency": 0, "encrypted": 0, "call_length": 2, "talkgroup": 43, "talkgroup_tag": "PGPD K", "talkgroup_description": "PGPD King Sector-Dist 4-Oxon Hill", "talkgroup_group_tag": "Law Dispatch", "talkgroup_group": "PGPD", "audio_type": "digital tdma", "short_name": "2A8", "patched_talkgroups": [37,43], "freqList": [ {"freq": 770356250, "time": 1656877640, "pos": 0.00, "len": 2.00, "error_count": "0", "spike_count": "0"}, {"freq": 770356250, "time": 1656877646, "pos": 2.00, "len": 0.16, "error_count": "0", "spike_count": "0"} ], "srcList": [ {"src": 2538671, "time": 1656877640, "pos": 0.00, "emergency": 0, "signal_system": "", "tag": ""}, {"src": -1, "time": 1656877646, "pos": 2.00, "emergency": 0, "signal_system": "", "tag": ""} ] }

and

{ "freq": 771756250, "start_time": 1656877529, "stop_time": 1656877537, "emergency": 0, "encrypted": 0, "call_length": 5, "talkgroup": 25, "talkgroup_tag": "PGPD G", "talkgroup_description": "PGPD George Sector-Dist 3-Landover", "talkgroup_group_tag": "Law Dispatch", "talkgroup_group": "PGPD", "audio_type": "digital tdma", "short_name": "2A8", "patched_talkgroups": [25,181], "freqList": [ {"freq": 771756250, "time": 1656877529, "pos": 0.00, "len": 1.08, "error_count": "0", "spike_count": "0"}, {"freq": 771756250, "time": 1656877534, "pos": 1.08, "len": 3.60, "error_count": "0", "spike_count": "0"} ], "srcList": [ {"src": 1000312, "time": 1656877529, "pos": 0.00, "emergency": 0, "signal_system": "", "tag": ""}, {"src": -1, "time": 1656877534, "pos": 1.08, "emergency": 0, "signal_system": "", "tag": ""} ] }

[Dewey3]

@robotastic - while there are some UIDs that TR will still occasionally get missed and substituted with a -1, it's time for a mea culpa! This may be more Rdio not being able to keep up than TR. @tadscottsmith mentioned that he thought he saw something like that as well when he was working on my test system. I did some updates today and updated the Rdio handling the TR v3 - 2A8 system from v6.4 to the current v6.5.1 and immediately noticed the UID problem. I then went back to Rdio v6.4 and the problem 95% - 98% disappeared. It's almost time for me to start getting ready for my 0300 get up time for work tomorrow, but you can bet when I get home, I'll run your latest copy of TR into Rdio v6.4 and see what I get.

[Dewey3]

Just an update... I ran the 7/3/2022 build into Rdio v6.4.0 and as much as I wanted to be wrong and start seeing accurate UIDs, I didn't see a change.

[robotastic]

@Dewey3 it turns out I can receive the PG County system pretty well from DC.... and I am seeing the -1 still on IDs. I am going to try to work in some of the code from Tadscottsmith's branch. I had tried to merge it in before, but it seemed to cause some issues with the Phase 1 talk groups ids. 0300 is early!!!

[Dewey3]

It looks like this issue is finally put to bed with the 7/7/2022 release (https://github.com/robotastic/trunk-recorder/issues/701#issuecomment-1178413518) in https://github.com/robotastic/trunk-recorder/issues/701.

Thanks for all of your work @robotastic and @tadscottsmith !