APX Smartzone Multi-Site Non-affiliated scanning

[slobonmycob]

Can anyone who has experimented with adding preferred sites provide feedback on the results? Did the radio preform better when trying to monitor a specific talk-group? I've been trying to read up on the subject matter but overall everything is inconclusive.

Currently, I have one trunked system and one trunking personality with all the control channels/ talk-groups.

An idea has been mentioned elsewhere, that to better monitor specific talk-groups within a multi-site system, one should program a new system and new trunking personality for each different site with it's correlating talkgroups. Any feedback on this idea?

with love slobonmycob

 

[wgbecks]

Generally speaking, there's no need to setup preferred sites for a given trunking personality, assuming a portable radio that's setup to passively monitor (NAS) a system as opposed to one that's programmed to affiliate on the system. However, there may be circumstances whereby you are operating in geographical areas where the desired site has marginal RF coverage, and whereby the trunking logic selects an adjacent site that may not necessarily broadcast (multicast) certain or specific TGID's of interest.

In these situations, it makes perfect sense to setup preferred sites as a means to force the radio to remain tuned to a weaker or more marginal site that's known to broadcast TGID's of interest. It really depends upon how the zone controller is setup and if the TGID's of interest have radios affiliated on adjacent sites.

Unless you have specific knowledge of the system, may need to utilize a program like Unitrunker, SDRTrunk, or OP25 to collect traffic statistics on the TGID's of interest to better analyze the system and to plan your course of action.

 

[slobonmycob]

Generally speaking, there's no need to setup preferred sites for a given trunking personality, assuming a portable radio that's setup to passively monitor (NAS) a system as opposed to one that's programmed to affiliate on the system. However, there may be circumstances whereby you are operating in geographical areas where the desired site has marginal RF coverage, and whereby the trunking logic selects an adjacent site that may not necessarily broadcast (multicast) certain or specific TGID's of interest.

In these situations, it makes perfect sense to setup preferred sites as a means to force the radio to remain tuned to a weaker or more marginal site that's known to broadcast TGID's of interest. It really depends upon how the zone controller is setup and if the TGID's of interest have radios affiliated on adjacent sites.

Unless you have specific knowledge of the system, may need to utilize a program like Unitrunker, SDRTrunk, or OP25 to collect traffic statistics on the TGID's of interest to better analyze the system and to plan your course of action.

What can you say about setting up a different trunking system and trunking personality for every pool of talk-groups at different sites?
Take for example my statewide multi-site system:
Fort smith PD uses the Fort smith simulcast system (site 001 (1)) and Hartford (site 028 (1C))
With the following talk-groups: FSPD 1 and FSPD 2
Now Sebastian County Sheriff's office also uses the same sites with talkgroups: SCSO 1 and SCSO 2.
Since both pool of talk-groups utilize the same sites to better track them it has been suggested to create a separate system and personality to track them specifically.

 

[Mr_Boh]

It's a definite "your mileage may vary" sort of thing. There's a lot of factors with regard to one system with multiple sites vs breaking it out, and it comes down to the system itself.

An example I will give, one system I programmed only for monitoring with two sites, I didn't even bother programing the smaller second site, just the larger simulcast cell. The reason being was for the most part all the TGs were over the larger simulcast and only if coverage was needed in a smaller area would the other site lite up with the talkgroups. The smaller site was deployed for coverage of the portable transmitting, not necessarily for the reception (since the simulcast cell can be received pretty far away). So my concern was the subscriber locking onto the smaller site with less TGs even though I could hear them all on the larger site in pretty much 95% of the same footprint.

You can see this in larger systems too - if I am only interested in listening to one specific fire dispatch for a county with two sites, the second site might be for some coverage between that county and another - when they sites are built they are built for both 3W portable transmit and receive, but in this case we only care about receive, so I wouldn't even worry about the site designed for gap filling just so the odds are always better of landing on the site that has the TGs I want to listen to.

Hopefully that makes sense? I even try to manage this with scanners/pagers that are programmed as well since it makes a huge difference in speed and ability to follow conversations.

 

[wgbecks]

If Fort Smith FSPD 1 & FSPD 2 multicast on both sites and these are your target TGID's then there should be no reason to split up the system or to have to utilize preferred sites. The fact that there are other users on these sites makes no difference as your APX is listening to the control channel and only follows channel grants for the TGID's in your attached scan list. All should be well.

The question is, "do your Fort Smith PD groups multicast regardless of SU affiliation"? If you happen to have a second radio available for a test then create your different trunking systems in CPS based upon just those targeted control channels and compare the two radio to see if any traffic is missing on the APX that has the control channels of both sites in it's single system list.

One has to sometimes get creative with layout and programming in the absence of affiliation. However, there is nothing you can do once
outside of your normal site(s) (areas) to assure that you continue to receive home TGID's that don't normally multicast on these adjacent sites
short of an SU from that group being affiliated there.

This is the reason that I suggested setting up a traffic study with a PC or a Raspberry Pi armed with the proper software to capture RID's and TGID's to determine if targeted TGID's multicast on a given site regardless of targeted group SU affiliations. You might find out that you're beating a dead horse and that in some cases certain things are going to be beyond your control from a passive monitoring perspective.

 

[slobonmycob]

You might find out that you're beating a dead horse and that in some cases certain things are going to be beyond your control from a passive monitoring perspective.

I was beginning to suspect that might be the case. Even with affiliated radios at work it's not recommended we scan other channels because of how busy the system can get.

This is the reason that I suggested setting up a traffic study with a PC or a Raspberry Pi armed with the proper software to capture RID's and TGID's to determine if targeted TGID's multicast on a given site regardless of targeted group SU affiliations.

This is interesting, I could contribute some valuable information to the database here. I believe you and I have exchanged emails before I will send you a message shortly.

Hopefully that makes sense? I even try to manage this with scanners/pagers that are programmed as well since it makes a huge difference in speed and ability to follow conversations.

That makes perfect sense and goes along with what wgbecks says. I have pro96com but haven't figured out why it's not saving the information.. so I might need to find a better alternative in the mean time.

 

[wgbecks]

Still same email address as in the past but you can PM me here if you've lost track of it.

Bill