No More Of The PRIMARY & SECONDARY Control Frequencies?

[PanJurekMrJerry]

Whathappened to the RED & BLUE.
I just see BLUE now.
I only see Control Frequencies and no more Priamry or Secondary ones.

 

[jon_k]

Whathappened to the RED & BLUE.
I just see BLUE now.
I only see Control Frequencies and no more Priamry or Secondary ones.

I think this was done to stop confusion and because the "secondaries" are rarely, if ever useful.

 

[Jay911]

I remember a discussion about this - perhaps it was only in the DB admin forum. Jon_k is right - the decision, as I recall it, was based on the fact that there's virtually no benefit to knowing whether a frequency is a "primary" or "secondary" CC. The fact of the matter is, 99 times out of 100, it's only really beneficial to know if a frequency carries, or can carry, a CC or not.

 

[fmon]

as I recall it, was based on the fact that there's virtually no benefit to knowing whether a frequency is a "primary" or "secondary" CC.

Other then opting out of alt controls with the PSR scanners when using Web Import on Statewide Mot or P25 systems. E.g., ya get more for your TSYS without unneeded secondary controls.

 

[mikey60]

I remember a discussion about this - perhaps it was only in the DB admin forum. Jon_k is right - the decision, as I recall it, was based on the fact that there's virtually no benefit to knowing whether a frequency is a "primary" or "secondary" CC. The fact of the matter is, 99 times out of 100, it's only really beneficial to know if a frequency carries, or can carry, a CC or not.

I strongly disagree with this decision. It's of great benefit on large systems like the MPSCS to know which control channel is most likely to be in use on a given site. When I travel across the state, I enter the primary control channels first, since those are the ones most likely to be used on the sites I'll travel past, and then fill in with alternates until the system is full of control channels.

I sincerely request that the DB admins reconsider this decision and return the Primary/Secondary control channel flags.

Mike

 

[Jay911]

I don't think it's the DB admins' choice; it would be Lindsay Blanton's ultimate decision.

I think someone is misunderstanding the concept of alternate control channels, and I'm not sure who it is. As used in my area and in my experience, and evidently likely in Lindsay's view as well, alternate CCs are ones that cycle along with the "main" CC on a regular basis. You're going to need to have these CCs in your programming all the time, for when the control channel DOES change to those frequencies.

If a frequency is not used as a control channel at all, it should not be shown in the DB as a CC frequency.

In my experience, the average site has 3 control channel frequencies that it rotates through (on a system which has a rotating CC). Are you really that short of space on a modern scanner that you can't afford 3 frequencies per site? What do you do when the 'alternate' CCs that you haven't bothered to program in, since they're 'alternates', come active because the system controller detects interference on the 'primary' CC?

 

[fmon]

J,
I have 5 smartnet systems in my area which do rotate Controls every day and each have always been in DB as red. I have 4 Smartzones which never change the Control except for very short periods for maint and the alts have always been indicated as Blue. I have one P25 800 and one statewide P25 VHF systems which never change the controls, they have always indicated alts in Blue.

The Alt Controls show up when running decoding software meaning they may be used at times, thus we actually need Red and Blue markers to give us a choice.

My VA STARS statewide P25 is currently set in PSR Scanners with only primary controls imported under previous setup (pri/alt). With Mike's, Don's or Gommert's software, I was able to opt out of alts so one TSYS could be used. Setting it up today requires 2 TSYS for import. As this system grows, it will be paramount for us to have the option of choice or fill the scanner with duplicate talkgroups to support an unnecessary amount of non essential alt controls especially when all three vender's provide options to exclude.

 

[Jay911]

I have to admit total ignorance of what a TSYS is, as I have not used a RS/GRE product since the PRO-60 (child of the PRO-43). I gather it's analogous to a system, in Uniden-speak?

Why can't you just put all three control channels in the one system/TSYS, and let the scanner use whichever one is active? This is how my scanner's programmed; each site/system's control channels or alternate control channels are all in one system.

EDIT: If the software packages mentioned are creating multiple systems based on how many control channels they find, it appears those software packages need updates/fixes to catch up to the revised design Lindsay has placed on the RRDB.

 

[mikey60]

I don't think it's the DB admins' choice; it would be Lindsay Blanton's ultimate decision.

I think someone is misunderstanding the concept of alternate control channels, and I'm not sure who it is. As used in my area and in my experience, and evidently likely in Lindsay's view as well, alternate CCs are ones that cycle along with the "main" CC on a regular basis. You're going to need to have these CCs in your programming all the time, for when the control channel DOES change to those frequencies.

If a frequency is not used as a control channel at all, it should not be shown in the DB as a CC frequency.

Agreed that the final decision will likely be up to Lindsay..

My definition of an alternate control channel in the case of a system like the MPSCS in Michigan, is a frequency that the control channel data indicates that the site *MAY* use if necessary. On the MPSCS, it is very rare that an alternate control channel is used, however the possibility does exist, and they are advertised on the control channel data as possible control channels.

From what I have seen of most networked systems, both P25 like the MPSCS, and Motorola 3600 systems, control channels don't follow the rotation schedules (some probably do) like single site systems do. Knowing the primary control channels helps prioritize which frequencies are entered first.

In my experience, the average site has 3 control channel frequencies that it rotates through (on a system which has a rotating CC). Are you really that short of space on a modern scanner that you can't afford 3 frequencies per site? What do you do when the 'alternate' CCs that you haven't bothered to program in, since they're 'alternates', come active because the system controller detects interference on the 'primary' CC?

The MPSCS has over 200 sites statewide. Using only the Primary control channels, and removing the duplicates, I counted 51 unique control channel frequencies. Those do not fit into a single bank on the Pro-96/2096, and will not fit into a single TSYS object on the PSR-500/600. I'll grant you that in most cases you would want to limit the sites in the radio anyway, but if you take all of the sites within a single zone of the MPSCS, trying to enter all of the control channels can easily fill a Pro-96/2096 bank or PSR-500/600 TSYS object without entering all of them.

Knowing which frequencies are the primary (and thus the most likely to be active) allows the user to prioritize which frequencies are entered first so that you have the best chance of hearing what you want. You can then fill in with alternate control channels (using the definition I gave above) to help take the occasional primary failures into account.

Mike

 

[Jay911]

The MPSCS has over 200 sites statewide. Using only the Primary control channels, and removing the duplicates, I counted 51 unique control channel frequencies. Those do not fit into a single bank on the Pro-96/2096, and will not fit into a single TSYS object on the PSR-500/600. I'll grant you that in most cases you would want to limit the sites in the radio anyway, but if you take all of the sites within a single zone of the MPSCS, trying to enter all of the control channels can easily fill a Pro-96/2096 bank or PSR-500/600 TSYS object without entering all of them.

I wouldn't want to put that many sites in a single system (or TSYS, if I understand it correctly) anyway. I have enough trouble with my six-site Smartzone system (total of 17 CCs) on the 396. In the 996, I needn't worry as each site gets its own slot, so I just have six slots - five with 3 CCs each and one with 2.

Trust me, I know multi-site scanner programming is a pain with what the manufacturers are giving us to play with today. I don't think eliminating secondary/alternate/backup/whatever-you-want-to-call-them CCs is a viable solution to space issues, though. Furthermore, as much as I too would like to have my scanner programmed for every eventuality I could encounter, I doubt that you (generically, not you specifically) have a need to have all 200 sites of a given wide-area trunk system programmed.

Anyway guys, I'm not for or against you in any way. I just remembered the conversation going on between DB admins and Lindsay. If it really breaks the GRE radios that badly, perhaps he'll consider putting it back the way it was. But for me, I don't care whether frequency xyz is an active or standby or alternate or backup control channel - if it is likely to carry CC data, it goes in the system definition in my scanner.

 

[mikey60]

I have to admit total ignorance of what a TSYS is, as I have not used a RS/GRE product since the PRO-60 (child of the PRO-43). I gather it's analogous to a system, in Uniden-speak?

Why can't you just put all three control channels in the one system/TSYS, and let the scanner use whichever one is active? This is how my scanner's programmed; each site/system's control channels or alternate control channels are all in one system.

EDIT: If the software packages mentioned are creating multiple systems based on how many control channels they find, it appears those software packages need updates/fixes to catch up to the revised design Lindsay has placed on the RRDB.

That's another issue I have with this change. There was no advanced notice to any of the software developers that this change was coming. Making a change without any advanced notice that could effectively "break" numerous software packages is not the best way to handle an issue like this. In my testing with PSREdit500, it appears that the RR web service currently still has the Primary/Alternate flag in it, so nothing has changed yet as far as the software packages are concerned. Hopefully it never does in this regard.

The PSR-500/600 uses a TSYS object, with a listing of the control channels it can use to monitor a system. There is a hard limit of 32 frequencies per tsys. Talkgroup objects may be assigned to exactly one TSYS object. If the PSR-500 had an option to create systems with multiple sites, you could do what you are suggesting.

As I mentioned in a previous message, using primaries only on the MPSCS, there are 51 unique control channel frequencies. Adding the alternates will easily double that. At 32 frequencies per TSYS object, we're talking at least 3-4 using all control channel frequenies, versus 2 using only primaries.

Mike

 

[mikey60]

I wouldn't want to put that many sites in a single system (or TSYS, if I understand it correctly) anyway. I have enough trouble with my six-site Smartzone system (total of 17 CCs) on the 396. In the 996, I needn't worry as each site gets its own slot, so I just have six slots - five with 3 CCs each and one with 2.

I doubt anyone would want every site in a single TSYS object (I know I don't). But there is a space limitation there, so being able to prioritize based on the most likey to be active control channel is a big plus.

Mike

 

[slicerwizard]

the decision, as I recall it, was based on the fact that there's virtually no benefit to knowing whether a frequency is a "primary" or "secondary" CC.

A "fact" that isn't true. If I'm planning on doing some mobile analysis of a large SmartZone system, I'll program all of the unique control channel frequencies (into a conventional bank/system) and label them according to their usage; for example:

141.705 "141.705 23 8a 27a 38a"
...
142.590 "142.59 8 27 38 23a"

If I'm monitoring zone 8 and I can't RX the control channel on 142.59, I immediately know that something is up because the site isn't using its normal primary control channel.

Or if I'm just stepping through the channels to see what's in RX range from a given hilltop, 99.999% of the time the display tells me right away that I'm monitoring zone 8 when I stop on 142.59, because this system rarely uses its alternate control channels. It's a good thing I made my Fleetnet maps before this ill-advised choice was made.

As used in my area and in my experience, and evidently likely in Lindsay's view as well, alternate CCs are ones that cycle along with the "main" CC on a regular basis.

A poor definition IMO. A PCC is the RF channel pair on a SmartZone/OmniLink site that is currently handling control channel duties. An ACC is an RF channel pair on a SmartZone/OmniLink site that has been programmed to handle control channel duties and is currently capable of handling CC duties (e.g. isn't disabled/malfunctioning), but is currently not carrying CC traffic. Cycling or not is immaterial.


On the SmartZone system you're most familiar with, all programmed control channels get equal time in the spotlight (PCC duty), so they should appear in the database in red. Red means that all of the control channels are essentially equals and if you don't program them all, you will lose the control channel on a regular basis.


On many other SmartZone systems, one channel is almost always the PCC while (typically) one other channel is almost always the ACC. When interference (RF signal but no ISWs) is detected on the PCC input, a zone will switch PCC and ACC channels until the interference goes away:

6:24:17 Neighbour zone #3 - North; PCC = 629 (866.7375 / PCN2)
6:24:17 Features: Digital and Analog voice, Wide area trunking

6:25:18 Neighbour zone #3 - North; PCC = 649 (867.2375 / PCN1)
6:25:18 Features: Digital and Analog voice, Wide area trunking

After one minute, the system reevaluated the noise problem and since it had abated, channel 1 was reinstated as the PCC and channel 2 went back to its normal ACC state.


Looky here: http://home.ica.net/~phoenix/wap/Fleetnet/Fleetnet Zone 1.JPG

The King and Cayuga sites use the same two frequencies as control channels, but the preferred PCCs use different frequencies, as do the ACCs. If they didn't, those two sites would frequently be using the same RF channel as their PCC and any mobiles on the high ground north of King could (and would!) cause interference on Cayuga's PCC. An affiliation by a King unit would be made simultaneously on both sites - the zone controller would just love that.

By using Cayuga's preferred PCC frequency as King's normal ACC, transmissions by King units on Cayuga's PCC are kept to an absolute minimum (since King will use its ACC for voice comms only when all other channels are busy)


Those preferred PCC and ACC frequencies should be identified with red and blue tags respectively; it shows that the system uses preferred PCCs rather than just rotating them. The distinction is very handy when a user happens to pick up a faint distant control channel on a scanner that doesn't display zone numbers (like a 246T) - when he scans the database listing for that system, the red entries are the likely candidates. With everything using blue, he has no idea which ones are ACCs and therefore likely not the zone he heard. This is not progress.

You're going to need to have these CCs in your programming all the time, for when the control channel DOES change to those frequencies.

That's not the point being debated here.

In my experience, the average site has 3 control channel frequencies that it rotates through (on a system which has a rotating CC).

For SmartZone systems, that seems to be the minority these days. If you look in the database at the large (and small) SmartZone systems in Ontario, Ohio, etc.,etc. you'll see that generally, each zone uses a single preferred primary control channel plus a single alternate. Oh wait, you can't - they're all blue now. So much for doing your own survey/analysis on how SmartZone systems are configured these days. Bad move...

 

[blantonl]

That's another issue I have with this change. There was no advanced notice to any of the software developers that this change was coming. Making a change without any advanced notice that could effectively "break" numerous software packages is not the best way to handle an issue like this. In my testing with PSREdit500, it appears that the RR web service currently still has the Primary/Alternate flag in it, so nothing has changed yet as far as the software packages are concerned. Hopefully it never does in this regard.

Mikey60, you need to go back and read the message that I posted in this thread -- I'll repost the relevant part for you:

The web service (which provides data to the programming apps) will still have the data

I didn't change a thing in the Web service, so the same functionality still exists there.

 

[blantonl]

Folks, in light of some valid arguments here let me review this decision.

More to follow.

 

[Jay911]

A "fact" that isn't true. If I'm planning on doing some mobile analysis of a large SmartZone system

Respectfully, if we're using alpha tags that are adjusted to cater to any and all comers (i.e. scanner newbies and such) - see previous discussions on this topic - and thus I can't use my known good official alias text labels in the DB, then I think your argument is a little too "high-tech" for the same reasons. To "Joe Blow" scanner user, whether a frequency is a control channel now, might be a control channel later, or whatever, doesn't matter - he should just program in the control channels and be done with it.

 

[mikey60]

Mikey60, you need to go back and read the message that I posted in this thread -- I'll repost the relevant part for you:

The web service (which provides data to the programming apps) will still have the data

I didn't change a thing in the Web service, so the same functionality still exists there.

That must have been in another thread, this is the first post from you I've seen in this thread. At any rate, I appreciate that the web service will not change on that front, and that you are reconsidering this change. That's all we can ask.

Mike

 

[fmon]

My apologizes to Jay and Lindsay

ASS-U-ME, I *****ed but didn't try import. Alternate flags are still in use for import in all three softwares.

Keep up the great work.

 

[PanJurekMrJerry]

Thanks for the info!!!! ;-)

 

[slicerwizard]

Never mind.