Trunked Priority Question

[tvengr]

A am monitoring a P25 trunked system. Priority ID Scan is On for the system and Priority is On for the Fire Dispatch talkgroup. I am monitoring the Fire Dispatch talkgroup with a second scanner. If another talkgroup is active at the time, it will not switch to Fire Dispatch when that talkgroup becomes active. I am hearing the 2 different talkgroups at the same time. What am I overlooking?

 

[doctordialtone]

What am I overlooking?

Priority works differently on a trunked system. It's complicates.

Read here:

BCD325P2/BCD996P2: - Top 50 Scan

If I were to somehow flag my top 50 channels currently programmed over multiple systems and groups in my 996P2 could I scan only those flagged? I've number tagged them already 1 to 50 and set the Priority to On for just those tagged. Also, some are conventional but most are in Trunked systems...

forums.radioreference.com

and here:

Priority Scanning Trunked System

New SDS100 User. I am having trouble understanding if/how to set priority scanning for a P25 trunked system. I set priority on the channel (talkgroup) i want to prioritize and set "priority ID scan" for the system but I see no indication of priority (PRI) like I see with conventional priority...

forums.radioreference.com

 

[u2brent]

IMHO it just doesn't work at all. You're not overlooking anything.. It is what it is.. Broke. Not functioning as designed is another descriptor.

Recently discussed in this thread..

SDS100/SDS200: - Trunked channel priority

On my SDS100 I can’t do priority scanning on a trunked channel. I get a “Priority Scan, No Channel “. I have tried several times and followed the user manual exactly each time. Help!

forums.radioreference.com

among many others.

 

[GTR8000]

The truth is that P25 trunked priority scanning is broken on Uniden scanners, because it was never implemented correctly. "Priority Monitor" scanning in real subscribers works by decoding the low speed data on the traffic channels. Uniden never implemented that for priority, and so the scanner has no awareness of other active talkgroups that are priority capable while decoding a voice call. So it does nothing, it just remains on whatever talkgroup is active regardless of any other talkgroups that may be flagged for priority.

I brought this to Paul's attention a few times over the years, but it never got fixed. Maybe @JoeBearcat can put it on the list and finally get it done correctly. It would be nice for P25 priority monitor scan to finally work, just like it does on every subscriber and Unication G Series pager. It's pretty basic functionality in 2021, no reason for all of these Uniden scanners to lack it.

 

[tvengr]

Priority works differently on a trunked system. It's complicates.

IMHO it just doesn't work at all. You're not overlooking anything.. It is what it is.. Broke. Not functioning as designed is another descriptor.

The truth is that P25 trunked priority scanning is broken on Uniden scanners, because it was never implemented correctly.

Thanks for all of your help! From what I just read, Priority ID Scan is useless. I don't know why it is included on the scanner.

 

[GTR8000]

Thanks for all of your help! From what I just read, Priority ID Scan is useless. I don't know why it is included on the scanner.

I believe it works on Motorola Type II systems, so it was probably carried over from that to P25, but never implemented properly. It's not even that complicated, and most of the Uniden P25 capable scanners already decode some of the traffic channel data, so it simply needs to be refined to include priority monitor talkgroups (which have to be flagged as such in the trunked system itself). I believe Paul had them make a correction to the decoding of the traffic channel data to read the subscriber ID so that "late entry" calls (decoding in the middle of a call, missing the initial grant) would be able to display the RID. Why priority monitor decoding wasn't added at the same time, I have no idea.

 

[tvengr]

Thanks GTR8000! Hopefully, Joe Bearcat will pick up the ball on this.

 

[trentbob]

Well, as long as it is on the... "list".

 

[MStep]

Well, as long as it is on the... "list".

Well "The List" keeps getting longer and longer. But so far, we haven't really seen any results. I think we need a gentle laxative to get those engineers at Uniden to get some "movement" flowing on "The List". Perhaps Joe Bearcat can post a thread, which he has sole access to, which could numerically list every item that is currently on "The List" so that folks don't keep making the same suggestions over and over again.

 

[MStep]

Priority works differently on a trunked system. It's complicates.

Read here:

BCD325P2/BCD996P2: - Top 50 Scan

If I were to somehow flag my top 50 channels currently programmed over multiple systems and groups in my 996P2 could I scan only those flagged? I've number tagged them already 1 to 50 and set the Priority to On for just those tagged. Also, some are conventional but most are in Trunked systems...

forums.radioreference.com

and here:

Priority Scanning Trunked System

New SDS100 User. I am having trouble understanding if/how to set priority scanning for a P25 trunked system. I set priority on the channel (talkgroup) i want to prioritize and set "priority ID scan" for the system but I see no indication of priority (PRI) like I see with conventional priority...

forums.radioreference.com

Between "Priorities" and "Filters" and all the other goodies, we really got everything short of the kitchen sink tossed into the SDS series. And while that is overwhelming for many, I'm happy that so many unique features were added. It may be perplexing for some of the beginners, and even some of the old-timers seem to sometimes get confused, but in the long run, it's better that those features are there than not.

drdialtone's statement that "it's complicated" is exacerbated by the fact that some of the priority functions may not work as expected, especially on newer trunking systems.

u2brent's observation that "it's broke" might be more accurately summarized by GTR8000's comment that it was never "properly implemented". My guess is that those waiting for any firmware update to "fix" the priority function are in for the long haul.

A much more practical solution is to dedicate a second radio to scan only those very limited channels or talk groups which one considers a priority to monitor. My guess is that whatever engineers are left at Uniden after the Covid decimation are so overwhelmed by all these minor issues that folks keep bringing up that it's safer in the long run to do nothing rather than to make any changes which would have unintended adverse affects on other functions of the SDS. With Paul gone, my impression is that there is no longer any true guidance to help "prioritize" the direction of the current SDS series. Pun intended.

 

[JoeBearcat]

Thanks for all of your help! From what I just read, Priority ID Scan is useless. I don't know why it is included on the scanner.

I believe UPMan described it as follows: If the scanner goes back into scan mode, it will look for a priority TG before non-priority TGs.

Yes, that is another area that I believe has lots of room for improvement.

 

[JoeBearcat]

Well "The List" keeps getting longer and longer. But so far, we haven't really seen any results. I think we need a gentle laxative to get those engineers at Uniden to get some "movement" flowing on "The List". Perhaps Joe Bearcat can post a thread, which he has sole access to, which could numerically list every item that is currently on "The List" so that folks don't keep making the same suggestions over and over again.

We are not yet addressing bug fixes. Feature requests will be after those are addressed. Bug fixes should start soon.

 

[GTR8000]

I believe UPMan described it as follows: If the scanner goes back into scan mode, it will look for a priority TG before non-priority TGs.

Certainly no offense to Paul, but that description makes little sense. In truth, the scanner doesn't actually "scan" talkgroups, it simply parks on the control channel and waits for talkgroup grants. If a grant comes along for a talkgroup that is not locked out/avoided, and is in the clear, it tunes to the appropriate traffic channel, else it ignores it.

The flaw in the logic that the scanner "looks for a priority TG before a non-priority TG" is that it's always going to tune to a non-avoided, unencrypted talkgroup as soon as the grant comes across the control channel, regardless of any priority status. And of course once it's on the traffic channel, and it's not decoding the data stream, it has absolutely zero awareness of other grants, thus rendering priority useless.

P25 control channel signaling ranges from 30 to 40 messages per second, so these grants are happening literal milliseconds apart. The idea that the scanner is sitting there waiting for a full second before tuning to a traffic channel 'just in case a priority TG grant occurs' is improbably, as it means the scanner would miss the very beginning of each transmission.

Yes, that is another area that I believe has lots of room for improvement.

Indeed, glad to hear that you agree. Now that you have a better sense of the issue, I look forward to see the feature get implemented properly in the future.

 

[wa8pyr]

The truth is that P25 trunked priority scanning is broken on Uniden scanners, because it was never implemented correctly. "Priority Monitor" scanning in real subscribers works by decoding the low speed data on the traffic channels. Uniden never implemented that for priority, and so the scanner has no awareness of other active talkgroups that are priority capable while decoding a voice call. So it does nothing, it just remains on whatever talkgroup is active regardless of any other talkgroups that may be flagged for priority.

On top of that, some really large systems don't even use Priority Monitor; too many Priority Monitor talkgroups at a given site would mean a pretty long delay between instances where a specific talkgroup is "seen" on the low speed data, causing radios to miss transmissions, thus making Priority Monitor next to useless. Unless something has changed, Priority Monitor data cannot be routed to specific sites that I recall.

Scanning on multi-site systems is generally considered a "convenience" feature; since talkgroups can only be scanned if they're active on the site the user's radio is affiliated to, it's a hit-or-miss feature at best.

 

[JoeBearcat]

Certainly no offense to Paul, but that description makes little sense. In truth, the scanner doesn't actually "scan" talkgroups, it simply parks on the control channel and waits for talkgroup grants. If a grant comes along for a talkgroup that is not locked out/avoided, and is in the clear, it tunes to the appropriate traffic channel, else it ignores it.

The flaw in the logic that the scanner "looks for a priority TG before a non-priority TG" is that it's always going to tune to a non-avoided, unencrypted talkgroup as soon as the grant comes across the control channel, regardless of any priority status. And of course once it's on the traffic channel, and it's not decoding the data stream, it has absolutely zero awareness of other grants, thus rendering priority useless.

P25 control channel signaling ranges from 30 to 40 messages per second, so these grants are happening literal milliseconds apart. The idea that the scanner is sitting there waiting for a full second before tuning to a traffic channel 'just in case a priority TG grant occurs' is improbably, as it means the scanner would miss the very beginning of each transmission.


Indeed, glad to hear that you agree. Now that you have a better sense of the issue, I look forward to see the feature get implemented properly in the future.

OK. I will simplify it for you:

You are scanning a TRS. Fire Dispatch (non-pri) becomes active. The scanner tunes to that TG. When that TG is finished, it returns to the control channel and the next grants it sees is Fire Ops 1 (another non-pri TG), EMS dispatch (another non-pri), and Police Dispatch (A PRI TG). Rather than tuning to the first one found (Fire Ops 1) it tunes to Police Dispatch because that you have set as a priority.

Conversely, if NO PRI TGs were set, it would tune to the first one it sees: Fire Ops 1.

Do you understand the logic now? (I'm not saying agree with it - I am saying understand it)

Again, I agree it could (and should) be much better, but the operation was not my call. I am merely relaying my understanding of it.

Yet again, I would have preferred preemptive priority, but that depends on several system factors.

 

[Ubbe]

The flaw in the logic that the scanner "looks for a priority TG before a non-priority TG" is that it's always going to tune to a non-avoided, unencrypted talkgroup as soon as the grant comes across the control channel, regardless of any priority status.

No, it doesn't work like that. When a user in a TG conversation releases his PTT button the scanner will immediately go to the control channel. The control channel has a "late entry" feature where all active TG's in that site are transmitted on the control channel and also the info on which traffic channel they are. If a TG has been set to prio and that TG info are sent on the control channel it will go to that prio TG and monitor it and will stop following the conversation on the initial TG.

There's hardly any time for a user to respond in a conversation with his PTT button until that "late entry" info already have been sent over the control channel. Also if the TG has been programmed with a delay, perhaps the default 2 sec, then during that 2 sec waiting time it will also check the datastream if any prio TG are active at the site before it scans over to the next system.

The system admin could have set the trunked mode to message trunking where it stays on the voice channel for the duration of the TG delay time, but that are a very inefficient way of using a trunked system and the capacity are drastically reduced and I haven't encountered any such system but it might be some special cases where it is intentionally used.

/Ubbe

 

[GTR8000]

No, it doesn't work like that. When a user in a TG conversation releases his PTT button the scanner will immediately go to the control channel. The control channel has a "late entry" feature where all active TG's in that site are transmitted on the control channel and also the info on which traffic channel they are. If a TG has been set to prio and that TG info are sent on the control channel it will go to that prio TG and monitor it and will stop following the conversation on the initial TG.

There's hardly any time for a user to respond in a conversation with his PTT button until that "late entry" info already have been sent over the control channel. Also if the TG has been programmed with a delay, perhaps the default 2 sec, then during that 2 sec waiting time it will also check the datastream if any prio TG are active at the site before it scans over to the next system.

The system admin could have set the trunked mode to message trunking where it stays on the voice channel for the duration of the TG delay time, but that are a very inefficient way of using a trunked system and the capacity are drastically reduced and I haven't encountered any such system but it might be some special cases where it is intentionally used.

/Ubbe

Thanks, but I'm quite aware of how it works and what continuation messages are. Still doesn't address the fact that Uniden is not decoding the priority monitor grants and continuation messages on the TRAFFIC channels. This is not about when the scanner is on the CONTROL channel.

I've been pretty clear in my other posts, so I'm bowing out of this thread. Either the preemptive priority will eventually get done (like every other proper trunking receiver is capable of), or it won't. I've been beating the drum on this for years and have gotten nowhere with it. A fundamental feature of P25 trunking that has been in the TIA-102 specs for many, many years...hardly rocket science.

 

[JoeBearcat]

Thanks, but I'm quite aware of how it works and what continuation messages are. Still doesn't address the fact that Uniden is not decoding the priority monitor grants and continuation messages on the TRAFFIC channels. This is not about when the scanner is on the CONTROL channel.

It is 100% about when the scanner goes to the control channel. We are talking about a different type of priority than preemptive priority. Priority Monitor grants do not come into play.

Once you get over the fact we are not talking about preemptive priority, all the "flaws" you cite go away.

Yes, I agree that preemptive priority would be nice, but the scanner does not have that.
It is not a bug, but is the design, and that is what you say is wrong without knowing how it was intended.

 

[Ubbe]

Still doesn't address the fact that Uniden is not decoding the priority monitor grants and continuation messages on the TRAFFIC channels.

It's probably a Uniden decision that it isn't worth the work to decode traffic channel slow data. All active TG's are transmitted on the high speed control channel but the system admin sets which TG's info that should be sent on the traffic channels. It could be that the TG that you set prio to isn't sent out on the traffic channel and scanner users then complain about the function being flaky and doesn't always work. The scanner are probably too complicated as it is for most users and adding one more thing that might work or might not work that are in the hands of each systems administrator might not be the best feature to add right now.

/Ubbe

 

[JoeBearcat]

I believe it would be well worth the work to add preemptive priority.

But yes, talkgroups that are not set on the system as priority will not be evaluated
for preemptive priority anyway which may be why it was not included.