Multi-Site mode and programming the PSR500

Status
Not open for further replies.

N7YUO

Member
Joined
Mar 23, 2004
Messages
694
Location
Kearns, UT
As I read the owner's manual again and again, I have come to these conclusions:
1. If I want to program the UCAN TGRP objects only once, I will have to choose Multi-Site,
and deal with all the additional parameters.
2. If I want to be able to select individual sites: WB Simul, DA Simul, SL Simul, UT Simul,
then I will have to program each of those as separate TSYS each with it's own set of TGRP.
Common TGRP such as Landing Zone 1 and Event(s) will need to be programmed for each
different TSYS.
3. Scenario: I program TSYS Weber County. I use the CC for WB Simul. I program all the Event,
and air ops TGRPs. Now I program for other counties and I "map" those common TGRPs to the other
scan lists. Now I am in Wendover trying to monitor a helicopter landing on LZ-1, but the parameters for that TGRP say that it belongs to WB Simul site, not Wendover Peak site. Since it cannot receive WB Simul CC, the radio stays mute.
4. If I were to travel to an unfamiliar area such as Seattle, Multi-Site and Roam would be beneficial, since I would not know the coverage areas of the various sites. Here in Utah, I know when to switch sites. Also, with IR sites like Nelson and Mt Ogden spewing rf far and wide, I don't want my radio jumping to those sites just because they have the highest threshold values.

Your comments, criticisms, opinions are welcome !
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
Big system/Multi-Site mode

Mrgadget,

I would think of the multi-site capability of the PSR500/600 separately from how you want to best set up your area programming. On these scanners the multi-site feature mainly concerns how the scanner "looks" at the control channels you have programmed into a particular TSYS object thusly:

Off: As most trunking scanners have always worked - Pick the first decent control channel and park there until it drops to unusable. (I have reason to believe the actual algorithm is doing a bit more than just this in the PSR500/600 but it's just suspicion for now; the official word is pretty much how I stated it and we'll stick to that).

Roam: The scanner looks at the control channels receivable by it and picks the one wherein the decode rate does not drop below what you set as Threshold Lo; what you set as Threshold Hi determines the "goodness" of the control signal that you have determined it should look for. For example, if you set Threshold Hi to 90% and Threshold Lo to 70% then the scanner will look for a control channel with a decode rate of at least 90% and park on that until it goes below 70% at which time it will attempt to find a better quality control channel.

Stat: The scanner will actually park on each decent quality control channel in succession according to how you have the "Check All CC" setting set. If "Check All CC" is set to "No" then the scanner will park on a different decent quality control channel each time it scans that TSYS. If you have "Check All CC" set to "Yes" then the scanner will park on each decent control channel in the list successively looking for programmed talk groups BEFORE leaving that TSYS and moving on to other TSYS's or conventional channels.

The idea, here, is that you can use Roam in a multi-site system so that, while moving, the scanner will attempt to lock on the best site it can find (according to how you set the thresholds) and stay on that site until the quality drops below what you have set in Threshold Lo at which time it will attempt to find a better site matching your Threshold Hi value, if at all possible. It's not a perfect system and has some limitations that, depending on your area and what other systems share those frequencies, can adversely affect the performance. However, if you move around a lot it may be worth experimenting with it (but see my note below).

Stat is intended to allow you to scan through all decent quality control channels while stationary (say, at home or work) so that you can hear all of the available traffic on all of the available receivable decent quality control channels. This can result in a long scan time, however. It will either take many successive passes through the TSYS to get through all of the control channels (if "Check All CC" is set to "No") and you may miss a lot of traffic on a busy system or it will take a long time scanning through the control channels during each pass through that TSYS (if "Check All CC" is set to "Yes") in which case you may miss activity on your other TSYS's and conventional channels. But it's all a compromise and it's up to you how to use these functions.

NOTE: As I wrote above, the system isn't perfect and does have some limitations. One notable problem with all modes (Off, Stat, or Roam) is that the scanner cannot isolate a system by its System ID, it only uses the decode quality as a filter, therefor, if you have other systems sharing some control frequencies with the ones you want to use within receivable range then the scanner might "falsely" lock on those systems and you may not hear what you wanted to; where I live, it is a major problem as I have many systems outside my desired area with good quality control channel signals that share some frequencies with the system I want to monitor. It most adversely affects Roam and Stat modes, since these involve the scanner most frequently checking other listed control channel frequencies but it can affect the scanner even when set to Multi-Site is set to "Off" due to the rapid changes in signal quality even while stationary (I think it is the many mountains toward my east causing rapid signal fades and phase changes on the strongest site's control channel output).

All that having been said, I think your question seems more geared toward how best to organize your programming rather than how to set up the PSR500/600's Multi-Site mode (though, of course, knowing how that mode works is still very useful!).

I looked at the UCAN system - it is indeed quite large! When reading your post I thought of how I set up my programming for my area. The system I monitor is also very large and has many sites covering a large area. It's here: http://www.radioreference.com/apps/db/?sid=499 if your interested. It covers two large counties in southern California and has many different users.

What I ended up doing was dividing up the area I wanted to cover roughly geographically using the labels for the talk groups as a gauge on where to include them. I set up two V-folders which roughly divide the area up into NORTH and SOUTH. Within each V-folder I have subdivided further into COMMON, COASTAL, INLAND, and EAST. These are actually individual TSYS objects. I can select these and deselect these using Funct+XX wherein XX is the number of the TSYS in the scanner's memory - I use the lower numbers for the TSYS objects to make it easier. I can temporarily or permanently lock out the TSYS's as desired according to where I am or what I am interested in.

Now the COMMON TSYS is what may be of interest and use to you in your situation. I originally did not use it and was frustrated that I had to copy so many talk groups between each TSYS - those talk groups not expressly used in distinctive "East", "Inland", or "Coastal" areas. This really began to balloon the memory usage until the obvious "DUHH!" moment hit me - add one more TSYS object which contains the talk groups common to all areas and not repeat them in each of the others! Adding a TSYS object only adds 10 blocks of memory usage in addition to the talk groups within it and is much better than trying to recopy three hundred fifty talk groups into each other TSYS! So the COMMON TSYS is always activated since it is applicable across areas while I can elect to activate the more area specific TSYS's as needed.

I'm thinking that maybe the "Common" TSYS idea might be helpful in your case?! I would find those talk groups you know are used throughout the area (state, in your case) and put those in the "common" TSYS while dividing up the other talk groups according to the areas they are intended to be most used in and assign those to specific regional TSYS objects. If you can't fit all this in one active memory program then divide the state in two in a way which suits you - say, for example, east and west or north and south - whatever works best for you. Just pick a usable dividing line that won't make it too frequently that you need to call up the other V-folder. Everything else is then fairly easily activated and deactivated by using the temp or permanent TSYS lockouts within active memory.

It would be nice if the PSR500/600 allowed talk groups to be assigned to multiple TSYS objects rather than just one but, oh well!

And you may ask how I use the scan lists. I use the scan lists as ways to subdivide by agency and user. In my case I use the following:

1) County Fire

2) County Law

3) County Emergency

4) County Medical

5) County Roads

6) County Misc.

7) State Fire

8) State Law

9) State Emergency

10) State Roads

11) State Misc.

12) Federal Fire

13) Federal Law

14) Federal Emergency

15) Federal Forestry/Parks

16) Federal Military

17) Utilities

18) Rail/Bus Transport

20) General Misc.

I'm not sure if any of this helps but maybe it can give you some ideas!?

Good luck!

-Mike
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
annnnnd...some stuff I forgot to mention!

Umm, left some stuff out, now that I think about it!

So, to add to what I already wrote:

Each of my TSYS objects contain ALL of the entire system's primary and alternate control channel frequencies (well, all but the ones in the other county, Imperial). I normally use Multi-Site set to OFF unless I am traveling within the area and then may use Roam depending on how well it works for me given the local conditions. I sometimes use Stat when at home to just "browse" through all the receivable sites - but because of my area and the local RF conditions (including outside non-system sites, as I noted previously) I can't always get effective usage out of this mode.

In your case you will have to just experiment. I would start by putting as many of the primary and alternate control channel frequencies for your system as you can. Your system looks very large but you may be able to cull out repeated control channel frequencies (re-used on differing sites). If there are still too many control channels then divide them up using the "east/west" or "north/south" division I have already mentioned. Use one half in one V-folder representing one large area and the other half in the other V-folder - use some overlap, don't just actually chop in half, I doubt you need to, anyway, so that when traveling between the "boundary" you have set (again, up to you) you don't just drop all the channels you were using (some overlapping sites).

For what it's worth, I set my "north" versus "south" boundary based on an old site coverage map which used a local east-west freeway as a dividing line. In your case, I would think there must be some local geographical or geopolitical imaginary "line" you can come up with that works for you!

Again, good luck!

All for now...at least until I can think of something else I forgot to mention!

-Mike
 

N7YUO

Member
Joined
Mar 23, 2004
Messages
694
Location
Kearns, UT
Programming for Performance

Quote: "This really began to balloon the memory usage until the obvious "DUHH!" moment hit me - add one more TSYS object which contains the talk groups common to all areas and not repeat them in each of the others! Adding a TSYS object only adds 10 blocks of memory usage in addition to the talk groups within it and is much better than trying to recopy three hundred fifty talk groups into each other TSYS! So the COMMON TSYS is always activated since it is applicable across areas while I can elect to activate the more area specific TSYS's as needed."

When programming the Pro93 and Pro95s, CC trunking allowed me to program similar to what you have described. I did not program all the CCs (Control Channels) (for the benefit of our less experienced), in each bank. Basically, when I travel into another county, I want to primarily monitor the simulcast site. That is where the action is. I might some juicy special ops on simulcast, but if I switch to an IR (Independent Repeater) site, they are not there because none of the special ops team is 'Affiliated' to that IR site.

When programming CC freqs for a county, I programmed them this way:
CC Simulcast
CC IR site 1
CC Simulcast
CC IR site 2
CC Simulcast
CC IR site 3
The scanner did as you stated. It scans the programmed freqs and 'locks on' to the first 'quality' one it comes across. It remains there until the quality of the signal diminishes to some low value and it scans for another CC channel. The benefit: When I drive under a bridge or enter some other shadow area, the scanner always searches for, and usually finds a signal. Each time it searches for a signal, it has to check the simulcast site.

The Banks were arranged in this order:
Bank 0 All SAR (Search & Rescue), SOPS (Special Ops) Fire, and all common use TGRPs.
All CC freqs for the entire system were programmed as well as the ITAC freqs.
Bank 1 Salt Lake County Sheriff TGRPs and SL UHP TGRPs
SL Simul and Nelson Peak IR sites
Bank 2 Salt Lake City TSYS and their TGRPs. Salt Lake City now has one combined site
Bank 3 Other cities within Salt Lake County
Bank 4 Davis County Simulcast, IRs, and Davis TGRPs
and so on. Counties with smaller populations were grouped together: Summit and Wasatch.

Since memory was fixed (In the PSR 500/600 it is 'dynamic') I used the remaining channel memories to program conventional freqs for other areas and uses: Marine VHF radio, SE Utah VHF, SW Utah VHF.

One of the best ideas that I got from your post was using the smaller Object Numbers for the TSYS.
So when you want to activate or deactivate them, it takes less key stokes.

EVERYONE - Please pay attention to this: Our system has 'Event TGRPs' The State Radio template has them in every public safety radio, in the same 'zone'. They were intended to be used for 'events' such as festivals, parades, and such. But since every radio has them, and they are 'authorized' on every site for evey user, they have become ideal TGRPs for surveillance and undercover.
Now if your local system has similar TGRPs by whatever name, I recommend you keep them programmed in and scan them always. The undercover's sometimes get creative. They were operating in Davis County,
Affiliated to a site in Salt Lake County, and transmitting on the event TGRP for Tooele County. But they couldn't hide from me.
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
MultiSite cont.

Actually the idea for the low TSYS index numbers came from another thread. I can't remember the folks who discussed it but the thanks go to them!

For me, that idea plus the "common" TSYS really pulled it all together. I spent probably close to two weeks massaging the WIN500 programming before I actually even bought the scanner. I am somewhat of a "thoroughist" when it comes to my scanner programming and pretty much like to include as much as possible in as orderly a fashion as possible. Fortunately, the way I used to program my older banked scanners (Pro93, Pro96, Pro97) was suitable to relatively easy adaptation to the PSR500's methodology. And, of course, I am always improving, updating, tweaking, etc.

I include all talkgroups I can find in the programming including the special event TG's. Your comment about the usage of those was interesting! I have noted similar usage for other non-obvious law enforcement TG's also. One of the local PD's has a "traffic" tactical. I am not sure what the official use of it is supposed to be, though I assumed it had something to do with "traffic", but have heard much of what appears to be surveillance activity on it. So I understand your point!

-Mike
 
Last edited:
Status
Not open for further replies.
Top