Simulcast Maps & Talkgroup Sites

[jpolich7]

Here are suggestions for
1) presenting simulcast sites on the Site Details pages, and
2) matching talkgroups to sites.

These observations are based mainly on the Arizona Regional Wireless Cooperative (RWC) but probably apply more broadly to many other systems.

SIMULCAST MAPS

It would be helpful if maps on the opening Site Detail page, like this one

Simulcast A: Phoenix PD and City Services Site Details (Regional Wireless Cooperative (RWC))

showed all of the licensed transmitter locations. Presently it seems necessary to click on each of the Site FCC Licenses to see its location and then try to plot our own map. A consolidated map would help those of us trying to determine the best antenna type and direction to monitor simulcast systems. In the example above, this is the RWC Simulcast A: Phoenix PD and City Services with twelve (12) Site FCC Licenses, with each transmitter at a different location.

TALKGROUPS AND THEIR SITES

Listeners who are not experts on a particular system may find it hard to determine which talkgroups are carried on which system sites. Again using the RWC as an example, the north dispatch Scottsdale PD talkgroup and a couple district dispatch Phoenix PD talkgroups seem to be carried on the Thompson Peak site, a high power, high elevation transmitter that is easily heard throughout much of Phoenix and its eastern suburbs.

However, the south dispatch Scottsdale PD talkgroup is only carried on Simulcast H along with the north dispatch. And most of the Phoenix PD dispatch talkgroups are on Simulcast A. Both these simulcasts are notoriously hard to monitor.

It may be worth considering creating another RadioReference database page within large systems like the RWC-- a spreadsheet that matches rows of talkgroups with columns of the sites. This would be very helpful to listeners at every skill level, and might reduce postings from those trying to find this information and administrator time answering.

Thanks for your consideration.

 

[jonwienke]

This suggestion is mostly pointless. System operators have several options for mapping talkgroups to sites.

1. A talkgroup is broadcast from a single site.

2. A talkgroup is broadcast from a static list of sites.

3. A talkgroup has a list of affiliated users, and is dynamically broadcast from whatever site(s) have affiliated users listening.
For example, a bridge inspector talkgroup 577 has 20 affiliated users, all of whom are bridge inspectors. As the inspectors travel around, talkgroup 577 is activated and deactivated on sites as bridge inspector radios affiliate and deaffiliate with the site. Any given site will only broadcast talkgroup 577 if there are bridge inspectors within service range of the site, and one or more of their radios affiliate with the site. If all of the inspectors are at headquarters, only the headquarters site will carry talkgroup 577. But if they are all out in the field, there could be 20 sites broadcasting talkgroup 577.

4. A talkgroup can be broadcast from all sites in the system.

Scenario 3 is actually pretty common, as it eliminates the need for system admins to know in advance which site is going to be the best choice for a given set of users, and if a site goes offline and there is another site in range, there is a seamless and immediate failover to the alternate site. It also covers situations where people are out of their normal operating area on a mutual aid call, or are responding to a disaster. As long as they are within range of any site, they can call home and communicate with each other.

So the mapping between sites and talkgroups can change daily or hourly, depending on the configuration of the system, and what the users are doing. It may be a nice idea in theory, but in practice, often you may be trying to nail jelly to a waterfall.

 

[slicerwizard]

Those who monitor these large systems know which sites talkgroups show up on and most certainly could create such a spreadsheet. They already use this knowledge to properly program their radios and scanners.

 

[jpolich7]

Those who monitor these large systems know which sites talkgroups show up on and most certainly could create such a spreadsheet. They already use this knowledge to properly program their radios and scanners.

Thanks for chiming in.

 

[slicerwizard]

No prob.

 

[DaveNF2G]

This is another Theory versus Reality debate.

In theory, jonweinke is correct. That is how systems are designed to operate.

In practice, slicerwizard is correct. Over time, the actual configuration of a system tends to settle into recognizable patterns that can be documented and used to make predictions of usage.

 

[INDY72]

And guys, this is about simulcasts right? There is no what site carries what. Literally.
Every site in an simulcast system carries every transmission of every user assigned to that system. If you live in an area that has multiple simulcast that are subsets of an main system, it won't take too long to map out who is on which simulcast, and who is on multiples, or all of the ones in use. An prime example of this is the Indianapolis Department of Public Safety family of TRS. IDPS has one core that runs as of now, 4 P25 Phase I LSM systems. System 1, is the Public Safety tier for Marion County, and carries all PS Ops for the county, and has 1 shared site with System 3, that is the Hamilton County tier of the family of systems. There is also System 2 which is the Public Works tier for Marion County, also sharing the 1 site with S3. Then is the newest member of the family, System 4, the Madison County tier of the overall network. Each of these systems has at least 8 towers. The only mapping one can do with this system is by those of us running UniTrunker and Pro96Com on the 4 LSMs. By doing so we have mapped out the networks by both TG, and RID. The RIDs matched up with TGs have told us there is a little overlap for interop between S1 and S3, as well as between S3 and S4 on the Public Safety side of things. But we also know that no matter what *site* in the system that an user is assigned to, his traffic is on every one of the *sites* in the simulcast system. So on System 1, if an City of Lawrence PD unit is running an plate in downtown Lawrence, you will hear his traffic in the City of Speedway on the *site* nearest you, and in City of Indianapolis, and over in Beech Grove, even if there is NO Lawrence radio in those areas. Because no matter which tower captures that radio and initializes affiliation, every tower is affiliated with since all of them act as one single site. So trying to say that the Lawrence Tower of the system is what you want to use for Lawrence traffic is pointless, and individual towers mapping is only useful for aiming an Yagi at to try to eliminate simulcast distortion for an scanner. The only real mapping for it has been done as good as its going to get until we get hexagonal mapping for actual coverage etc.... Now if you mean you want notations in the database listings made to say XYZ PD uses Simulcast C of this network, that is being done by some admins but is not an standard requirement and no official guidelines for the practice have been set yet. Its probably best that they be made in TG Group notes, not in the TG Description field as we keep trying to get things tidy and concise, especially now that the newer scanners use that field for displays. Ad then, there are still a TON of older scanners that use the 12 character limited display and can only really usefully use the Alpha Tag field, which means notations are not happening there lol. So you (the end user - scanner guy) will need to make your own little database of special notes somewhere.

 

[jpolich7]

Yes, this thread is about simulcast

Thanks to all for their opinions. Yes, this thread is about simulcast; the title of the thread is Simulcast Maps & Talkgroup Sites.

To return to the RWC example, if I aim a yagi antenna from my home toward the closest of the 12 antennas used by Simulcast A Phoenix Police about 99 percent of transmissions are not received. This is because there are several other Simulcast A antenna sites farther away but in the same general direction, all of which compete for attention from a scanner.

Putting all these RWC sites, each of which has its own FCC license, on a single map would make it easier for listeners to try to find a strategy that successfully receives Simulcast A. I assume there are other system examples around the country.

Further, some of the RWC Phoenix PD talkgroups are actually also carried on a completely different non-simulcast site, Thompson Peak High. This site is much easier to monitor because it is high powered at a high elevation and not simulcast. But there is nothing in the Radio Reference database to indicate that these talkgroups, representing entire police precincts, are broadcast from Thompson Peak. This is why a spreadsheet or some other way to quickly find this information would be so helpful.