Slow Scan Rate on P25 Digital VHF System

[eriepascannist]

Hi all, I'm monitoring the Chautauqua county (NY) public safety system on my Uniden BCD536HP scanner. It is a VHF system and I was aware of the monitoring difficulties with that type of system in the initial firmware release; I am up to date on firmware however at this time.
I was wondering if anyone else ever had issues with the scan time on this or other kinds of trunked systems. I find We have roughly 13 talkgroups on our system, which is certainly not a large number. I am often missing transmissions because the scanner often takes 5 seconds or more to get through these talkgroups in Scan mode. Add in some extra chatter, and I could (and often do) miss entire fire dispatches or PD calls because of the excessive lag time.
I have my talkgroups organized into 3 Fav Lists (I didn't dive too much into the memory architecture when I first got the radio, and haven't bothered to change it since). I tried listening to just one list with 2 talkgroups in it to see if that was the problem; if I skipped a transmission on one, it took around 3 seconds to get back to it again (even with just one other TG being scanned).
I am on the edge of the county, but there doesn't appear to be a signal quality issue; I never have dropped or garbled transmissions.

Am I just too used to conventional systems and expecting too much out of the scanner? (This is my first exposure to trunked systems at all, let alone digital ones.) Is this "lag time" standard for the radio to follow the control data and "know" what is happening on the system? Or is there some setting or option that might help the problem?
(I noticed the live feed online for Chaut. county on RR, found here,
Chautauqua County Public Safety South - Digital
doesn't seem to have the delay issue; I think I saw somewhere along the way that he is using a 436HP which if I understand correctly is basically identical to my 536, just in portable form.)

 

[UPMan]

The number of programmed TG's has absolutely no affect on how long it takes to scan a trunked system. When "scanning" a trunked system, the scanner actually just sits on one frequency (the control channel) and watches the channel grants and channel updates as they appear in the data stream. The scanner compares the received grants/updates to the TGs you have programmed and, if one of those becomes active, switches to the appropriate voice frequency to monitor the TG.

Do you have an excessive channel delay set? That setting controls how long the scanner waits for a reply on the same TG before paying attention to grants/updates for other TGS.

 

[Badboy536]

The one thing that can slow down on a trunked system is if it has multiple sites and it has to scan through multiple sites and some of the sites are out of range that can slow down the scan rate.Try to determine the sites that your scanner hits on in your area and maybe block out the ones it does not hit on.in my area
I block out a few sites and only use the Closest 2 to my house.there are like 6 sites on the system I listen 2.using just the 2 closest sites really helped me when it comes to hearing Reply traffic .

 

[eriepascannist]

Thank you both for your replies. Here is the page for the system:
Chautauqua County Public Safety System Trunking System, Chautauqua County, New York - Scanner Frequencies

Per my (albeit limited) understanding, this is a simulcast system so the blocking out of sites isn't really possible. I've tried adjusting the squelch to various levels, up and down (as I understand there can be issues with systems of this variety for various reasons), , but to no avail.

I haven't changed the delay/hold settings at all from factory defaults.

 

[marksmith]

If this is simulcast system, that is probably more your issue than anything else.

As Upman said, a scanner does not scan talkgroups.

There are some things to try, but limited.

Moving scanner locations, even a few inches can have an effect.

Turning on attenuation for this system can reduce the number of towers received, or using a worse antenna or directional one.

These last 2 things reduce signal received. If you can reduce reception to nearest tower only, it can reduce simulcast distortion.

536/436/ws1095/996p2/996xt/325p2/396xt/psr800/396t/HP-1/HP-2 & others

 

[eriepascannist]

Understood. I was under the impression that simulcast issues were more related to signal quality and not the time it takes to receive them. But I understand the point. I will be moving to a new location in a month or so and perhaps the issue will resolve there (closer to one tower, as opposed to a more neutral location.) I just thought maybe it was something else I could resolve in the meantime.

 

[marksmith]

Not sure what you mean by "the time it takes to receive them"?

The issue with simulcast distortion is

1. Scanners are not built to receive Sinai on same frequency from 2 different sources simultaneously.

2. Usually can be improved by DECREASING signal strength, to get 1 tower instead of many

536/436/ws1095/996p2/996xt/325p2/396xt/psr800/396t/HP-1/HP-2 & others

 

[greggk]

Do you have your squelch turned down low? Very low squelch will really slow up the scanning. Greg

 

[eriepascannist]

I was aware of the distortion issue on simulcast systems; however these signals are perfectly clear and I have never had distortion issues. That is why I was under the impression that that wasn't the problem. By that I just mean what I described in detail in my initial post; even when air is dead on other TG's I might miss the first 5 seconds or more of a transmission because the scanner doesn't "find" it in time; or if I skip a transmission, even when air is dead on other TG's, it takes 5 seconds or more for it to cycle through the other 12 TG's to get back to the one with traffic. (I've missed entire fire dispatches before and just heard the time at the end, which is even longer than 5 seconds by a good bit.) I'm content with the answer that this is simply "as good as it gets"; I just don't want to be missing traffic if there is something I can do about it.

Greg, thank you - yes, I have the squelch set so on an analog system it is just above the noise/open threshold.

 

[UPMan]

The scanner does not "cycle through" anything when monitoring a trunked system. See my previous post.

What does the system Analyze System function tell you regarding error rate?

 

[greggk]

FWIW..and I don't mean to repeat myself, but I meant try turning the squelch about 1/2 way thru, not just sitting past the squelch noise.

Again, not to insult..just trying to help. Greg

 

[jonwienke]

On a trunked system, scan speed has nothing at all to do with the number of talkgroups. It has everything to do with the number of sites you are scanning, and the number of frequencies programmed for each site.

Your problen is that you have multiple instances of the system in separate favorite lists.

NEVER do that. EVER. You are guaranteed to scan slowly and miss traffic. Here is why:

The scanner doesn't scan talkgroups, it scans sites. When it starts scanning a site, it takes a second or 2 to sync with the control channel and start seeing channel grants. If you have the system split among 3 favorite lists, there is a 2/3 probability that a transmission will be ignored by the scanner. After a second or two, it will go back to the SAME site, monitor the SAME control channel, and look for traffic from the second set of talkgroups. If the call isn't in those talkgroups, it will move to the third favorite list, go back to the SAME control channel on the SAME SITE a third time (after an additional 1-2 second delay), and then finally play the traffic.

In contrast, if you program the system in a single favorite list, the site and control channel are only scanned once. If you hold on the system, the scanner will never break lock on the control channel--no 1-2-second re-sync delay. If you want to group the talkgroups into categories, create multiple Departments under the system, and use quick keys or whatever to toggle the departments on and off. That will still allow you to ignore a set of talkgroups if needed, without scanning the system redundantly and inefficiently.

Programming the system this way will miss far less traffic than your current setup.

 

[UPMan]

Actually, sync is very quick, but it takes 1-2 seconds for the site controller to transmit all of the channel grants/updates, otherwise your description is sound. I did not realize that he had programmed it the way you described. If that is the case, the scanner will constantly miss transmissions for exactly the reason you describe.

 

[marksmith]

Correct.
You want the system to be in one favorites list, and you can put the talkgroups in as many departments of that system site as you want to break them down, but not in different lists.

It will monitor one control channel and instantly produce audio on any talkgroup that becomes active, rather than trying to monitor several control channels (that are all the same), but have just certain talkgroups associated with each.

536/436/ws1095/996p2/996xt/325p2/396xt/psr800/396t/HP-1/HP-2 & others

 

[UPMan]

I apologize again for missing where you described how it is programmed. Here is what the scanner is going to do based on its current programming. I'm assuming FL1=PD, FL2=FD, FL3=Other

With all 3 FL's enabled the scanner will:

Check for PD calls for about 2 seconds
Check for FD calls for about 2 seconds
Check for OTHER for about 2 seconds
Check for PD calls for about 2 seconds
Check for FD calls for about 2 seconds
and so on.

While checking PD, it will not check FD or Other.

With the channels all programmed into one system in one FL, the scanner would instead:

Check for PD/FD/Other for about 2 seconds.
Check for PD/FD/Other for about 2 seconds...
well, actually it is just going to continuously check for activity on all programmed channels continuously, which is what I believe you really want.

If you want to be able to independently turn PD, FD, and Other on/off, then put each type into its own department and assign a Department Quick Key. Example:

PD = DQK 1
FD = DQK 2
OTHER = DQK 3

Then, to toggle on/off, you would press:
..01 (for PD)
..02 (for FD)
..03 (for Other)

 

[Poonwart]

Thanks to eriepascannist for starting this thread. I learned I need to reprogram my scanner in a more efficient manner that was not obvious to me.