PSR 500 Question

[KC9MHB]

Can anyone explain why the TSYS comes up everytime the scanner stops on a conversation? Is the tuning wrong? If someone can assist on this I would be gratefull. Email me @ kc9mhb@gmail.com

73's


David Parrish
KC9MHB

[tuttleje]

It's normal on a trunked system. If you push the softkey under the TSYS ( F2 ) and then "Analyz", scroll to the control channel it will give you information about the system you are monitoring.

See page 43 of the manual.

[n4jri]

Originally Posted by KC9MHB

Can anyone explain why the TSYS comes up everytime the scanner stops on a conversation? Is the tuning wrong? If someone can assist on this I would be gratefull. Email me @ kc9mhb@gmail.com

73's


David Parrish
KC9MHB

Let me clarify just a bit more. Although you see TSYS on your screen you're still on your TGRP object. The "TSYS" on your display simply marks a softkey (F2) which takes you to the TSYS object if you want to analyze it (as Tuttleje mentioned) or modify it. (as I describe below)

For example, you might want to lock out a trunked system without turning off an entire scanlist. To do this, you'd press F2 (TSYS) then PGM > EDIT > CURR and scroll down to L/OUT with the arrow keys and select 'off' or 'on'. Scroll further down the menu and you can adjust that TSYS for options on attenuation, narrow FM, digital AGC and dwell time.

Prior to the appearance of this feature, you couldn't access your TSYS objects directly unless you knew their object number, or did a search to find them. (TSYS's are not scannable objects, so you can't scroll to them AFAIK) Now you have direct access to the TSYS everytime the radio stops on one of its talkgroups--or when you scroll to one of those talkgroups.

If you're in an area where trunks predominate, you can store a number of systems in the same scanlist and then them on and off at will. A great feature for those of us who miss the subbanks from the PRO-96.

73/Allen (N4JRI)

[Mike_G_D]

Actually the TSYS objects do have a specific object ID associated with them and can be directly accessed. I have my TSYS's grouped in the low ID range (starting at 0) so that I can easily go to them and lock or unlock as I desire. I use these as geographic divisions (north common, north coastal, north inland, east, etc.) while I use the 20 scan lists as usage geopolitical divisions (county law, county fire, state law, state fire, federal forestry, etc). I can then activate, for example, only TSYS "North Coastal" (TSYS 1) and "North Common" (TSYS 0) and scan list "County Law" (scan list #2) and only hear the north coastal county law talk groups and talk groups common to all of the county (mutual aid, etc.) if I so desire. This works quite well for trunking systems. For conventional channels, however, you only have the scan lists to divide them up category-wise.

To go to the desired TSYS just press MAN + (the ID number for the desired TSYS) + ENT. So, for example, if I want to select TSYS number 1 I would press MAN + 1 + ENT. I could then temporarily or permanently lock out that TSYS or unlock it as desired.

-Mike

[n4jri]

Originally Posted by Mike_G_D

Actually the TSYS objects do have a specific object ID associated with them and can be directly accessed.

Actually Mike if you read my post, I didn't claim that TSYS objects couldn't be directly accessed. I said in the third paragraph that you couldn't directly access your TSYS objects without knowing their object number. So I don't think we're in disagreement.

That said, I'm intrigued by your organization scheme, and would love to see a V-scanner file that you've organized in this way.

I've been using objects 0-22 as locked-out conventional objects which identify my Scanlists as I scroll between them with the left/right arrow keys. Using these lowest object #'s assures that each will be 'on top' of its respective scanlist as I scroll along.

I also number all my TSYS objects together starting with 1801 so that there will be predictable numbers in case I have to direct-access. All other object #'s are 2000+ in Win500 so that I can organize my objects with block-sequential numbering. So Win500 changes all those numbers to take up the space from 0023 to 1800 when it uploads the file to the radio.

I think that smart organization is the key to a lot of the problems that new users have here. Would love to trade V-scanners with you to further the state of that particular art.

73/Allen (N4JRI)

[Mike_G_D]

Allen,

Firstly, sorry for the misunderstanding on my part, I apologize! I'll try and attach a file for you to see. One thing I think many people fail to get, at least initially, when dealing with the new OOUI GRE methodology is that the scan lists are NOT banks and do not represent actual physical memory locations as channels in banks do.

Scan lists can be thought of as "category tags". They are simply pointers to memory locations and can have labels allocated to them. This is why you can have an object belong to multiple scan lists and it will not take up multiple memory spaces as putting a frequency in multiple banks would do.

That said, seeing as how you are limited to 20 scan lists (or 22 if you count the Favorites and SkyWarn lists) but you can have as many TSYS objects as can fit in the total memory it makes sense, for trunking systems, to use the TSYS objects as another "layer" of organization. I chose the user/geopolitical divisions for the "limited" number of scan lists while I used the rough geographical boundaries for divisions via the TSYS objects.

Where I am (in north San Diego County, California) we have a very large and comprehensive mixed mode 3600 baud Motorola trunking system comprised of four main zones and multiple fill-in intellipeaters (I think they are called). The four main zones are North, South, East, and Northeast. The four main zones each in turn have multiple sites that are set up in a simulcast arrangement (well at least the North and South are, I am not sure about the other two).

This is the system I am talking about for your reference: Scanner Frequencies: San Diego, County of (RCS - Public Safety) Trunking System, Various, California.

As you can see, it has a large number of users and associated talk groups and covers a large area.

I designate one TSYS as "Common" which carries all of the mutual aid, agency intertie, and non-location -specifc tlak groups. Then I have three others which are designated "Coastal", "Inland", and "East". Because the system is so large it cannot completely fit in one go so I have further divided up the area into "North" and "South" V-Folders. Thus, since I live in the north area I normally have the "North" V-Folder in active memory. If I travel down south I then call up the "South" V-Folder. So the actual names for the TSYS objects (for the RCS) are "North Common", "North Coastal", "North Inland", and "North East" within the North V-Folder and "South Common", "South Coastal", "South Inland", and "South East" in the "South" V-Folder.

In addition to the RCS trunking system I also have other area specific systems such as the city of San Diego trunked system and various other civil, military, and private TRS's within the two main V-Folders. There is some overlap contained in both, of course, for example the City of San Diego straddles the boundary between the north and south zones as outlined in a zone coverage boundary map that was publicly available. For east talk groups, becuase the northeast zone was created much later after the north, south, and east zones, I do not have an exact boundary division so I have many overlaps here (for example east talk groups are contained in both the Northeast and Southeast TSYS objects).

In any case, I should point out that I certainly didn't invent this strategy of programming. I learned of it from a couple of folks discussing it on this site way back when the GRE PSR500 first came out and applied it to my own use when I finally was able to purchase one of these scanners. Also, I believe Don Starr, the creator of WIN500, also was advocating this approach, at least as one option, along with those folks whose names I cannot currently recall.

I will try and attach the two main V-Folders. Hope they provide the insight you desired!

-Mike

[n4jri]

I'll look forward to browsing through those files, Mike. Those big California systems are something else, and they certainly seem to lend themselves to management by turning TSYS's on and off.

Here's one of my typical V-folders set up for easy scrolling. Objects 0-22 are locked out and act only as markers for the scanlists. Because of their low numbers, they are guaranteed to appear at the top of each scanlist as I scroll with the left/right arrow keys. I put a DCS code on the 'marker' objects so they wouldn't break squelch as I scrolled across them.

Everything else is block-sequential above 2000. This way only my SL markers and TSYS objects are actually forced to be specific object #'s. After looking at your file, I might start numbering my TSYS's from 1851 backwards instead of 1801 forwards.

Object numbering is set up so that everything is organized by scanlist and locality. That allows me to modify the files frequently without having to reassign large segments of object numbers. In scanlist 5, for example, one county might start at 5101, another at 5201, and yet another at 5301. That allows me to manipulate one county at a time, and shuffle things easily within that county.

73/Allen (N4JRI)

[Mike_G_D]

Thanks Allen, I see the logic in how you have organized your files; I have downloaded the file and will study it more closely later on. One thing to note, I initially did something similar to you in that I used block organization with the 1000's and 2000's etc. for ID numbers. However, as I wanted to have the numbers remain consistent between the program and the scanner for reference purposes I abandoned that approach. One reason I needed that consistency was so that I could easily manipulate the scanner manually when away from the computer. Also, due to the amount of data that I have I could not afford "dummy" channels to use for labels for the scan lists as you did. When I add to or otherwise modify my files I always renumber them using the "All Objects" tab and reassign object numbers option in WIN500 which I find very useful. As you can see, I keep my search objects at the high end of the scanners' object ID lists - those I do not reassign, at least not very frequently. But I can see, after a brief review, how your method works well for you.

I, too, find it interesting to see how others have their units programmed and have modified my initial attempts when I find someone else's methodology has advantages that I can use effectively.

As you say, the organization of these scanners' memory is the key to getting the most out of them.

Thanks for sharing!

-Mike

[smokeyjones666]

Is there any disadvantage in using multiple TSYS objects for the same system in that way, in particular if you're using a feature like Multisite Stat? (For instance, extra long times to scan each system?) I too live in an area with a rather large P25 system and if I could separate police, fire and others into different TSYS objects yet still have the same scan list organization it would be like multiplying the number of available scan lists.

[n4jri]

Originally Posted by smokeyjones666

Is there any disadvantage in using multiple TSYS objects for the same system in that way, in particular if you're using a feature like Multisite Stat? (For instance, extra long times to scan each system?) I too live in an area with a rather large P25 system and if I could separate police, fire and others into different TSYS objects yet still have the same scan list organization it would be like multiplying the number of available scan lists.

Here are the disadvantages that I see in multiple TSYS:

1 - Each TSYS has to be separately checked, resulting in additional time taken, and in a greater possibility that you have other system activity going on which is not available on your current TSYS object. In other words, missing a police call while scanning your Fire TSYS, etc.

2 - If you're using your Wildcard to search for new TG's, it's best to have all your TG's for a given system attached to the same TSYS. Otherwise you'll see police TG's show up with no alpha tags while scanning your fire TSYS and vice versa.

Here in Richmond, VA we have a 3-zone system serving two counties and two cities. Each zone has its own CC's but I put them all in one TSYS and use multisite stat. That keeps my Wildcard quiet until it actually discovers something new.

Just remember that in the PSR-500 you're not limited in the number of TG's you assign to a given TSYS. (with the PRO-96, you can only have 150 TG's per system). One of the selling points of the PSR-500 is that one P25 or Motorola TSYS (10 memory blocks, I think) could over 1800 TG's (1842, maybe?) attached. It's been tested and performed well with around 1800 TG's I think.

Also unlike the PRO-96, you can assign your TG's to any scanlist you want. You're not stuck with TSYS and talkgroups all in the same bank together. So if most of your listening is on a big trunked system, maybe you could just divide your TG's among up to 20 scanlists.

73/Allen (N4JRI)

[n4jri]

Originally Posted by Mike_G_D

I, too, find it interesting to see how others have their units programmed and have modified my initial attempts when I find someone else's methodology has advantages that I can use effectively.

I'd like to see more examples of organization from more users. It's also interesting how needs vary.

My block-sequential numbering serves me well because I'm constantly changing the files involved. They allow me to highlight and even resort small segments of my object lists without affecting the other groups surrounding them. I also sometimes use dummy objects to split up sections of a long scanlist.

Out where you are, I can see where you don't have room for non-active objects. Those systems are huge. I was surfing the Orange and San Bernardino systems, and they're real jawdroppers. They make statewide systems in VA, WV and NC look pretty puny.

Theres also the hope that a future firmware update might cause the existing SL alphas to do what I'm now sacrificing 22 CONV objects to do.

Those guys have done some amazing things since the radio was first released.

73/Allen (N4JRI)

[jnewell]

This is a great discussion. I live in MA, which is totally different from the situations you guys are in, both in terms of the structure of governmental agencies and in terms of public safety radio systems. However, the organizational approaches you're discussing here are very interesting and, I think, must-read material for PSR500/600 and Pro106/197 owners. These are great radios but really do need some thought to deliver their full potential. This thread should be a sticky and/or be WIKI-fied, IMO. Thank you for your discussion here!

[Mike_G_D]

Originally Posted by n4jri

Here are the disadvantages that I see in multiple TSYS:

1 - Each TSYS has to be separately checked, resulting in additional time taken, and in a greater possibility that you have other system activity going on which is not available on your current TSYS object. In other words, missing a police call while scanning your Fire TSYS, etc.

2 - If you're using your Wildcard to search for new TG's, it's best to have all your TG's for a given system attached to the same TSYS. Otherwise you'll see police TG's show up with no alpha tags while scanning your fire TSYS and vice versa.

Problem #1 is partly why I use the TSYS objects for geographical separation rather than departmental separation. I use the 20 scan lists for departmental separation. The TSYS objects can be turned on or off fairly easily as required and are there primarily to allow me to focus on certain geographical locations. Although I often have all of them engaged I can easily deselect them (both the TSYS's and the scan lists) to focus on the location and department/user I want.

And I don't use the wild card feature with this file (not usually) because of the problem with #2. I actually have another file in my V-folders that is just the RCS all in one TSYS object with all of the known talk groups programmed. This is what I use when I want to search for new talk groups. Because this file uses most of the memory for just the RCS talk groups it is not practical, in my case, to use as my main general listening file but it is nice for wild card searches and for using with the Multi-site STAT function when I want to hear as much as possible from outlying sites on the RCS.

Allen, if you want I can send you this file also. But it is pretty boring as it focuses primarily on the RCS and virtually nothing else (I have some conventional stuff in it just for convenience when using the file but not much else). It has all of the talk groups I have found on here and other local scanning websites (of course I may have missed some but most are there).

And to address the Multi-site issue, I have experimented with it but find it best to leave it off for most of my usage. For me in my area a lot of the talk groups that I am interested in are only carried on the North simulcast loop. With multi-site on STAT I will miss a lot of traffic as it scans the other sites. And around here, Roam mode can lead to very unpredictable results. This is because there are so many other systems within range some of which share frequencies with the RCS and the scanner has no way of telling one system from another as it does not use the SysID when scanning. Without warning you can end up on some foreign system and not hear anything (at least of interest).

-Mike

[n4jri]

[QUOTE=Mike_G_D;1031737]Problem #1 is partly why I use the TSYS objects for geographical separation rather than departmental separation. I use the 20 scan lists for departmental separation. The TSYS objects can be turned on or off fairly easily as required and are there primarily to allow me to focus on certain geographical locations. Although I often have all of them engaged I can easily deselect them (both the TSYS's and the scan lists) to focus on the location and department/user I want.[\QUOTE]

I agree. You're loading up that radio big time (I need to look again and check your object counts<g>) And are apparently able to get a lot of flexibility out of each of your V-folders. I have to keep several V-folders for the Richmond area in order to serve different purposes.

[QUOTE=Mike_G_D;1031737]And I don't use the wild card feature with this file (not usually) because of the problem with #2. I actually have another file in my V-folders that is just the RCS all in one TSYS object with all of the known talk groups programmed. This is what I use when I want to search for new talk groups. Because this file uses most of the memory for just the RCS talk groups it is not practical, in my case, to use as my main general listening file but it is nice for wild card searches and for using with the Multi-site STAT function when I want to hear as much as possible from outlying sites on the RCS.[\QUOTE]

I have all the dogcatchers and dump trunks in my main system but locked out for Wildcard purposes. I keep a separate TSYS for those TG's with no wildcard in case I actually want to listen to them. Again, I'm not under quite the pressure for efficient use of space that you are. And like you, I keep one file with known TG's locked out so that I can get into Wildcard usage--but I have two radios, which makes this much more practical.

[QUOTE=Mike_G_D;1031737]Allen, if you want I can send you this file also. But it is pretty boring as it focuses primarily on the RCS and virtually nothing else (I have some conventional stuff in it just for convenience when using the file but not much else). It has all of the talk groups I have found on here and other local scanning websites (of course I may have missed some but most are there).[\QUOTE]

I'd love to see it, as might some of the other users here. I hope we'll hear from some other guys who have played around with this.

Originally Posted by Mike_G_D

And to address the Multi-site issue, I have experimented with it but find it best to leave it off for most of my usage. For me in my area a lot of the talk groups that I am interested in are only carried on the North simulcast loop. With multi-site on STAT I will miss a lot of traffic as it scans the other sites. And around here, Roam mode can lead to very unpredictable results. This is because there are so many other systems within range some of which share frequencies with the RCS and the scanner has no way of telling one system from another as it does not use the SysID when scanning. Without warning you can end up on some foreign system and not hear anything (at least of interest).

So I take it your system isn't simulcast. That's the only disadvantage I see to the single-TSYS idea. With a system like STARS here in Virginia, all sites have separate CC's and there's only room for 32 per TSYS.

73/Allen (N4JRI)

[n4jri]

I think that the organization discussion may be fruitful if some others join in as well. I wonder if we could find a good chopping point here to start a new thread, or maybe rename this one to call attention to this subject?

73/Allen (N4JRI)

[Mike_G_D]

Allen,

Yeah, I think we actually inadvertently hijacked this thread from the OP! Oh well!

Anyway, actually the RCS is simulcast but only parts of it are. I have read conflicting reports about the East loop (in the Southern California Frequency Directory 3rd edition it is listed as not being simulcast) but I know the North loop is and I believe the South Loop is also.

It's really a mixture of simulcast and intelipeaters or some such. Others can better describe it as I am still a little sketchy on this.

The traffic on the different loops is different and generally area specific. Some talk groups such as Cal Trans and CHP get carried on all loops regardless (apparently) of radio affiliation but most local communities talk groups and county law talk groups only get carried on the loop that contains that area.

Within the loops themselves, at least the North and South loops, there are simulcast sites which broadcast on the same frequencies and are phase locked to a central reference.

So, as I said, it's a mix of simulcast sites (within a loop) and separate systems (separate loops and some fill in intellipeaters).

I'll attach that wide area RCS file to this post. Also, in addition to using this file for wild card catches and for occasional wide area monitoring I also use it as a master file for the RCS. So, if I make changes based on new information (for the RCS) I try and make them first on this file and then copy the relevant data to the appropriate North or South files. This is why you see the "NCOM", "SCOM", "NI", "SI", "NC", "SC", etc. in the WIN500 Notes column. I use those tags to quickly allow me to group portions together to copy to the appropriate TSYS's in the North and South files (i.e. "NCOM" means it belongs in the North Common TSYS and NC means it belongs in the North Coastal TSYS, etc.). If I make a change to the Wide area file I make sure to tag it for the appropriate area and then can use that tag to direct me on where to copy it in the other files.

-Mike

[n4jri]

Originally Posted by Mike_G_D

The traffic on the different loops is different and generally area specific. Some talk groups such as Cal Trans and CHP get carried on all loops regardless (apparently) of radio affiliation but most local communities talk groups and county law talk groups only get carried on the loop that contains that area.

Our system is similar. With the exception of one locality, all police, fire & EMS dispatch freqs and all fire response tacs are simulcast on the whole system. For most other TG's something has to be affiliated in the zone for it to be heard. This is what makes multi-site stat work for me. I'll hear PD/FD/EMS dispatch no matter which zone's CC I'm tracking. Police surveillance, fire marshals, dogcathers and dump trucks are all normal SmartZone.

Thanks for sharing the file. I look forward to checking it out.

73/Allen (N4JRI)