Geotag for simulcast EDACS sites

[ST-Bob]

The Worcester Public Safety EDACS system Worcester Public Safety Trunking System, Worcester, Massachusetts - Scanner Frequencies is set up to cover the entire circle just enclosing the city borders. However, in reality there are 2 separate sites, one located in the city and a second (lower powered) site on Asnebumskit Hill in Paxton to the north-west of the city. There's also several talkgroups on the system affiliated with the water department which must cover the outlying reservoirs located several miles beyond the city's borders.

What is the correct way to handle this type of system?

Should it be set up with a single site that has a larger range and move the center point to cover the city borders and the outlying reservoirs?

Should a second site be set up (even though they share 10 identical frequencies) and set its location and range so it adds to the coverage area of the main site to just enclose the reservoirs and roads leading to/from them and the city?

Should the individual talkgroups needing the extra range be broken out from their department (DPW) so they may have different geotag location and range?

Can a talkgroup within a system that's got one location and 5.5 mile range have a different location and greater range or will it have to fit within the confines of the main system's confirmed LCN's geotag info?

How will this affect location-based scanners like the HomePatrol and others? Will they cut off reception at the system's border or the talkgroup's border (even if larger than the system's border)?

A complex question, I know. But it's got to be asked and I hope we can get an answer that works for everybody.

 

[loumaag]

Bob, I know we have explained this before but for simplicity let me restate the way geo-tags work for TRSs.

1. The system has a geo-tag set which is the default for the entire system (all sites and TG categories). If a site or TG Cat does not have a separate geo-tag set, then the default is used. Point of information in regard to the HP-1, each system must have an actual geo-tag set and cannot be an "inherited" one from say the county page, else it is ignored in the weekly update by Uniden (this is situation that Uniden may have addressed, but it was the case in the beginning).
2. Each site, in multi-site systems, should have a geo-tag set for that site. Simulcast sites should include the entire intended coverage area by all towers included in that simulcast site. Single tower sites should be geo-tagged with the intended coverage area of that site alone. Single site systems do not need to have the site geo-tagged as it inherits the default from the system, which is the same thing.
3. Each TG Category can also be geo-tagged thereby over-riding the default (system level). The object of this is to further define what normal service area is covered by that category of TGs. An example best serves to explain; take a TG category that covers court house security (bailiffs, entrance security, etc.), the intended coverage area of that would be centered on the court house and only a radius of the building and surrounding parking or support buildings. Probably something in the order of 1/10 of a mile. It makes no difference that a bailiff may be somewhere else and still use his "home" TG, the intended service area is the key.

It makes no difference on the type of system (EDACS, P25, Motorola, LTR, etc.), it is the same set of rules for all.

 

[ST-Bob]

Lou, you may have explained it before and I might have missed it or could not find it. Sorry if I'm dredging up old topics.

The unique thing about Worcester's EDACS system is the same-frequency multi-site simulcast. I've run into simulcast sites for the Mass State Police Motorola Smartzone system but I believe each site has its own unique set of frequencies. I could be wrong of course. There's a lot of data and I didn't look at it very closely.

So the way I understand it the system itself is the one that gets the main geotag info which includes, by default, the whole city and both the Site and Department can have their own geotag information which differs from the main system.

I'm a little fuzzy on how the multi-site simulcast should be handled by RR policy. I thought the intent was to eliminate duplicate frequencies and thus Worcester's EDACS system shows up as one site even though, physically, it is two sites located several miles apart.

I want to make sure I'm reconfiguring things properly when I try to make corrections to this system. I hope it's OK to bounce additional questions off you and the other experts. Or would you prefer to do this off the forums.

My intent is to add a second confirmed LCN site which expands the coverage area with a circle that bulges outward from the regular system circle in the direction of the reservoirs to the northwest. This will then allow hearing the whole system on location-based scanners when out in the area of the reservoirs as this is within the intended area of coverage.

Is it safe to say the intended area of coverage should bulge out like that on one side? Or would it be better to just re-center and expand the water department's geotag?

Or is it necessary to expand the entire system's single geotag to include all outliying areas under one circular coverage area?

I just want to do what's right by both policy and technical capabilities of the database and the scanners which use the data.

Thanks

 

[loumaag]

Lou, you may have explained it before and I might have missed it or could not find it. Sorry if I'm dredging up old topics.

Which is why I repeated the explanation.

The unique thing about Worcester's EDACS system is the same-frequency multi-site simulcast. I've run into simulcast sites for the Mass State Police Motorola Smartzone system but I believe each site has its own unique set of frequencies. I could be wrong of course. There's a lot of data and I didn't look at it very closely.

All simulcast sites work the same no matter what the system. It is more than one tower/site with the same frequency lineup broadcasting the exact same thing at the same time (with timing being the main problem with such sites.) Anything else broadcasting the same signal (sites with different frequencies) at the (more or less) same time is not simulcast, it is multi-cast. We, at RR, don't really care and don't make any special provisions for multi-cast sites.

So the way I understand it the system itself is the one that gets the main geotag info which includes, by default, the whole city and both the Site and Department can have their own geotag information which differs from the main system.

Yes; however, take into consideration what I say about bulges below.

I'm a little fuzzy on how the multi-site simulcast should be handled by RR policy. I thought the intent was to eliminate duplicate frequencies and thus Worcester's EDACS system shows up as one site even though, physically, it is two sites located several miles apart.

There are no duplicate frequencies in simulcast sites on RR since all towers in a simulcast site are considered one site.

I want to make sure I'm reconfiguring things properly when I try to make corrections to this system. I hope it's OK to bounce additional questions off you and the other experts. Or would you prefer to do this off the forums.

My intent is to add a second confirmed LCN site which expands the coverage area with a circle that bulges outward from the regular system circle in the direction of the reservoirs to the northwest. This will then allow hearing the whole system on location-based scanners when out in the area of the reservoirs as this is within the intended area of coverage.

Based on what you have told me here, and a brief look at the system, it would appear that the system is configured according to RR policy. We would not accept a second site since there is not a second site. Both towers are considered one site.

Is it safe to say the intended area of coverage should bulge out like that on one side? Or would it be better to just re-center and expand the water department's geotag?

Well, we can't make bulges with our geo-tags.
So, the proper and accepted way to handle that is to center the geo-tag in the intended coverage are and draw a circle around it such that it just covers all intended areas. If this causes the coverage area to include areas that are not in the intended area, we can't do anything about it, since we are limited to a circle.

Or is it necessary to expand the entire system's single geotag to include all outliying areas under one circular coverage area?

Yes, and in this case since the site and system cover the same area the site does not need a geo-tag.

I just want to do what's right by both policy and technical capabilities of the database and the scanners which use the data.

Hopefully this point-by-point explanation furthers your understanding.

Thanks

Your welcome.

 

[loumaag]

Additional Info

Bob, after I posted that, I had another thought in reference to the various relationships of the different geo-tags, understand this is for all systems, not just this one.

Consider the system geo-tag as the main one. If different geo-tags are assigned to the sites (I say sites because if it is a single site, it doesn't need a geo-tag), then all sites must lie within the system geo-tag area. The same is true of TG category geo-tags. In other words, each sub-geo-tag (below the main one) must, in its entirety, lie within the bounds of the system tag.

This is quite understandable from the HP-1 point of view. Consider that if a system has a circle and within that system a site has a circle which contains any area outside the system circle, it would be ignored by the HP-1 if you were (assuming a zero range setting) within the site's range but outside of the system's range since it would not not "see" the system in the first place. A similar situation goes for the TG category areas.