Documenting Quick Keys

[jonwienke]

Another scenario where your method will miss traffic:

A site in county A near the border between counties A and B carries traffic for agencies in both counties.

It broadcasts a transmission for a county B agency. while you have both you A and B copies of the system active.

The scanner hears the transmission from the site in county A while scanning the county A copy of the system.

Because the traffic is for a county B agency, it is ignored while scanning the county A copy of the system. You won't pick the call up until the scanner scans the county B copy of the system, and picks it up from a county B tower. If it's not broadcast on a county B tower, you miss the entire transmission. And you won't even know it.

 

[werinshades]

I understand exactly what you're doing, and you're wrong about missing traffic, for the simple reason that in most systems, there is not a neat 1:1 mapping between sites and departments. Site coverage is planned based on RF propagation, not county boundaries. And the system programming that dictates which talkgroups are broadcast from each site follows the same principle.

For example, a small town PD near the edge of county A may mostly use a tower across the border in the county B because its location gives them better coverage. In that situation, if you have one instance of the system for County A and another for county B, you'll miss all or most traffic from Smalltown PD. Here's why:

When you're listening to the County A copy of the system, you won't hear Smalltown PD, because it's not normally broadcast from any of County A's sites.

When you're listening to the County B copy of the system, you won't hear Smalltown PD unless you:

1. Program county A's talkgroups in county B's copy of the system. But that defeats the purpose of programming separate copies of the system for county A and county B. If everything for county A is programmed in county B's system, you've forfeited any advantage of programming multiple copies of the system.
2. Turn on ID Search in the county B system. But then you will only see the talkgroup ID, and the scanner won't tell you what you're listening to, even though it could.

So to solve this, you have to either program a department that lives in county A into couty B's system (silly and counterintuitive), or you will miss traffic.

Another problem with your approach is that since RF propagation doesn't follow county boundaries, toggling sites by county guarantees you're going to spend more time scanning out-of-range sites than if you used Location Control. If you're on the south side of county A, that doesn't mean you can hear sites on the north side, and vice versa. Location Control toggles sites individually, irrespective of jurisdictional borders that mean nothing to radio waves. If set up correctly, when you're near the border of county A and county B, Location Control will activate nearby site(s) in both counties, but not the ones at the far reaches of either county, that you can't hear anyway.

Another scenario where your method will miss traffic:

A site in county A near the border between counties A and B carries traffic for agencies in both counties.

It broadcasts a transmission for a county B agency. while you have both you A and B copies of the system active.

The scanner hears the transmission from the site in county A while scanning the county A copy of the system.

Because the traffic is for a county B agency, it is ignored while scanning the county A copy of the system. You won't pick the call up until the scanner scans the county B copy of the system, and picks it up from a county B tower. If it's not broadcast on a county B tower, you miss the entire transmission. And you won't even know it.

Sorry I rained on your parade , but the systems I use have duplicate traffic on both sites. Starcom is what I use..Site 1-001 and Site 1-002. Sooo...once I leave the Cook County area (Site 1-002) and travel within the confines of DuPage County (Site 1-001) and I'm driving along, both sites receive ISP Districts that I have programmed in ID Scan. Once I can safely do so, 11.1 or 11.2 is pressed (depending on location) and all works well without a missed beat.

I understand you have a business to run, and if I was traveling across country in a vehicle, gps modification would probably be the optimal solution. However, back to the question...he was turning on and off sites manually and I "suggested" my method only if the sites carried duplicate traffic, which in the few state systems I've programmed, usually does.

You shouldn't make assumptions if you don't have a clue as to how other systems work. For you and others, the location control/gps method works good. I don't post that "you are missing traffic" because I don't know the monitoring situation of others. My method works, I've been doing this a long time and leave it at that.

 

[jonwienke]

Good programming practices will work well on any system, regardless of its size, and regardless of whether or how traffic is duplicated across multiple sites. Your method requires the system to be set up in a very specific way in order to not miss traffic, for the reasons I outlined in my previous posts.

Most systems are set up to avoid duplicate traffic across multiple sites, for good reason: spamming sites with non-local traffic will quickly overload a site, particularly on large statewide/multistate systems. You'd have to have dozens of frequencies for every site, and would still have trouble with capacity overload if every site carried all traffic from the entire state.

So site traffic in most systems is carefully limited by talkgroup to keep traffic relevant to the service area of the site. Following your advice will cause problems for a majority of people programming such systems. Using Location Control is an all-around better approach, even if you aren't using GPS, because it toggles sites on an individual basis, rather than by county.

You don't need GPS to use location control at a fixed location. You can enter your coordinates from Google Maps and it will work just as well. GPS is only useful if you're scanning on the go, or changing fixed locations frequently enough to make manually entering coordinates an inconvenience.

I've never recommended my GPS mod services to people who never travel with their scanners, and have no plan to start doing so. Your suggestion that I've done otherwise is dishonest and insulting.

 

[werinshades]

Good programming practices will work well on any system, regardless of its size, and regardless of whether or how traffic is duplicated across multiple sites. Your method requires the system to be set up in a very specific way in order to not miss traffic, for the reasons I outlined in my previous posts.

Most systems are set up to avoid duplicate traffic across multiple sites, for good reason: spamming sites with non-local traffic will quickly overload a site, particularly on large statewide/multistate systems. You'd have to have dozens of frequencies for every site, and would still have trouble with capacity overload if every site carried all traffic from the entire state.

So site traffic in most systems is carefully limited by talkgroup to keep traffic relevant to the service area of the site. Following your advice will cause problems for a majority of people programming such systems. Using Location Control is an all-around better approach, even if you aren't using GPS, because it toggles sites on an individual basis, rather than by county.

You don't need GPS to use location control at a fixed location. You can enter your coordinates from Google Maps and it will work just as well. GPS is only useful if you're scanning on the go, or changing fixed locations frequently enough to make manually entering coordinates an inconvenience.

I've never recommended my GPS mod services to people who never travel with their scanners, and have no plan to start doing so. Your suggestion that I've done otherwise is dishonest and insulting.

Once again John, you don't understand what I have been doing for many years. Telling people I'm wrong or will cause other scanning issues is where I take issue with. The poster will make up his mind as to what he wants to do.

I'll break it down for you or anyone else who is trying to understand this a little better. Favorite List (Starcom Statewide)...System/County...site control/alternate frequencies active within the county site....Department(s) within the county i'm traveling I would like to monitor.

Driving to DuPage County...I live in Cook County. Before I leave the house, I press 11.1 (Cook), 11.2 (DuPage). I'm on the expressway, now entering DuPage County. When I get a free moment, I press 11.1 Enter to turn off Cook County site and now receiving only the DuPage County site...which also receives District Chicago amongst others....ID Scan.. transmissions received, not missed.

I know this isn't your suggested gps/location control method, but it works well, everything is being received and have been using it for a long time.

 

[jonwienke]

I understand exactly what you are doing, I'm not stupid. I don't have an issue with programming one copy of a system in a favorite list, and toggling sites within that one copy of the system on and off manually, (e.g. entering 11.1.1, 11.1.2, etc to toggle site QKs within the single programmed copy of the system). It's not what I do personally, but there's nothing wrong with it conceptually, other than the potential safety issue associated with taking your eyes off the road to operate the scanner keypad.

Where things go off the rails is when you program and scan multiple copies of a single system in a favorite list, with each copy of the system targeting a different county or agency. Perhaps your system is configured in such a way that you can do that on that system and not miss traffic, but on most systems you absolutely will miss traffic if you program that way, and for that reason, that method of programming should be avoided, and certainly not recommended for general use.

 

[werinshades]

I understand exactly what you are doing, I'm not stupid. I don't have an issue with programming one copy of a system in a favorite list, and toggling sites within that one copy of the system on and off manually, (e.g. entering 11.1.1, 11.1.2, etc to toggle site QKs within the single programmed copy of the system). It's not what I do personally, but there's nothing wrong with it conceptually, other than the potential safety issue associated with taking your eyes off the road to operate the scanner keypad.

Where things go off the rails is when you program and scan multiple copies of a single system in a favorite list, with each copy of the system targeting a different county or agency. Perhaps your system is configured in such a way that you can do that on that system and not miss traffic, but on most systems you absolutely will miss traffic if you program that way, and for that reason, that method of programming should be avoided, and certainly not recommended for general use.

Sites aren't numbered..each system has an assigned site based upon county I'm in. If a county has more than one site, both sites frequencies are added independent of each other with a hold time set as 0. Usually, both sites in a county carry the same traffic.

 

[jonwienke]

Quick keys are numbered, regardless of whether sites are named or numbered. In my example the favorite list QK is 11, the system QK is 1, and the site QKs are 1 and 2.

 

[werinshades]

Quick keys are numbered, regardless of whether sites are named or numbered. In my example the favorite list QK is 11, the system QK is 1, and the site QKs are 1 and 2.

I got that...but the site numbering is not necessary. In your example in my set up, 11.1.1...is Favorite List 11, System 1, Department 1. This way if you just want to listen to police (Dept. 1) or Fire (Dept. 2), you can turn them off or on. Site will enble or disable depending on the System in use. I can isolate it to the area I'm traveling without using the other methods. It works, just another way of achieving the goal.

 

[jonwienke]

It's the Uniden programming equivalent of using a flat screwdriver as a chisel. The fact that it works well enough sometimes doesn't mean it's actually a good idea.

It delivers acceptable results for you, given just the right set of conditions found on the one system you're monitoring. But isn't something you should be recommending as a good practice for general use, because it will not work well on many systems out there, for the reasons I outlined earlier.

 

[werinshades]

It's the Uniden programming equivalent of using a flat screwdriver as a chisel. The fact that it works well enough sometimes doesn't mean it's actually a good idea.

It delivers acceptable results for you, given just the right set of conditions found on the one system you're monitoring. But isn't something you should be recommending as a good practice for general use, because it will not work well on many systems out there, for the reasons I outlined earlier.

If asked, I will continue to recommend my method and you can recommend yours, whether you want to admit it works quite well. We can leave it at that...

 

[jonwienke]

If asked, I will continue to recommend my method and you can recommend yours, whether you want to admit it works quite well.

For you. On one system. And probably not as well as you think. Other people have done the same thing as you on other systems, and had precisely the missed traffic issues I described previously.

None of the scenarios I described are theoretical; every single one is a summary of a real-life issue that someone has at some point posted about on RR requesting help. You're doing a disservice to others with your advice.

 

[werinshades]

For you. On one system. And probably not as well as you think. Other people have done the same thing as you on other systems, and had precisely the missed traffic issues I described previously.

None of the scenarios I described are theoretical; every single one is a summary of a real-life issue that someone has at some point posted about on RR requesting help. You're doing a disservice to others with your advice.

Johnny...let it go man. We've danced long enough.

 

[jonwienke]