Cary/Wake P25 Split?

[AA4BK]

I've been thinking about Cary/Wake P25 in the database, and wondering if they should be split. Has that been considered already? I don't remember seeing anything about splitting them up, and in a few searches I haven't found anything about it, but it seems to me like if they're administratively separate (as obviously they are), and they don't even share a NAC, nor any common management, it seems like they should be two separate systems in the database.

I'm not asking for myself really. I've got them already split in my scanners. But I'm just saying if they're not the same system, it doesn't seem correct to have them listed under the same department/site in the database. I just wondered what others thought.

 

[RaleighGuy]

I've been thinking about Cary/Wake P25 in the database, ... it seems to me like if they're administratively separate (as obviously they are), and they don't even share a NAC, nor any common management, it seems like they should be two separate systems in the database.

While the sites do not share the same NAC, as with most P25 systems, the system they are on does. Both agencies share one system, just on two different sites cared for by two different governmental agencies. While I understand what you are suggesting, and why, it would be difficult if not impossible, to enter two systems in the database with the same system info. Additionally, if anyone was to search the BEE00.596 system they'd find two systems in the same location which could create more confusion. Just my thoughts.

 

[drayd48]

From a scanner standpoint it is two systems. From a radio standpoint, it’s still one system. They both share a common core and are only one system in mine and other radios. The TG that the radio is on tells it which tower to affiliate to

 

[AA4BK]

That's a tricky problem, but I understand now why they're listed as the same system. That's unfortunate but at least it makes sense to me now, and I agree that the way it is right now might be as close to correct as possible at the moment.

 

[Chris0516]

I split in two.

 

[GTR8000]

Site NAC has nothing to do with it. The vast majority of multi-site ASTRO 25 systems have a unique NAC per site, so there is nothing unusual about the Cary/Wake system in that regard. In fact, it follows the same pattern as most ASTRO 25 systems...Site 1 uses a NAC of 591 and Site 2 a NAC of 592. In other words, the first two characters from the SysID followed by the Site ID number.

In any case, it's long standing RRDB policy to have only one listing per system core, regardless of how many sites there are in the system or how each site might be segregated logically per county/agency.

The listing is correct as-is and won't be split, per that policy.

 

[jthorpe]

From a scanner standpoint it is two systems. From a radio standpoint, it’s still one system. They both share a common core and are only one system in mine and other radios. The TG that the radio is on tells it which tower to affiliate to

Ehhh not quite. They are two separate systems with different control channels. When I program all of our radios here at SHP, I put in two separate 596 systems. One for Cary and one for Wake. They are distinctly different. If you just bunch up ALL of the CC's for both systems, that would technically work but it's inefficient and very slow for the user, creating safety issues.

The talkgroup does not tell the radio what tower to go to. That's under "system" and appropriate CC's should be listed separately. When one of my guys is on RPD and then switches to APEX for instance, those are two different personalities pointing to 596 wake or 596 cary. The transition is quick if programmed properly, and slow or not usable at all if not.

Whoever programmed your radios didn't do it correctly, and it should be fixed before someone gets hurt.

Same goes for 4E0

 

[drayd48]

Ehhh not quite. They are two separate systems with different control channels. When I program all of our radios here at SHP, I put in two separate 596 systems. One for Cary and one for Wake. They are distinctly different. If you just bunch up ALL of the CC's for both systems, that would technically work but it's inefficient and very slow for the user, creating safety issues.

The talkgroup does not tell the radio what tower to go to. That's under "system" and appropriate CC's should be listed separately. When one of my guys is on RPD and then switches to APEX for instance, those are two different personalities pointing to 596 wake or 596 cary. The transition is quick if programmed properly, and slow or not usable at all if not.

Whoever programmed your radios didn't do it correctly, and it should be fixed before someone gets hurt.

Same goes for 4E0

Actually not. That would be like saying you program a different system for every VIPER tower

 

[RaleighGuy]

Actually not. That would be like saying you program a different system for every VIPER tower

Not correct at all, they are two totally different things. VIPER talkgroups, users, are available on most towers as they travel through the state and remain on the same system maintained by one group of radio techs, with one set of policies.

Wake & Cary are totally separate and maintained by different agencies with different policies, one may not use the other without changing systems, just like when VIPER wants to access Wake County talkgroups like Wake Event 10. Additionally, you will not hear Cary talkgroups on site two, nor Wake talkgroups on site one, unlike Viper which is able to change sites as they travel.

 

[GTR8000]

Wake & Cary are totally separate and maintained by different agencies with different policies, one may not use the other without changing systems...

Without changing sites.

Yes, it's somewhat nitpicky, but it's an important distinction. 596 is a single ASTRO 25 system running on one core/one zone controller that has two sites. Yes, those two sites are managed by different counties and talkgroup roaming may be restricted and/or outright prohibited so as to appear that it's two separate systems, but it's really not.

Go ahead and call me pedantic, but I believe it matters to some degree that we use the proper terminology and understand at least the basics of these systems if we're going to engage in technical discussions about them.

Carry on.

 

[RaleighGuy]

Without changing sites.

I stand corrected and that is what I meant to say, thank you for clarifying for me.

 

[jthorpe]

Actually not. That would be like saying you program a different system for every VIPER tower

Not true. I stand by what I said. It's the same core but two totally different sites that also act as different systems to the user. The towers are decided by the system programming. The talkgroups, scan lists and emergency data are defined in the personalities. Of course actual "channels" are shown in the zone programming.

The radio makes the decision for a tower based on the following order.

1. adjacent site list
2. Control channel list
3. Full spectrum scan if turned on.

If your radios are programmed the way you say, they are absolutely incorrect and can cause delays in attaching to the proper tower site and talk group.

 

[GTR8000]

The radio makes the decision for a tower based on the following order.

1. adjacent site list
2. Control channel list
3. Full spectrum scan if turned on.

If your radios are programmed the way you say, they are absolutely incorrect and can cause delays in attaching to the proper tower site and talk group.

I'm not saying that your thought process is wrong, but let's agree that there is more than one way to skin a cat.

There is no reason why an APX codeplug couldn't be setup so that each trunking personality (i.e. grouping of talkgroups) can't make use of the Preferred Sites parameters. You could setup 596 as a single system in the codeplug, with all 8 control channels programmed into a single list, then restrict talkgroup access per site by way of Preferred Sites.

In fact, I would argue that this is more efficient as you don't need to unnecessarily duplicate 596 in the codeplug, when presumably you'd have the same UID in Provisioning Manager regardless of which site/county you're operating on.

Oh and to clarify, the first thing the subscriber checks when it's powered up is the list of programmed control channels, not the adjacent site list. Assuming that they even have the two sites broadcasting each other. If these are truly treated as separate systems, why would you even want an adjacent site list being broadcast? Aren't you trying to prevent automatic site roaming?

 

[jthorpe]

I'm not saying that your thought process is wrong, but let's agree that there is more than one way to skin a cat.

There is no reason why an APX codeplug couldn't be setup so that each trunking personality (i.e. grouping of talkgroups) can't make use of the Preferred Sites parameters. You could setup 596 as a single system in the codeplug, with all 8 control channels programmed into a single list, then restrict talkgroup access per site by way of Preferred Sites.

In fact, I would argue that this is more efficient as you don't need to unnecessarily duplicate 596 in the codeplug, when presumably you'd have the same UID in Provisioning Manager regardless of which site/county you're operating on.

You can do this, but there is no point IMO based on the fact that you cannot access "cary" TG's from Wake and you cannot access "Wake" TG's from the Cary side. From a programming standpoint, it takes me about 2 seconds to duplicate 596 then change the control channels to match the site I want.

Oh and to clarify, the first thing the subscriber checks when it's powered up is the list of programmed control channels, not the adjacent site list. Assuming that they even have the two sites broadcasting each other. If these are truly treated as separate systems, why would you even want an adjacent site list being broadcast? Aren't you trying to prevent automatic site roaming?

This depends. I'll clarify. If the adjacent site list is empty, then yes, the radio goes to control channel list first. If the adjacent site list is populated, the radio uses it first. As long as you don't switch from one system to another, the adjacent site list stays populated even if you power down the radio.

Now, if you switch from say.. Event 10 to Apex PD, you've just switched systems so the adjacent site list is erased, and the radio uses the control channel list first. If one switches to VIPER after that, then it'll clear the adjacent site list again and go to control channels. Then full spectrum.

So yeah, there is more than one way to skin a cat, but the 500+ radios I have programmed for VIPER, Wake and Cary work exactly as we want them to, so I'm going to continue to do it that way. I get what you're saying but at the same time, I don't really like using preferred sites anyway. That's just me though. 🤷🏼‍♂️