Scanning a trunked system

Joined
Sep 19, 2003
Messages
133
Location
Denver, Colorado
#1
A few years ago I programmed a Uniden 436 and a GRE PSR-800 with the exactly the same with 3 seperate trunk systems. Some sites were 10 freq's and the other had 20 or so. I noticed the Uniden was sweeping through every frequency on a tower site while my GRE responded to the first active TG from another site. Is this the way Uniden scanners are made to scan since the 396T was first released in this format?
I was missing a ton of radio traffic, so I sold my Uniden. Can some one correct me if I am wrong or that is the way Uniden radios work.
 
Joined
Sep 8, 2006
Messages
2,550
Location
Stockholm, Sweden
#2
Uniden scanner trunktrack from the control channel, it doesn't need to scan all frequencies and should be more efficient than the GRE if you had the system program correctly.
What type of system was it, Moto analog TypeII ?

/Ubbe
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
#3
Uniden scanner trunktrack from the control channel, it doesn't need to scan all frequencies and should be more efficient than the GRE if you had the system program correctly.
What type of system was it, Moto analog TypeII ?

/Ubbe
This is a somewhat (at least potentially) incorrect statement.

For other than DMR and NXDN, both Uniden and GRE/Whistler scanners will find and only care about the control channel frequency -- and for the most part doesn't need or use the rest.

One major difference between newer Uniden's and GRE/Whistlers (since the PSR-800) is that the GRE/Whistler will find the first good/solid control channel (for any site that is programmed) and stay with/on that control channel (ignoring other sites for that system). The Uniden will try to look at each and every site you have programmed - even if not in range - and try to find a control channel. Even with location control enabled/in use, the Uniden's will tend to potentially try to scan sites that are not receivable from a given location.

On a related note - now that the SDS-100 can display trunked system site frequencies while scanning, I routinely see it stepping through all of the programmed sites (and individual frequencies) trying to find something that is not receivable.
 
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#5
A few years ago I programmed a Uniden 436 and a GRE PSR-800 with the exactly the same with 3 seperate trunk systems. Some sites were 10 freq's and the other had 20 or so. I noticed the Uniden was sweeping through every frequency on a tower site while my GRE responded to the first active TG from another site. Is this the way Uniden scanners are made to scan since the 396T was first released in this format?
No. There's a couple of steps to the process.

First, Uniden uses Location Control to decide which site(s) are in range and scannable. If you disable Location Control, have your location set incorrectly, or have site location data set incorrectly, the scanner will waste time trying to scan sites that are not actually in range.

But if the site is in range, the scanner will scan through the site frequencies until it finds the control channel. You can streamline this by putting the current control channel at the beginning of the list of frequencies for the site. Once the scanner finds the control channel, it will not look at other programmed site frequencies.

When the scanner finds the control channel, it will spend 1-2 seconds parsing it for active transmissions. If there is one, the scanner will look up the Talkgroup ID to see if its Service Type is enabled, and will also look up the Department for the Talkgroup to see if you are in the Department's service area as defined by your Location Control settings. If not, the scanner will move on and skip the transmission. But if all the criteria are met, the scanner will switch to the voice channel specified by the control channel. For P25 systems, the voice channel frequency doesn't have to be programmed, the scanner gets it from the control channel.

The most common error is not having all of the appropriate Service Types turned on, which causes the scanner to ignore traffic it can easily receive, but thinks (mistakenly) that you don't want to hear.

The next most common error is having Location Control misconfigured, particularly having it turned OFF for large multi-site trunked systems. This forces the scanner to waste a lot of time scanning sites it cannot hear, which results in missing traffic. A lesser (but common even in the RR database) error is not having the control channel as the first frequency listed for a site. This isn't a critical error, but slows the scanner down a little by forcing it to check frequencies other than the control channel freq before finding the control channel.
 
Joined
Sep 8, 2006
Messages
2,550
Location
Stockholm, Sweden
#6
...Uniden was sweeping through every frequency on a tower site while my GRE responded to the first active TG from another site.... I was missing a ton of radio traffic....
If there are no carrier on a frequency it scans with 80ch/s and wouldn't slow down anything to make you miss a ton of traffic. Uniden stays on a control channel as long as it is active with calls that will direct the scanner to voice channels. If it doesn't detect any calls for a while it will start to scan for a more active control channel on the same site and then on to other sites if they are enabled. That way it will let you listen to the most active site, if you don't force it to behave differently.

I know of no system type that would let the Uniden scanner go through every frequency of a tower and be so slow about it that you would miss a ton of traffic.

So no, that is not the way Uniden scanners should work.

/Ubbe
 

ofd8001

Member
Premium Subscriber
Joined
Feb 6, 2004
Messages
5,942
Location
Louisville, KY
#7
If there are no carrier on a frequency it scans with 80ch/s and wouldn't slow down anything to make you miss a ton of traffic.

I know of no system type that would let the Uniden scanner go through every frequency of a tower and be so slow about it that you would miss a ton of traffic.
It's possible to have a statewide system with 100+ sites and averaging 5 potential control channels per site. If location control wasn't used, the scanner could be going through 500+ frequencies to find a control channel. So at 80 channels per second, that's 6 seconds or more wasted on out of range sites. Most voice transmissions are less than that 6 seconds, so the time spent searching for an active control channel could lead to many missed transmissions.

On the original post of why did one scanner receive something and the other did not . . . It's possible you may be at the fringe of reception and one squelch setting is too tight to receive. Could be antenna orientation. Could be one scanner was desensitized by something. Lots of possible explanations.
 
Joined
Jul 18, 2014
Messages
8,884
Location
PA
#8
Most likely explanation though is user error, especially not enabling or misconfiguring location control (causes the scanner to waste a lot of time scanning out of range sites), not having the appropriate service types enabled (causes the scanner to ignore desired traffic), or trying to manually prune trunked system objects from a favorite list and deleting site(s) or department(s) needed to hear the desired traffic.
 
Joined
Sep 8, 2006
Messages
2,550
Location
Stockholm, Sweden
#9
It was scanning a limited number of frequencies of a tower site, not all statewide tower sites that where out of range.
Must have been a setup error, wrong zip code or GPS data, and no reason for getting rid of a fine scanner.

/Ubbe
 
Top