GRE radio scanning speed

[Patrick_]

I've noticed that the new (and older, RS-branded) GRE radios have a much lower scan speed than their Uniden counterparts. 55 channels per second for the PSR-500, while the BCD396T can apparently get 100 channels per second, and the BR330T 90CPS (according to the wiki).

I've not noticed anyone really complaining about this... is there really any real-world difference in the conventional scan speed?

 

[proquist96]

scan speed

I noticed this thread not getting any replies and what i say may get it moving along. I have read that Unidens will pass up transmissions while GRE made scanners (pro96) is talking away in side by side comparisons. In my opinion a faster scan speed doesn't stop very well. Other features on the Uniden (AGC) doesn't appear to work either according to what i've read. The PSR-500/600 is the new standard which others will be judged and hope to get one.Make a wish foundation please send me a psr-500 scanner.

 

[Air490]

In most circumstances, I don't think it makes that much difference.

The only time I have found a fast scan speed to be very useful is when scanning a large number of Milair frequencies.

 

[n2mdk]

There is also a difference in scanning channels like in search mode and scanning things like Trunked Systems. My Pro-97 scans much faster than my BC246T does on TRS.

 

[gmclam]

Too many channels to scan doesn't work well

There are a lot of factors to consider before a complete/accurate answer can be given to this question. BUT, if everything is the same between 2 scanners, generally the scanner with the slower scan speed will be more "sensitive". Consider what all goes on inside the scanner when switching from one frequency to the next. It takes time for the CPU to issue the commands to the chips to make the switch. Then it takes time for the chips to respond. Then it takes time for the signal to get from the antenna to a point where it is detected by the CPU; therefore keeping the CPU from scanning to the next.

Some designs use faster CPUs or ICs than others. Each design will have some minimum "dwell" time needed to acquire a (weak) signal. If the scanner doesn't obey that minimum time, the effect is it is less sensitive.

Hope this helps.

 

[troymail]

It's not clear to me exactly how they come up with the scan rates -- probably done by the same people that certify MPG on the sticker of new cars (you almost never get that much).

I have no info on the difference between the GRE and Uniden but I do know that I have a BC-296 and a BC-396 that many times are side-by-side and even thought the 396 is a newer model, it misses the beginning on more transmissions than my 296... I've always wondered why.

 

[Stick0413]

It's not clear to me exactly how they come up with the scan rates -- probably done by the same people that certify MPG on the sticker of new cars (you almost never get that much).

lol I am thinking similar to the way you are. Except I am thinking of it like this. Since there is no industry standard of measuring this then who is to say its all accurate. One might say have a scan rate of XX and that is scanning only conventional channels (normally scans faster) and another might have a scan rate of YY scanning trunked channels/talkgroups. Personally I would like to see both Uniden and GRE say it scans this fast exclusivly with a trunked system and this fast with conventional frequencies. Then we could determine about what our scan speed would be by what we listen to.

 

[gmclam]

Creative measurements

The published "scan speed" can only be for conventional channels. It is actually pretty simple math. But when it comes to trunked channels, there is no good way to measure true scan speed. The reality is that the scanner is sitting on the control channel - perhaps at the rate of 1 channel per second. But that one control channel might represent 1000 talkgroups - so that would be 1000ch/sec. Neither is accurate.

My gripe when it comes to GRE scanners is how they measure the "delay time". RS publishes it as a 2 second delay. It is not even 1 second. And it has been this way on RS scanners I've had for over 30 years.

 

[kikito]

When it comes to trunked systems, the scanners don't really scan for talkgroups like they do conventional frequencies. In other words, the scanner does not scan a list of talkgroups nor does it scans for every possible talkgroup incrementally or the like.

The scanner analyzes the control channel waiting for talkgroups to become active. When one does, it checks if it's program on your scanlist, what might the tag for it, if it's locked out and so on. That's the kind of function the scanner performs when "scanning" a trunked system.

 

[Gilligan]

My gripe when it comes to GRE scanners is how they measure the "delay time". RS publishes it as a 2 second delay. It is not even 1 second. And it has been this way on RS scanners I've had for over 30 years.

I definately would like an accurate delay time (and optional delay times, for that matter) on the new GRE scanners...

 

[JASII]

I did some testing on conventional channels and it seemed that the scan speed was only about 25 channels per second.

 

[DonS]

I did some testing on conventional channels and it seemed that the scan speed was only about 25 channels per second.

I seem to get about 56 channels per second. 500 CONV objects (FM mode, Sq Mode=None, RF squelch never opening) takes about 8.9 seconds.

If you're only getting 25 channels per second, it sounds like you have CTCSS/DCS/NAC values programmed and RF squelch is opening. The scanner (necessarily) has to wait around looking for your programmed CTCSS/DCS/NAC value. This will definitely slow down the "scanning rate".

 

[k9xyz]

I seem to get about 56 channels per second. 500 CONV objects (FM mode, Sq Mode=None, RF squelch never opening) takes about 8.9 seconds.

If you're only getting 25 channels per second, it sounds like you have CTCSS/DCS/NAC values programmed and RF squelch is opening. The scanner (necessarily) has to wait around looking for your programmed CTCSS/DCS/NAC value. This will definitely slow down the "scanning rate".

I agree in my observations I get over 50 per sec as well on conventional. I would say the rate as stated by gre is on the money. The scan speed is fine, no missed calls or anything here.