Control Channel Designator

[Enforcer52]

Since trunked systems usually have more than one control channel, I was wondering if it would be possible for folks to report which control channel is the Master/Main/Default channel. For new folks or folks planning to travel to an area it would be nice to know which control channel is actually in normal everyday use, and not have to program in all the other control channels or could set them to avoid/lockout so as not to have to rotate scan thru them.

Since RR uses a little "c" to designate a control channel, perhaps a capital "C" could designate the Master/Main/Default control channel.

400ms scan time per channel does slow down the scanning process when there are 4-6 control channels per tower. I scan 6 counties so actually scanning from 12-30 total control channels takes forever. Once I do identify which is the Master/Main/Default control channel, I avoid the others or delete them.

What do Database Admins and other members think of the idea?

 

[Unitrunker2]

I've debated this with RR DB admins many years ago. The pattern used back then was a "c" for the active control channel and a "d" or "a" (can't remember) for alternate control channels. They seem to have simplified to "c" for everything. The problem back then was two-fold. Some folks ignored the alternates only to complain the DB was wrong. Some folks made a DB submission every time the control channel moved. This was extra, unwanted churn for the admins.

My opinion is the database should not track the active control channel. Use a radio or SDR software to do that. As long as you have the list of know good control channels, you're good.

If you are scanning across multiple sites / systems, you'll still miss calls - and you're still vulnerable to the one site that decides to roll over to one of the locked-out alternates. The fix for this is to put more radios or SDRs to work continuously monitoring the sites/systems you care about most.

 

[mwjones]

I concur with @Unitrunker2's remarks regarding the unneeded churn. And then of course there's the NexEdge systems that tend to change their control channel daily - great for identifying the frequencies in use but would be a nightmare for the RRDB team to maintain which is primary vs. alternate.

In the world of scanning, just knowing a frequency is capable of being a control channel is all you really need to know, after that let the hardware/software figure out which is active at that moment.

 

[Enforcer52]

I understand what everyone is saying, but in the Houston Area if you program all the control channels in your total scan time to run thru all the channels is extremely long. I know 400ms doesn't seem long but it adds up.

I know it sounds like a lot of work, but I was only referring to Public Safety frequencies and not all the private systems.

Oh well it sounded like a good idea, I'll just keep doing what I have been doing then and lock out freqs until needed.

Thanks for y'alls input.

 

[dave3825]

400ms scan time per channel does slow down the scanning process when there are 4-6 control channels per tower.

Once I do identify which is the Master/Main/Default control channel, I avoid the others or delete them.

What do Database Admins and other members think of the idea?

I think that since some systems can use alternate control channels as voice channels, it's always best to have all labeled freqs with a c programed into the scanner.

 

[wa8pyr]

We used to keep track of that information, but went to the current format a couple of years ago as it simply was not practical to track it. This was because some systems change control channels frequently (often daily), others not so much, and the workload on our administrators dealing with the steady flood of submissions about control channel changes was just too much.

In reality, any designated control channel could be the active one at any time; it’s best to program all the control channels and move on, don’t try to cut corners and program only the active one.

In other words, we’ll stick with the current format.

 

[Echo4Thirty]

I understand what everyone is saying, but in the Houston Area if you program all the control channels in your total scan time to run thru all the channels is extremely long. I know 400ms doesn't seem long but it adds up.

I know it sounds like a lot of work, but I was only referring to Public Safety frequencies and not all the private systems.

Oh well it sounded like a good idea, I'll just keep doing what I have been doing then and lock out freqs until needed.

Thanks for y'alls input.

The best solution to this on large systems is to not build one giant system but to limit the sites the TGs actually come out of. For example, in Harris county you really only want to scan the simulcat cell(s) that serve you. In Harris county, only focus on the simulcast cells and not the indivdual roamers. If you are in Ft Bend, or Galveston only scan their respective simulcasts. This will reduce the time it takes as its not wasting time going to sites that the TGs will never come out of anyway.

Generally for TxWarn the TGs are typically only allowed in the county sites and one adjacent county (except for the occasional transient traffic on the roamer sites). For Houston, with a few exceptions (Spring ISD PD on the Spring site for example), stick to the 4 quandrants.

 

[KevinC]

The best solution to this on large systems is to not build one giant system but to limit the sites the TGs actually come out of. For example, in Harris county you really only want to scan the simulcat cell(s) that serve you. In Harris county, only focus on the simulcast cells and not the indivdual roamers. If you are in Ft Bend, or Galveston only scan their respective simulcasts. This will reduce the time it takes as its not wasting time going to sites that the TGs will never come out of anyway.

Generally for TxWarn the TGs are typically only allowed in the county sites and one adjacent county (except for the occasional transient traffic on the roamer sites). For Houston, with a few exceptions (Spring ISD PD on the Spring site for example), stick to the 4 quandrants.

Another thing is Unidens can mistake IV&D traffic for a CC and if it sees an IV&D frequency before a CC it can lock onto it and stay there FOREVER. So yeah, build site specific lists and if a Uniden make use of the quick keys for sites.

 

[Echo4Thirty]

Another thing is Unidens can mistake IV&D traffic for a CC and if it sees an IV&D frequency before a CC it can lock onto it and stay there FOREVER. So yeah, build site specific lists and if a Uniden make use of the quick keys for sites.

Give me a sec, Kevin and Ill figure out how we can blame it on Motorola haha

 

[KevinC]

Give me a sec, Kevin and Ill figure out how we can blame it on Motorola haha

I blame Todd.