Hi. After reading what the manual says about priority scanning, i'm trying to understand how the 436/536 handle talkgroup ID's that are set as priority channels, when set to the DND mode. Is it correct that talkgroup ID's that are set as priority channels are only checked when the scanner is scanning the trunked system that they are part of? If so, it seems that there isn't much advantage to setting talkgroup ID's to be priority channels. (Hope this all makes sense.)
Priority Scanning
- Thread starter gn32772
- Start date
- Status
Hi gn32772,
From what I have read and used in real-time scanning on my Motorola Type II Smartzone analog trunked system, my 436HP will scan the entire system for active talk groups within the ID Scan or ID Search(Searching all talk groups regardless of what departments are turned on or off). With Priority DND, if a non-priority talkgroup is active, then the talk group is trunk tracked on whichever frequencies are allotted. Once the transmission has completed and your hold time duration expired without any new activity on that tracked talk group(Mine is 3 seconds, yours could be different), then the scanner will close squelch and begin scanning your talk groups that are set on Priority FIRST. The entire Priority talk group list will be scanned. If no activity is heard on that priority list, then the rest of the system will be scanned until activity is detected.
Pertaining to your question, the DND Priority setting scans your priority list if and only if there is no activity on your previously trunktracked talkgroup after squelch has closed. With NORMAL Priority, I believe the scanner will scan the entire system or global scan list while interrupting and reverting to your Priority list every 2 SECONDS, regardless if you are listening into traffic or not. This is not ideal if you have extended duration transmissions because of the fact that the NORMAL Priority scanning will interrupt your transmission every 2 seconds to scan for Priority talkgroup activity...Not to mention the fact that I believe if activity is detected on any of those others Priority talkgroups, then it will jump to the prioritized talk group and scan that one instead of the one you were previously scanning.
If you have any other questions just ask away. If anybody has amending suggestions I need to make to this reply, absolutely let me know. I'm fairly versed with scanners but absolutely am not the end-all-be-all encyclopedia on them.
Spencer
KM4KFG
marksmith
Member
You are right except that it makes your priority talkgroups a priority over the ones that are not on that same system.
Mark
536/996P2/HP1e/HP2e/996XT/
396XT/PSR800/PRO668/PRO652
For some reason I was under the impression that Priority DND scanning applies only to conventional channels and not a trunked system. If Priority DND scanning is invoked it will not disturb an active transmission to check a priority channel for activity.
Priority DND scanning is only beneficial if there is a very large number of conventional frequencies being scanned.
Priority for trunked systems is a whole different ballgame and there are difference nuances depending upon the type of system involved, such as a P25 system or certain type of Motorola system.
On "most" trunked systems when priority scanning is applicable, there is no pre-emption of an on going transmission to check for activity on a priority talkgroup. Only when the scanner is monitoring the control channel is when priority "kicks in".
What I've seen happen on a P25 system is that I can be holding on a talkgroup (as in not scanning). If there is no activity on that talkgroup and a talkgroup I have selected to be a priority talkgroup becomes active, the scanner goes from that "held" channel to the active priority talkgroup.
Pre-emption of an on going transmission on a non priority talkgroup can occur on certain Motorola systems, but only when certain conditions are present. These conditions are 1-the radio system administrators have marked a talkgroup as a priority talkgroup and 2-you have marked your scanner programming so such talkgroup(s) are priority. If those two conditions are present, then your scanner will stop listening to a non priority talkgroup and jump to an active priority talkgroup.
Suffice it to say the concept of "Priority" is pretty complex and it is not easily undestood at first blush.
Priority DND scanning is only beneficial if there is a very large number of conventional frequencies being scanned.
Priority for trunked systems is a whole different ballgame and there are difference nuances depending upon the type of system involved, such as a P25 system or certain type of Motorola system.
On "most" trunked systems when priority scanning is applicable, there is no pre-emption of an on going transmission to check for activity on a priority talkgroup. Only when the scanner is monitoring the control channel is when priority "kicks in".
What I've seen happen on a P25 system is that I can be holding on a talkgroup (as in not scanning). If there is no activity on that talkgroup and a talkgroup I have selected to be a priority talkgroup becomes active, the scanner goes from that "held" channel to the active priority talkgroup.
Pre-emption of an on going transmission on a non priority talkgroup can occur on certain Motorola systems, but only when certain conditions are present. These conditions are 1-the radio system administrators have marked a talkgroup as a priority talkgroup and 2-you have marked your scanner programming so such talkgroup(s) are priority. If those two conditions are present, then your scanner will stop listening to a non priority talkgroup and jump to an active priority talkgroup.
Suffice it to say the concept of "Priority" is pretty complex and it is not easily undestood at first blush.
That is correct.
As is the rest of ofd8001's post.
I will add that to check to see if a priority TG is active on a trunked system, the scanner must spend 1-2 seconds on that system (it must monitor the control channel for all channel grants/updates). Would you tolerate a 1-2 second break in audio (per trunked system you have priority TGs set for) every 2 seconds? In a hypothetical trunked DND mode, the scanner would still spend more time checking priority channels than actually scanning.
Another thing worth mentioning. . .
From time to time it is asked "What good is priority scanning on a trunked system, if it will not pre-empt a transmission to jump to an active priority talkgroup?"
With trunked systems, several talkgroups may be active at any one given time. At the conclusion of a transmission, the scanner looks to see what else is going on, so that it will monitor another conversation. With Priority ID Scanning, if given a choice of going to several other transmissions, the scanner will select a priority talkgroup over a non-priority talkgroup as the next conversation it monitors.
From time to time it is asked "What good is priority scanning on a trunked system, if it will not pre-empt a transmission to jump to an active priority talkgroup?"
With trunked systems, several talkgroups may be active at any one given time. At the conclusion of a transmission, the scanner looks to see what else is going on, so that it will monitor another conversation. With Priority ID Scanning, if given a choice of going to several other transmissions, the scanner will select a priority talkgroup over a non-priority talkgroup as the next conversation it monitors.
So with all that being said, (as much as i can understand) am i correct that there isn't much benefit to setting trunked ID's as priority channels? Since the scanner will only stop on them when it's already scanning their system, and likely would stop on them anyway.
If there are priority channels active AND non-priority channels active, you will hear the priority channels, so there is some benefit if you would rather hear the priority channels over the non-priority channels. I guess it would depend on how busy the system in question is. The more busy, the more you may want the priority set so you hear those channels.
Thanks Voyager. Now i get it !!
It's also possible that Uniden hasn't "fully cracked the nut" yet. Our fire department P25 trunked radios would do priority. For example I had my radio in scan mode scanning to several channels and the channel selector switch would be on "Fire 5". I could be listening to a transmission on Fire 1, but if Fire 5 became active, the radio would jump from Fire 1 to Fire 5.
Of course I'm comparing a $2,500 radio to a $500 scanner and my expectations/thinking bar may be set too high.
Of course I'm comparing a $2,500 radio to a $500 scanner and my expectations/thinking bar may be set too high.
It might also require the system to specifically tell your registered radio to switch which is not possible with an (unregistered) scanner. I've never dived into the P25 format enough to see how the priority works. Your nut theory may be correct, too, but I would have expected DVSI to provide that part of the code with the basic P25 decoding scheme they purchased.
My understanding of my state's P25 system is that a talkgroup is marked as priority in the system if a user on that talkgroup presses their emergency button. Beyond that, I'm not sure if there is any type of priority structure within the system.
I believe P25 systems can be configured several ways.
I don't know if "priority" is the appropriate term, but systems can be configured such that there are levels of priority for system use. These "priorities" allow certain classes of uses to access the next available channel if they system is clogged. For example a firefighter versus the dog catcher.
Our local system is such that if a responder presses the emergency button, that user gets priority to use the system, even to the point of disrupting an on-going conversation if the system is busy. That user would "hold" the "ultimate priority" until the emergency button is re-set. So in our case, the radio holds the priority and not the talkgroup. That's because a user could be on different talkgroups depending on what is going on at the time.
The are other features associated with an emergency button. Whether they are used and how they are used, depends on the thinking of the system administrator. Radios in the emergency mode can be steered to a special talkgroup used only for emergency purposes. The radio in an emergency mode can be forced to transmit by the dispatcher so the dispatcher can listen to what is going on in the background.
I don't know if "priority" is the appropriate term, but systems can be configured such that there are levels of priority for system use. These "priorities" allow certain classes of uses to access the next available channel if they system is clogged. For example a firefighter versus the dog catcher.
Our local system is such that if a responder presses the emergency button, that user gets priority to use the system, even to the point of disrupting an on-going conversation if the system is busy. That user would "hold" the "ultimate priority" until the emergency button is re-set. So in our case, the radio holds the priority and not the talkgroup. That's because a user could be on different talkgroups depending on what is going on at the time.
The are other features associated with an emergency button. Whether they are used and how they are used, depends on the thinking of the system administrator. Radios in the emergency mode can be steered to a special talkgroup used only for emergency purposes. The radio in an emergency mode can be forced to transmit by the dispatcher so the dispatcher can listen to what is going on in the background.
ScannerSK
Member
I apologize to revive this old thread however the above specific comment came instantly to mind with an issue I'm having with the Uniden BCD436HP scanner. I live in Weld County, Colorado where we are on a separate county system from the state system. I would like to spend an equal amount of time scanning both systems however the county system only requires a single site to be entered while the state system requires around 6-10 sites to monitored to capture all the desired traffic. This creates a large discrepancy or imbalance between how much time my scanner is spending on each of the two systems.
The GRE scanners (PSR-500/600 and similar RadioShack/Whistler models) have an option to check a different site/control channel with each scan cycle (using the stationary and check all CC's no options). With this setting, a person could have one system with a single control channel and a second P25 system with a dozen active strong control channels and an equal amount of time will be spent scanning each system. The Uniden scanners offer nothing at all comparable to this important GRE feature.
90% of the traffic I wish to monitor is on the county system which only requires one site to be monitored while about 10% of the traffic I wish to monitor is on the state system which requires 6-10 sites to monitored to capture all the desired traffic.
The one possible work around which came to mind and would make sense (not a jimmy rig) was setting priorities on all the county system talkgroups. At last, this will not work either as priorities are only checked within the system actively being received at any given time.
Personally, I think talkgroup priorities should be capable of being checked across systems between lists of sites being checked in other systems. Then I would have the ability to add a priority to all my county talkgroups which would then be checked between each of the state sites being checked. This would allow a work around to compensate for the missing feature in Uniden scanners which GRE offers (capability to spend equal amounts of time scanning different systems when there is a large discrepancy between the total number of sites programmed in for each system to capture all desired traffic).
This one missing feature has kept me away from Uniden for years.
Just a thought...
Shawn
Last edited:
That's a pretty atypical scenario for two reasons:
1. With most systems and user antenna configurations, it's not even possible to receive 6-10 sites.
2. Most users aren't interested in sites carrying traffic several jurisdictions away from their location, so hearing traffic from that many sites would be deemed undesirable.
If you seriously need to scan 6-10 sites on one system, the best solution would be to dedicate a scanner to monitoring that system, and use a second scanner to monitor other traffic. You're going to miss a lot of traffic on the state system even if you were able to do what you propose.
Well, there is a way you could do what you wish on your 436. It isn't the most efficient and would be a pain to maintain. Plus I would not do it on a bet and I'm offering this up as a way of accomplishing what you want.
Let's assume you need to monitor 6 sites on the state system. You could make 5 copies of the county system, for a total of 6 versions, each having their own unique FL and name.
FL 1 County System_Original
FL 2 State System (Site 1)
FL 3 County System_Copy 1
FL 4 State System (Site 2)
FL 5 County System_Copy 2
FL 6 State System (Site 3)
FL 7 County System_Copy 3
FL 8 State System (Site 4)
FL 9 County System_Copy 4
FL 10 State System (Site 5)
FL 11 County System_Copy 5
FL 12 State System (Site 6)
FL 13 County System_Copy 6
You'll see the pattern - the scanner monitors the county system, then goes to one of the state sites. It goes back to monitoring the county system (though it is a separate "clone"), then to the next state site. It goes on until all state sites were sampled.
If it was me, I'd either put up with the 6-10 state sites or get another scanner. I might cull the state list and because traffic on "Site 1" might also be on "Site 2".
Let's assume you need to monitor 6 sites on the state system. You could make 5 copies of the county system, for a total of 6 versions, each having their own unique FL and name.
FL 1 County System_Original
FL 2 State System (Site 1)
FL 3 County System_Copy 1
FL 4 State System (Site 2)
FL 5 County System_Copy 2
FL 6 State System (Site 3)
FL 7 County System_Copy 3
FL 8 State System (Site 4)
FL 9 County System_Copy 4
FL 10 State System (Site 5)
FL 11 County System_Copy 5
FL 12 State System (Site 6)
FL 13 County System_Copy 6
You'll see the pattern - the scanner monitors the county system, then goes to one of the state sites. It goes back to monitoring the county system (though it is a separate "clone"), then to the next state site. It goes on until all state sites were sampled.
If it was me, I'd either put up with the 6-10 state sites or get another scanner. I might cull the state list and because traffic on "Site 1" might also be on "Site 2".
ScannerSK
Member
True, I'm just saying GRE has a capability that Uniden does not in that it can sample a different site with each scan cycle without the need to add additional systems or sites.
I can probably receive 20-30 sites clearly on our state system (we have many mountain top sites in Colorado) and the users I wish to listen to affiliate with different sites at different times so the more sites that can be entered the more likely I will capture the desired traffic.
Shawn
Last edited:
Scanning a site at random, or choosing only one site in a sequence per scan of the system isn't really a solution. You'll miss a lot of traffic. Unless you're seriously interested in EMS calls 5 counties away from your location, you can probably choose 3-4 sites nearest you, scan those, and hear the majority of traffic of interest.
ScannerSK
Member
Trust me, I have considered doing what you mention above or even combining the sites for both systems into a single system in the scanner. However, both are jimmy rigs and come with additional problems such as having to turn off and on large numbers of systems or quick keys each time, the requirment to duplicate any talkgroup or system changes numerous times over, etc. The GRE scanners do not have to be jimmy rigged to allow equal scan time regardless of the number of sites active.
I also monitor other systems at times as well (Denver, MARC, Aurora, Conventional). If I did what is mentioned above, the scanner would be spending an enormous amount of time on just two systems. This would necessitate also adding 5-10 systems for Denver and 5-10 systems for MARC and 5-10 systems for Aurora and 5-10 systems for conventional channels. At some point this would get absurd. I would have over 50 systems when only 6 are required in GRE scanners to do the same thing.
I was just thinking if priorities on talkgroups in one system were capable of being checked in-between the scanning of sites on another system this would solve this specific issue and would be a helpful feature.
I still run into additional programming issues with Uniden scanners beside the above: inability to assign talkgroups/conventional channels "across systems" into a single scan list (as GRE scanners can do), no sound notification when new unidentified talkgroups are received (a small thing which GRE scanners allow), and issues with patched talkgroup handling and the requirement to enter in an unknown "super group" to enable monitoring desired traffic on the non super group.
However, on topic, it would be nice to be able to sample priorities in one system between the scanning of sites in another system.
Shawn
IMO this is all making a mountain out of a molehill. Just because you can receive 30 sites from a system doesn't mean you need to scan them all to hear traffic of interest. Even if you dedicate a scanner to that system, scanning 30 sites would take so long you'd miss a lot of traffic under ideal circumstances. Throwing in priority scanning of another system just makes matters worse. No matter what scanning strategy you use, you're spreading too little butter on too much bread.
- Status
Similar threads
