BCD536HP - Slow Scan - My Workaround

[shonc182]

This may or may not be of use to some or any, but I'm hoping it will help. Just as important, I'm hoping somebody will take a look and help me out with making some improvement. It is probably only applicable to people living in larger metropolitan areas. I know its long and if you are not struggling with this issue there is probably no reason to run through it.

Slow Scan - Workaround

My Situation - I live in the Portland, OR metro area and - for any locals - I have omitted discussion of Vancouver/Clark Co. for simplification. Basically, I have three separate counties to scan police and fire. There is more, but I want these set up and working. All three of these counties are served by two trunking systems - Portland Public Safety (PPS) and WCCCA. Each county is primarily served by one trunking system, but makes limited use of the other for some TGID's. All counties also have at least one conventional system in addition to these for some frequencies.

I have always had 6 banks (one police and 1 fire/ems for each county) containing the relevant control channels and TGID's. I wanted my FL's to match this configuration for convenience and control. Using Sentinel, this is what it looked like.

F0-Washington Co - Police
---S0 WCCCA
------Police Departments 0 thru nn
---S1 PPS
------Police Departments 0 thru n
---S2 Conventional Sys
------Departments 0 thru n
---S3 Conventional Sys
------Departments 0 thru n
F1-Mulnomah Co. - Police
---S0 PPS
------Departments 0 thru nn
---S1 WCCCA
------Departments 0 thru n
---S2 Conventional Sys
------Departments 0 thru n
F2-Clackamas Co - Police
---S0 WCCCA
------Departments
---S1 PPS
------Departments....

.....and so on - giving me three police FL's and three fire/ems FL's.

What was happening (I think) - It is worth noting that the bulk of the TGID's are in S0 for each FL and the lesser used TGID's are located in the higher S numbers. Considering the scan order F0,S0; F1,S0; F2,S0;.....F0,S1; F1,S1; F2,S1....F0,S2; F1,S2; F2,S2.... - The first pass through the FL's yielded the best results, the subsequent passes yielded limited results because all the good stuff is in the S0's. I was just waiting for 2 or three passes through the FL's - often for nothing.

Also, I had assigned QK's to all of the sites that Sentinel brings in when you add a system or department into your FL, turning off all QK's except the simulcast site in each system within each FL. Even though the QK's were disabled, I could still see them flash by in the display.

All of this leads up to an initial performance that can only be described as abysmal.

The Experiment - Through a series of tweaks throughout the past week - the details of which I cannot fully recall, but did include "Avoid" all but the simulcast site within each system in lieu of shutting off QK's - I got this to where performance was just poor.

I set up 6 FL's for my 536HP that were nearly identical to 6 banks in my BC785D. The major difference for obvious reasons, is the site setup for the 536HP is as described as above and for the 785D - banks contain only control channels and is set for Ctrl Ch only scanning. Over this weekend I ran multiple 5 minute tests at various times throughout the day with both units going where I counted the number of transmissions captured that had an audible voice (not channels that were stopped on) - more on this later.

The results: My brand new 536HP received 85% as many transmissions as my ~6 year old 785D - of those it did land on my 785 beat it there 25% of the time. I have no data from the initial setup, but sadly this was a dramatic improvement.

The Improvement - For people that may only have this issue, this might be enough. In any regard, the following change is an improvement for me and may be good enough if I can solve another fundamental issue with this scanner - "Missed/Cutoff transmissions"

Very simply, I renumbered all of the systems to S0 to cut the number of passes through the FL's to once. From above:

F0-Washington Co - Police
---S0 WCCCA
------Police Departments 0 thru nn
---S0 PPS
------Police Departments 0 thru n
---S0 Conventional Sys
------Departments 0 thru n
---S0 Conventional Sys
------Departments 0 thru n
F1-Mulnomah Co. - Police
---S0 PPS
------Departments 0 thru nn
---S0 WCCCA
------Departments 0 thru n
---S0 Conventional Sys
.....and so on.

I believe (but can't really verify) the scan order is now; F0,S0; F0,S0; F0,S0....F1,S0; F1,S0; F1,S0.....F2,S0..... - "Systems with the same QK are scanned in order of creation" from pg 51 of my manual.

The Results: Now my new 536HP catches 90% of the transmissions as my old 785D and still gets beat 25% of the time.

Other Factors - I hadn't realized how big of an issue that I had with missing or incomplete transmissions until I started counting. I decided to do a modified experiment, albeit on a limited sample size relative to the first two. I decided to count any stop on a channel whether it had audible voice or not.

The Results: The 536 caught 94% as much as the 785D.

This is still not stellar, but would probably be getting much closer to even.

 

[wise871]

Looks like you did a lot of research. I just hope Uniden address the scan speed issues.

 

[signal500]

This may or may not be of use to some or any, but I'm hoping it will help. Just as important, I'm hoping somebody will take a look and help me out with making some improvement. It is probably only applicable to people living in larger metropolitan areas. I know its long and if you are not struggling with this issue there is probably no reason to run through it.

Slow Scan - Workaround

My Situation - I live in the Portland, OR metro area and - for any locals - I have omitted discussion of Vancouver/Clark Co. for simplification. Basically, I have three separate counties to scan police and fire. There is more, but I want these set up and working. All three of these counties are served by two trunking systems - Portland Public Safety (PPS) and WCCCA. Each county is primarily served by one trunking system, but makes limited use of the other for some TGID's. All counties also have at least one conventional system in addition to these for some frequencies.

I have always had 6 banks (one police and 1 fire/ems for each county) containing the relevant control channels and TGID's. I wanted my FL's to match this configuration for convenience and control. Using Sentinel, this is what it looked like.

F0-Washington Co - Police
---S0 WCCCA
------Police Departments 0 thru nn
---S1 PPS
------Police Departments 0 thru n
---S2 Conventional Sys
------Departments 0 thru n
---S3 Conventional Sys
------Departments 0 thru n
F1-Mulnomah Co. - Police
---S0 PPS
------Departments 0 thru nn
---S1 WCCCA
------Departments 0 thru n
---S2 Conventional Sys
------Departments 0 thru n
F2-Clackamas Co - Police
---S0 WCCCA
------Departments
---S1 PPS
------Departments....

.....and so on - giving me three police FL's and three fire/ems FL's.

What was happening (I think) - It is worth noting that the bulk of the TGID's are in S0 for each FL and the lesser used TGID's are located in the higher S numbers. Considering the scan order F0,S0; F1,S0; F2,S0;.....F0,S1; F1,S1; F2,S1....F0,S2; F1,S2; F2,S2.... - The first pass through the FL's yielded the best results, the subsequent passes yielded limited results because all the good stuff is in the S0's. I was just waiting for 2 or three passes through the FL's - often for nothing.

Also, I had assigned QK's to all of the sites that Sentinel brings in when you add a system or department into your FL, turning off all QK's except the simulcast site in each system within each FL. Even though the QK's were disabled, I could still see them flash by in the display.

All of this leads up to an initial performance that can only be described as abysmal.

The Experiment - Through a series of tweaks throughout the past week - the details of which I cannot fully recall, but did include "Avoid" all but the simulcast site within each system in lieu of shutting off QK's - I got this to where performance was just poor.

I set up 6 FL's for my 536HP that were nearly identical to 6 banks in my BC785D. The major difference for obvious reasons, is the site setup for the 536HP is as described as above and for the 785D - banks contain only control channels and is set for Ctrl Ch only scanning. Over this weekend I ran multiple 5 minute tests at various times throughout the day with both units going where I counted the number of transmissions captured that had an audible voice (not channels that were stopped on) - more on this later.

The results: My brand new 536HP received 85% as many transmissions as my ~6 year old 785D - of those it did land on my 785 beat it there 25% of the time. I have no data from the initial setup, but sadly this was a dramatic improvement.

The Improvement - For people that may only have this issue, this might be enough. In any regard, the following change is an improvement for me and may be good enough if I can solve another fundamental issue with this scanner - "Missed/Cutoff transmissions"

Very simply, I renumbered all of the systems to S0 to cut the number of passes through the FL's to once. From above:

F0-Washington Co - Police
---S0 WCCCA
------Police Departments 0 thru nn
---S0 PPS
------Police Departments 0 thru n
---S0 Conventional Sys
------Departments 0 thru n
---S0 Conventional Sys
------Departments 0 thru n
F1-Mulnomah Co. - Police
---S0 PPS
------Departments 0 thru nn
---S0 WCCCA
------Departments 0 thru n
---S0 Conventional Sys
.....and so on.

I believe (but can't really verify) the scan order is now; F0,S0; F0,S0; F0,S0....F1,S0; F1,S0; F1,S0.....F2,S0..... - "Systems with the same QK are scanned in order of creation" from pg 51 of my manual.

The Results: Now my new 536HP catches 90% of the transmissions as my old 785D and still gets beat 25% of the time.

Other Factors - I hadn't realized how big of an issue that I had with missing or incomplete transmissions until I started counting. I decided to do a modified experiment, albeit on a limited sample size relative to the first two. I decided to count any stop on a channel whether it had audible voice or not.

The Results: The 536 caught 94% as much as the 785D.

This is still not stellar, but would probably be getting much closer to even.

I did the same re-configuration on my favorites. I now have 15 favorites that only have quick key zero (S0) programmed into them. The 536 seems to scan faster and I don't miss as much traffic as I did before. I still believe there needs to be an overall improvement to the scan speed via a firmware update.

 

[Gilligan]

I know this probably sounds like a considerable greater amount of work for initial setup, but considering how your counties are aligned regarding shared systems, I have another suggestion I think you should consider.

Instead of having six favorites lists with the counties divided by police/fire, think about how you typically scan those systems. For example, I would think the following scenarios would generally apply:


1) All police for all 3 counties
2) All fire for all 3 counties
3) Police/Fire for 1st county
4) Police/Fire for 2nd county
5) Police/Fire for 3rd county


If you wanted to take it a step further, and only if there were a fair number of times when you only listened to one type of each county, like police only for 2nd county for example, you could add 6 more scenarios that match your original favorites list setup.


Now basically you would set up 5 favorites lists with those 5 primary scenarios, and each favorites list has both trunked systems and potentially both conventional systems, but you would only scan ONE favorites list instead of up to six of them. Just choose which scanning scenario you are wanting and use the favorites list for that scenario. In this way, you are not re-scanning the same sites over and over but only checking for a small group of active talkgroups on each scan cycle.


I'm considering a similar issue here in MD. My initial thought was to set up a favorites list for Fire and a second for Government (police are encrypted). However, it may be more to my advantage to actually set up 3 lists -- one with fire, second with government, and 3rd with both. You just have a much greater complexity since you're dealing with multiple systems. But I bet you would speed up your scan speed and miss less transmissions.

Just another thought -- If you were scanning all police or all fire, or all of a particular county, using the method I've described, and something exciting came up, you could always use department hold instead of reverting to the six extra favorites lists with each department on its own.

 

[Gilligan]

I understand how the Uniden system chooses the scan order based on favorites list and system, but it seems like it would make a lot more sense if they would just pause the scanner for a moment before actually scanning and sort the lists into a logical scan order that would only scan each trunked system once and during that cycle search for all scannable talkgroups in all scannable lists for each particular system. It would just make more sense...

 

[wise871]

All the above advice is great but that's a lot of extra work just to get it to scan faster. This needs to be fixed in a update.

 

[SCPD]

I found when I changed the Hold time from 4 seconds to 2 seconds per system the scan speed increased. Also changing the Delay on Departments from 4 to 3 helped.

 

[RF23]

The owners manual for both x36HP radios seem to give a slower scan rates than the older radios (80 channels per second) but the word 'Nominal" is used for the new scanners and the word "Maximum" (100 channels per second) is used for the older scanners so they may be the same, I just do not know.

Some seem to think that having a single big FL with more systems/depts. is faster than multiple smaller FLs (the single and multiple FLs total to the same number of channels). Therefore, you want to try to have only one FL if possible. However, this may depend on which systems you are scanning therefore, for us to know if this is true or not we need people trying different methods of programming.

Methods of programming should include all the settings in the radio like the ones mentioned by MaxTracker in the post above this one. Each of these (and they are others) can add up to an increase in scan rate too.

However, some have taken a few channels (10 or 12) put them in the new radios and in an older radio and the new radio still "clipped speech" more. So, we may need both better programming techniques and a firmware adjustment too.

 

[UPMan]

If you program the same trunked system into the scanner multiple times, then the scanner is going to rescan the control channel data multiple times. This is how trunked scanning works. My suggestion would be to make use of the "Department" level of systems and program each trunked system in only one time.

 

[mancow]

I'm confused about the slow scan. My 436 seems to scan extremely fast. Does it just hang on a system for a long time?

 

[UPMan]

Every trunked system site you program into the scanner requires about 1.5-2 seconds for the scanner to determine what channels are active on that site at that time (the amount of time is based on the rate of data transmitted by the site, not the scanner's speed of processing). If you program the system with one receivable site, then put all departments in that system, each pass will take only 1.5 - 2 seconds. If, however, you program the system in multiple times (or program in multiple sites for the system), the scanner is going to take 1.5 - 2 seconds for each instance the system is programmed (or for each programmed site).

The solution to "slow scanning" of trunked systems is to:

a) Only program each trunked system into the scanner one time; and
b) Only have enabled the minimum number of sites necessary to ensure all channels of interest are received.

In the OP's first example, from what I can tell WCCCA was programmed in 6 separate times, as was PPS. I cannot tell how many sites each of those systems had programmed, but assuming it was only one site per system the scanner was spending 9-12 seconds scanning each system instead of 1.5-2 seconds per system if each had been programmed only one time. Of course, if either system had more than one site programmed, the "dwell" time would have been multiplied (18-24 seconds for 2 sites, 27-36 seconds for 3 sites, etc).

 

[mancow]

Ah, if that's what he's doing. No wonder his radio is dwelling so long.

 

[Gilligan]

If you program the same trunked system into the scanner multiple times, then the scanner is going to rescan the control channel data multiple times. This is how trunked scanning works. My suggestion would be to make use of the "Department" level of systems and program each trunked system in only one time.

Thanks for the explanation. This was what I was trying to explain... It would make sense in a future firmware update, however, if the scanner would sort through all "scannable" systems and talkgroups and quickly come up with its own internal "scanlist" for situations such as this.

 

[mancow]

Thanks for the explanation. This was what I was trying to explain... It would make sense in a future firmware update, however, if the scanner would sort through all "scannable" systems and talkgroups and quickly come up with its own internal "scanlist" for situations such as this.

But why? What would be the point? Why would there be a need to scan sites out of receivable range?

 

[Gilligan]

I'm not referring to sites, but referring to talkgroups from the same system but actually programmed into different favorites list. That way the scanner would build a "master scanlist of talkgroups" for each system (as the favorites lists to be scanned are chosen) and would only scan the system (regardless of how many sites) one time each cycle instead of once per each favorites list iteration.

 

[mancow]

I'm not referring to sites, but referring to talkgroups from the same system but actually programmed into different favorites list. That way the scanner would build a "master scanlist of talkgroups" for each system (as the favorites lists to be scanned are chosen) and would only scan the system (regardless of how many sites) one time each cycle instead of once per each favorites list iteration.

Hmmm I think I've been up too long. You just blew my mind. I'm so confused.

Ok, so if activity roamed to a different tower how would it pick up that activity if it didn't jump to that control channel and wait for the talkgroup information? How would it predict that action? A "real radio" is an active participant so it can force the activity regardless of the tower it's on.

 

[Gilligan]

All I'm saying is that if you had 3 favorites lists, each scanning the same system (forget towers for now), it would be nice if the firmware would build a list of scannable talkgroups for that system from the selected favorites list, and only scan the system once instead of 3 times.

 

[mancow]

Ah I got ya. Yea that could be useful.

 

[shonc182]

I understand how the Uniden system chooses the scan order based on favorites list and system, but it seems like it would make a lot more sense if they would just pause the scanner for a moment before actually scanning and sort the lists into a logical scan order that would only scan each trunked system once and during that cycle search for all scannable talkgroups in all scannable lists for each particular system. It would just make more sense...

I agree with this statement, but if - and until that happens.....

If you program the same trunked system into the scanner multiple times, then the scanner is going to rescan the control channel data multiple times. This is how trunked scanning works. My suggestion would be to make use of the "Department" level of systems and program each trunked system in only one time.

This actually feels like a better approach that I had not considered. I have been married to using the departments that Sentinel imports in the way that it imports them.

For example (just police in this example):
In the database under WCCCA (Washington Co.), it brings in BPD, TPD, HPD, FGPD, So. Cities, WCSO and several other departments - each with multiple channels

Using the suggested approach, I will build one custom Washington Co. Police Department, throw all of the individual channels into this big bucket, and assign actual departments to the same DQK to look like this:

F0-Police/Fire List
---S0 WCCCA
------D1 Wash. Co. Police
---------Beaverton PD Ch-1
---------Beaverton PD Ch-2
---------Beaverton PD Tac-1
---------Hillsboro PD Ch-1
....
------D2 Wash. Co. Fire
---------Wash Co Fire Disp
---------Wash Co Fire Ops 33
....
---S1 PPS
------D1 Multnomah Co. Police
---------Portland Central Disp
---------Portland Central Tac-1
....
------D2 Multnomah Co. Fire
....

This feels like it works, but may sacrifice some controllability. I am struggling to think through how I will handle areas that require both systems to fully monitor - Clackamas Co. fire comes to mind. My employer is insistent that I complete a minimal amount of work each day, so I will work on this later and report back.

 

[bear780ks]

I wished I could figure out why when I look on my 996xt using KSICKS I see the same alpha tags weather I'm on KHP system or like our County which is Reno I see the same thing but I think someone said that is how the system or scanner has to set it up but I still scratch my head when I think about it..

When I had my BC780 what I put were stayed there unless I put it there on this scanner if you put a tag for say the KHP you may also find it in the Butler co system as well :roll: confusing. in some ways. I Wonder if the 536 does the same thing Madcow you use KSICS don't ya or I was thinking you did do see that in this radio.. Whoop's forgot you have the 436 sorry..