Question re Priority Talkgroups

[SCPD]

I have a question and looking for the best solution.

I have a system with 7 talkgroups (all in the same scanlist) and want to make sure that I get the transmissions on one of them above all other talkgroups. *it is an all call talkgroup.

I will be either scanning .. or sitting on one talkgroup. (not the all call though).

I do not use priority at all .. and have not for 20 years cause I just do not like how it works.
But unlike at home .. where I this is not an issue, I do need it now in my vehicle.

So .. wondering what your best solution would be ? Btw .. scanner is Whistler 1095.

 

[wbswetnam]

So, you want to declare a particular talk group a priority, but you don't want to use the priority function... do I understand you correctly?

 

[SCPD]

Exactly .. I have not used priority in 15-20 years and refuse to unless the manufacturers have made it like the commercial radios where it does not interfere by having it checked every so often.

I wanted to just put the same TG in multiple times in the scanlist but Whistler will not allow you to do so.

This is a mobile only problem .. as at home I am good.

 

[QDP2012]

If your refusal to use the Priority-Function is based upon experience 15-20 years ago, then the experience is likely based upon how scanners use priority-function with respect to conventional frequencies, which can be annoying at times as it "jumps" back and forth, and interrupts the current conversation.

In the RS106 family of GRE/RS/Whistler scanners, (and I'm guessing also with your model), the priority function that is used with respect to a Trunked Radio System, does not behave like the priority function for conventional.

To use priority on a TG within a TRS, the scanner must be scanning something/anything in that TRS, and the scanner will give the designated TG the priority if it becomes active, but will not "jump" back-and-forth audibly while checking, like it does with conventional.

But, if the scanner is not scanning that TRS and is instead scanning a different TRS or some conventional object, then the designated TG on that first TRS will be ignored until the scanner gets back to scanning something/anything on that first TRS; then it will give the priority-check to the designated TG.

And to clarify, an object (TG or conv-freq) must be marked as priority, AND the scanner must be in priority-scanning-mode, for the priority-check to be active during scanning.

Hope this helps,

 

[SCPD]

You can tell I use commercial radios and not scanners.

Btw ... the help file confirms you are correct. I am testing it to see if is works as I desire.

Well .. interestingly, my PSR-800 the priority does not work. Sitting on a normal TG, and not a peep on my priority talkgroup. I am going to reprogram the 1095 and go for a drive and see if it works. Oops .. this may be user error. I forgot to turn on Priority Mode.

 

[wbswetnam]

I also use the WS-1095 as a mobile scanner, and I had selected the MAC-Calling talk group of Arkansas's AWIN as a priority channel. I have never heard any pause or interruption in radio traffic as it 'checks' the priority channel, just as QDP2012 explains.

 

[SCPD]

Thanks .. I am going for a drive to see how it works. But bringing a real radio with me to know if it is really working.

I may have to drive around for an hour before I may get some activity .. but it is what it is.

 

[SCPD]

Well .. a complete failure. I have pulled the 1095 from my vehicle for now while I find a priority solution that works.

 

[Ed6698]

I am glad to have read what has been posted in this thread, never liked using priority back when everything in my area was using conventional. Could not stand it cutting out checking the priority channel. Now that everything is P25 I have 1 TG set for priority, my local town. I used to miss stuff for my local town when I monitor the whole county when things get busy. The priority set for my local town is working perfect for what I want, not missing anything now. Glad I have learned priority works differently in a way with P25.

 

[SCPD]

I am glad to have read what has been posted in this thread, never liked using priority back when everything in my area was using conventional. Could not stand it cutting out checking the priority channel. Now that everything is P25 I have 1 TG set for priority, my local town. I used to miss stuff for my local town when I monitor the whole county when things get busy. The priority set for my local town is working perfect for what I want, not missing anything now. Glad I have learned priority works differently in a way with P25.

I don't like priority period cause it does not work in the scanners. The thing .. when you have seen how real radios work and have used them for well over a decade, you never want to use a scanner again. The only reason I am using the Whistler is cause of the remote head and the install issues in installing a commercial radio. I also live in a bad area .. so the removal of that remote head is a requirement.

The main issue .. that the scanners are not able to go to the priority talk group while a conversation is ongoing, unlike the real radios which go to the priority talk group instantly when there is activity on that channel.

The other issue .. the scanner will not go to the priority talkgroup at all when sitting on one talkgroup. A pretty big failure. At least my 1095 will not.

 

[DonS]

my PSR-800 the priority does not work. Sitting on a normal TG, and not a peep on my priority talkgroup

I presume that "sitting on a normal TG" means you either:
a) navigated to that TG in the Browser and hit >/II/SEL; or
b) were scanning and, when that "normal TG" went active, you hit >/II/SEL to pause.

Priority mode does not work in either of those situations. Priority mode only works while in SCAN mode and not paused.
.

this may be user error. I forgot to turn on Priority Mode

That would also do it.

What type of TRS is this? Priority talkgroups only work if it's a system type that advertises active talkgroups within voice traffic. Examples include:
* P25
* Motorola analog voice (as long as the system sends the info in the subaudible data)
* LTR (if the priority TG is homed to the current repeater)

 

[SCPD]

I presume that "sitting on a normal TG" means you either:
a) navigated to that TG in the Browser and hit >/II/SEL; or
b) were scanning and, when that "normal TG" went active, you hit >/II/SEL to pause.

Priority mode does not work in either of those situations. Priority mode only works while in SCAN mode and not paused.
.

That would also do it.

What type of TRS is this? Priority talkgroups only work if it's a system type that advertises active talkgroups within voice traffic. Examples include:
* P25
* Motorola analog voice (as long as the system sends the info in the subaudible data)
* LTR (if the priority TG is homed to the current repeater)

Yes Don .. you are absolutely correct, and sorry for making it not clear. I am using the SEL pause mode at that point. It is an Edacs system. Thanks for your reply .. but I think that having the scanner go to the priority channel when paused is a very simple thing to do, as you just have to check the control channel for a call grant for the priority talkgroup.

I only have 1 priority talk group btw in my scanlist .. but I understand that some may have more than one, but really it would just be if there was a call grant from any of their priority talkgroups in their scanlist that you would need to be looking for.

I don't care about the PSR 800 .. it is the 1095 in my vehicle where I want this ability.

 

[DonS]

That's not how priority talkgroups work in the GRE/Whistler scanners (i.e. PSR-500 and later). They do not interrupt active voice (talkgroup) traffic to:
1. tune to a control channel frequency
2. wait for squelch
3. look for control channel data
4. wait for time <X> to see if a priority TG is active

That would create a major interruption in any current voice traffic

EDIT: the biggest part of the "major interruption" would be in #4. The scanner would have to wait for quite a long time, especially on busy systems, in order to decide that a priority TG is not active. This "wait" would be on the order of several hundred milliseconds and could be up to 1 second, depending on trunked system type.

Instead, these scanners look for talkgroup data supplied by the trunked system on the voice frequency.

 

[SCPD]

I get it, but that does not make it a good thing.

I may be wrong .. but the reason for a priority talkgroup is that 'you want to hear what is on that talk group'. I know that is a debate .. and maybe we need to have it.

So .. in my case, listening (paused mode) to a law enforcement talkgroup in one area of the city and you get an all call (standard transmission to the whole city). Nothing is happening in the area you are monitoring and that all call comes in and well on the Whistler scanner, nothing happens.

I am forced to make a separate scanlist with the 2 talkgroups (the TG for the area and the all call TG) and leave it on scan. In my city .. there are 6 areas. So that means 12 TG's .. and 6 being that all call TG. I change the scanlist based on where I currently am.

The system is way too busy to have that all call TG come up .. as the likelihood of there being no activity anywhere is very small. At least this way .. the chances of no activity is smaller and I may get to hear the all call transmission.

I see this as a major failure .. as priority only works half of the time (when scanning) and not when paused. I know .. that it is what it is, but maybe a setting for the user to indicate if they want the priority to interrupt may be in order. If I recall .. that is how it used to be as I recall seeing a setting just like that where you can specify if the priority will interrupt.

I know for myself I absolutely want that priority channel to over ride anything that is currently happening. Btw .. that is how the real radios work. I know on a scanner as it does not go back to the control channel after that call grant is received makes the priority thing over ride thing impossible.

But it could totally work in pause mode .. if there is no activity. Something for Whistler to consider, as there would be no interruption at that point ?

I did send Whistler a suggestion btw.

Thanks
Kevin

 

[DonS]

that is how it used to be as I recall seeing a setting just like that where you can specify if the priority will interrupt

I think you're referring to a function on the PSR-500 family, where you could tell the scanner to interrupt an active TGRP to perform priority checks for conventional channels.
"TGRP Pri Int" in those scanners' menus.

That's completely different. That's interrupting an active talkgroup for just a few milliseconds to see if squelch is open on a few conventional channels (12 milliseconds, or so, per CONV object to check). EDIT: and even that function is annoying - after checking those priority CONV objects and finding no activity, the scanner has to tune back to the trunked system's control channel, re-acquire it, look for the interrupted talkgroup ID, and tune to the voice frequency.

Checking for an "active priority talkgroup" would take hundreds of milliseconds, and it would be checking every few seconds. While listening to an active, non-priority talkgroup, the user experience would be "a few seconds of audio ... a second of silence ... a few seconds of audio ... a second of silence ..."

But it could totally work in pause mode .. if there is no activity

Yes, that's the one case where it could work. However, that's the same as scanning a single scan list which contains just 2 talkgroups - the one you're paused on and the "priority" TG. (I think that's the solution you described above.)

 

[SCPD]

I think you're referring to a function on the PSR-500 family, where you could tell the scanner to interrupt an active TGRP to perform priority checks for conventional channels.
"TGRP Pri Int" in those scanners' menus.

That's completely different. That's interrupting an active talkgroup for just a few milliseconds to see if squelch is open on a few conventional channels (12 milliseconds, or so, per CONV object to check). EDIT: and even that function is annoying - after checking those priority CONV objects and finding no activity, the scanner has to tune back to the trunked system's control channel, re-acquire it, look for the interrupted talkgroup ID, and tune to the voice frequency.

Checking for an "active priority talkgroup" would take hundreds of milliseconds, and it would be checking every few seconds. While listening to an active, non-priority talkgroup, the user experience would be "a few seconds of audio ... a second of silence ... a few seconds of audio ... a second of silence ..."


Yes, that's the one case where it could work. However, that's the same as scanning a single scan list which contains just 2 talkgroups - the one you're paused on and the "priority" TG. (I think that's the solution you described above.)

Ok .. yes, likely on the PSR500. I think I own too many scanners.

I totally get that it will not do priority when scanning very well on a reasonably active system. I am totally fine with that.

However .. doing priority when paused on a single TG seems like a very simple add and something that could be very useful to many. But .. that is your area not mine, I can only make the suggestion.

Yes .. the workaround with the 2 talkgroups is exactly what I have done. :wink:

It works as long as there is no activity on the non priority talkgroup. But in the ideal situation I should not have to go and do these steps.

 

[DonS]

I may be wrong .. but the reason for a priority talkgroup is that 'you want to hear what is on that talk group'.

You're not wrong.

However, that's also the reason for "pausing on a talkgroup". You've heard interesting traffic and you want to keep monitoring that conversation, without anything else interrupting.

It was a design / beta test decision, 10+ years ago, that "pause overrides priority". If the user presses "pause", he is assigning "super-priority" to the paused object, wants to hear everything on that paused object (without missing the start of every transmission), and will hear nothing else, even if the paused object is not active.

 

[SCPD]

I absolutely get it .. and it is the debate that could never end. Myself .. normally when paused I am interested in what is happening on that paused talkgroup, however the all call could be something very important. So it is obviously a thing we could debate forever.

Maybe .. the 10+ year old decision could be altered, and allow this with a setting to let the user decide which thing they prefer ?

Oh .. I should note, that I do not want to see the talk group being over ridden by the priority if it is active, just going to the priority if there is no activity on the normal talk group.

The thing .. you could go for 30 min or more and get no activity on the all call talk group so it is not like a very active thing, but of course it would depend on what the user defined as their priority talk group and how busy it was.

Like many here, I do not want to miss anything by having the radio go back to have to check things .. that would be like how it was long ago and the thing we all hated.

The other method .. I could haul around another radio but that kind of defeats the whole purpose.