• Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

PSR-500 Scan List "limitations" - possible workaround

Status
Not open for further replies.

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
In various threads, it's been mentioned that the PSR-500's 20 Scan Lists might be somewhat limited, based on users' preferences for subdividing groups of talkgroups in trunking systems. Sometimes, comparisons are made to some brand-U radios that have "systems" and "quickkeys", that essentially let you create complex hierarchies of things to be scanned (I don't own such a radio, so my terminology may be off).

I think I've come up with a potential workaround for the PSR's apparent limitation here. It makes use of the fact that you can lock out a trunking system ("TSYS object"). It does require some kind of PC software, something that can assign "Object IDs" to any object...

If I want to monitor my local trunked system (City of Santa Clara, CA, an analog-only Mot 3600 system), and have control over whether I'm monitoring a) everything, b) just police, c) just fire, d) police and fire, etc., but only use Scan List 01 for everything, here's what I'd do:
  1. Create three TSYS objects. They're all identical. Their object IDs are 0010, 0011, and 0012.
  2. TSYS 0010 will have all of the interesting talkgroups except police and fire. TSYS 0011 will have police only. TSYS 0012 will have fire only.
  3. Add TGRP objects to each TSYS, according to the filtering in (2)
  4. By my convention, the TGRP objects are in scan list 01. This is the "tens place" of the three TSYS object IDs. If I was putting the TGRPs in scan list 02, the TSYS object IDs would be 0020, 0021, and 0022. (My convention limits me to the first 10 scan lists).

Normally, I'd be scanning all three TSYS objects - leaving the TSYSs "not locked out" and enabling scan list 01.

If something interesting happens on the Fire talkgroups, I might want to ignore all of the talkgroups in the "everything" (0010) and "police" (0011) TSYS objects. Via a few key presses, I can lock out all of those TGRPs, by locking out the TSYS objects:
MAN 1 0 ENT L/OUT 1 1 ENT L/OUT SCAN
I've just locked out TSYS 0010 ("everything") and TSYS 0011 ("police"), and am only scanning the Fire talkgroups.

To re-enable the "police" TSYS, I'd hit:
MAN 1 1 ENT L/OUT SCAN

Drawbacks of this method:
  1. My definition of "a few key presses" may not be the same as yours. To lock out the two TSYS objects above and return to Scan mode required 10 key presses. Still, it's far less than locking out 50 TGRP objects individually.
  2. It requires PC software that can directly manipulate the TSYS Object IDs, since the radio doesn't let you do that from the keypad
  3. For MOT and P25 systems, each TSYS object beyond the first takes 10 additional "blocks" of memory (EDACS and LTR would be 4 blocks each). If you do this for too many trunked systems, it could have significant memory usage effects.
  4. It may increase scan cycle times. Each TSYS would be "scanned" for the default "dwell time", unless you change that value in the TSYS menu. My local system uses "scan markers", which the scanner seems to recognize - the PSR-500 only camps on each of my TSYS objects for 100-200 mS (watching the "CCDump" data, it looks like the radio leaves a Mot 3600 system if it has seen two of these "scan markers", even if the dwell time has not yet elapsed).
  5. It only works for trunking systems, where you want to subdivide categories of talkgroups
 

DaveNF2G

Member
Premium Subscriber
Joined
Jan 23, 2001
Messages
9,209
Location
Rensselaer, NY
I don't think a TSYS is a scannable object. A TGRP is, and can be locked out or assigned to scanlists. The only way to "scan" a TSYS is to set up a Wildcard TGRP object and scan that.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
A TSYS can be "locked out".

If you have a bunch of TGRPs for a certain TSYS, and all of the TGRPs are in "enabled" scan lists and not locked out, the TGRPs will only be "scanned" if the TSYS itself is not locked out.

I really did test the above procedure before typing all of that.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
Another shortcut...

In my example situation above, where I wanted to monitor only the "fire" talkgroups, I could skip the "MAN 1 0 .... SCAN" steps. Instead, I could just keep monitoring. If/when a "police" or "everything else" TGRP went active, I could hit F2 (the "TSYS" softkey) - that would put me in MAN mode on that TGRP's TSYS. I could then hit L/OUT (locking out the TSYS). Then I'd hit SCAN. Now I'm scanning again, but have eliminated the TSYS that "contains" all of the currently uninteresting TGRPs.
 

DaveNF2G

Member
Premium Subscriber
Joined
Jan 23, 2001
Messages
9,209
Location
Rensselaer, NY
DonS said:
A TSYS can be "locked out".
Upon reflection, you're right. It still gets a little confusing with the different kinds of objects on the 500/600. I just wasn't visualizing what you were describing the right way.

:wink:
 

bneilson

Member
Joined
Aug 2, 2004
Messages
856
Location
South Jordan, Utah
This is an interesting thought...

One potential issue that I see is having to enter Talk Groups multiple times, since a given Talk Group can only be 'Linked' to a single system (TSYS). If a given talk group were to be part of multiple TSYS objects as mentioned it would have to be entered multiple times...

Personally I have been able to overcome the 20 scan list limitation with V-Scanners and the use of temporary lockouts.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
bneilson said:
This is an interesting thought...

One potential issue that I see is having to enter Talk Groups multiple times, since a given Talk Group can only be 'Linked' to a single system (TSYS). If a given talk group were to be part of multiple TSYS objects as mentioned it would have to be entered multiple times...

Personally I have been able to overcome the 20 scan list limitation with V-Scanners and the use of temporary lockouts.
My proposed solution above doesn't involve putting any TGRP into multiple TSYS objects. Instead, I'd break the trunking system apart into multiple TSYS objects, only placing TGRPs into a single TSYS. For example, I might have a TSYS that has all of the "Fire" talkgroups, another TSYS for all of the "Police" talkgroups, and a third TSYS that has "all the other" talkgroups. By locking/unlocking individual TSYS objects, I can control which TGRPs I hear.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
Interesting thought Don. It's really unfortunate that we have to resort to all these "workarounds" to do talkgroup filtering. This is really one place where the PSRs fall down (but of course make up for in their superior reception and decoding capability).

But I have to strongly agree with you on drawback #4 -
It may increase scan cycle times. Each TSYS would be "scanned" for the default "dwell time"

I set my dwell times to zero so the radio only stays long enough to determine if there is something I want to hear and then it moves on. As you said, this may only be 100-200ms but multiplied by the number of TSYS objects/systems you're trying to monitor - coupled with the likelihood it's going to stop on at least one TG along the way, it can take a really long time to cycle back around.

I really want to listen to multiple systems (TSYS objects) - even before your idea of now possibly 3 TSYS objects for a single system but I typically find that I'm missing conversations on my "primary" system because of the increased cycle time while monitoring so many systems.

I'm not trying to hijack your thread but maybe a "PRIORITY" scanlist would be helpful - that is, if I have all 20 scanlists enabled, give me the option to have a scanlist of my choice sampled once between every scanlist (i.e. 1 - 2 - 1 - 3 - 1 - 4 - 1 -5, etc.). Then at least my "home" system could be checked more often/quickly.
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
troymail said:
But I have to strongly agree with you on drawback #4 -
It may increase scan cycle times. Each TSYS would be "scanned" for the default "dwell time"

I set my dwell times to zero so the radio only stays long enough to determine if there is something I want to hear and then it moves on.
A TSYS dwell time setting of zero means "automatic", and seems to make the radio use a "default" timeout value for each trunking system type. This default timeout seems to be about 1 second. The exception is Mot3600, *if* scan markers are used by the system (they're not used on every Mot3600 system). The radio seems to use scan markers to do an "early exit" of the TSYS check.

Of course, a TSYS's CC is only checked for as long as it might take to find an "interesting" talkgroup. If something is found in the first 100 mS, then the radio will leave the CC, going to the VC, at that time.

Whether this is a drawback is user-dependent. For example, it doesn't bother me much. I typcially only monitor a few CONV objects, plus a single Mot3600 TSYS that uses scan markers. If I break that single TSYS into three, those three are all checked in about 500 mS. This is still much less than a single Mot3600 TSYS would take, if it didn't use scan markers. Of course, if I had several unique TSYS objects (or maybe threw in an EDACS or P25 system), then the times would increase dramatically. Hence... user-dependent.

I'm not trying to hijack your thread but maybe a "PRIORITY" scanlist would be helpful - that is, if I have all 20 scanlists enabled, give me the option to have a scanlist of my choice sampled once between every scanlist (i.e. 1 - 2 - 1 - 3 - 1 - 4 - 1 -5, etc.). Then at least my "home" system could be checked more often/quickly.
I'm pretty certain that the radio doesn't scan things based on scan list order or membership, except to determine what should be scanned when you first hit that SCAN key.

If I have a bunch of CONV and TGRP objects in enabled scan lists, but not in any particular scan list ordering, the radio doesn't scan "items in SL01, items in SL02... etc.". It seems to scan all of the "enabled" CONV objects, then all of the applicable (i.e. TGRPs in enabled SLs) TSYS objects.

I doubt that adding a "priority scan list" would be feasible, without changing how the radio works at some fundamental level.
 

WayneH

Forums Veteran
Super Moderator
Joined
Dec 16, 2000
Messages
7,464
Location
Sitting in an airport somewhere
troymail said:
It's really unfortunate that we have to resort to all these "workarounds" to do talkgroup filtering.
It's not that severe of a limitation nor does it take "all these workarounds" to get it to work. This is one simple workaround for people that want to organize one step further (and equal to Uniden's level of organization). It's only a complicated process if people make it that way.

I don't like having to use a cheatsheet or remember 99 scanlists (systems....whatever) and which groups are which within them. GRE's way of organizing data is much more simpler. At least you have object ID's you can use to go direct to an object. Try that with a Uniden.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
wayne_h said:
It's not that severe of a limitation nor does it take "all these workarounds" to get it to work. This is one simple workaround for people that want to organize one step further (and equal to Uniden's level of organization). It's only a complicated process if people make it that way.

I don't like having to use a cheatsheet or remember 99 scanlists (systems....whatever) and which groups are which within them. GRE's way of organizing data is much more simpler. At least you have object ID's you can use to go direct to an object. Try that with a Uniden.
It's a great world isn't it? There's something for everyone to like and dislike -- one size doesn't fit all --- we're both right (my opinion).... :lol:

What we're talking about here is something you can do on a Uniden BCD396 with a subgroup (each system has 10). So I put fire in subgroup 1, police in subgroup 9, etc. The system is scanned and you can lock out an entire subgroup with 30 talkgroups (say police) all at once with FUNC-9 and reenable them the same way -- and the subgroups even have their own alpha tag (a third level).

I'm glad DonS and others offer observations of "workarounds" -- that's what these forums are all about... but we also obviously have the attention of the companies who make these things and the more we talk about the things we'd like to have (or in this case - miss), the more likely we could get those features later.

Keep on posting!
 

DonS

Member
Joined
Jun 17, 2003
Messages
4,105
Location
Franktown, CO
something you can do on a Uniden BCD396 with a subgroup (each system has 10). So I put fire in subgroup 1, police in subgroup 9, etc. The system is scanned and you can lock out an entire subgroup with 30 talkgroups
Unless, of course, you want to have "30 talkgroups" in each of those "subgroups" in a single trunking system. Wouldn't that exceed some weird limit?
 

WayneH

Forums Veteran
Super Moderator
Joined
Dec 16, 2000
Messages
7,464
Location
Sitting in an airport somewhere
troymail said:
It's a great world isn't it? There's something for everyone to like and dislike -- one size doesn't fit all --- we're both right (my opinion).... :lol:
I'll agree with you here.

Hopefully GRE's next gen permits some kind of nested grouping for both TG's and conventional, since this workaround doesn't work for conventional frequencies, which is where I could use it the most.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,977
Location
Supply (Lockwood Inlet area), NC
DonS said:
Unless, of course, you want to have "30 talkgroups" in each of those "subgroups" in a single trunking system. Wouldn't that exceed some weird limit?
Hmmmm... not sure -- There are 10 subgroups but I'm not sure about any limits on how many TGs you can put in a subgroup (although I'm sure there may be one).

(EDIT - Oh, I see where the question came from - I just used "30" as an example... not sure what if any limit exists)

I agree that the limit of 99 or 100 "systems" *could* be an issue but compared to 20 or 22 "scanlists", 100 is still better.... and V-Folders are NOT the same thing.. With QK (quick key) enabling, you can keep what you're already listening to an add another of up to 99 with a quick key sequency of simply "5" (turn on system 5) or . 9 9 (turn on system 99).

It's pretty much the same with the subgroups.

Hey - I love the radio - I just also love some of the features of a competor product and would love the see the best of both in one radio... :)
 
Last edited:

n4jri

Member
Premium Subscriber
Joined
Jan 10, 2004
Messages
1,294
Location
Richmond, VA
I already use Don's system. It has its ups and downs, but it is very useful. In my case, I treat a multi-zone regional system as a multi-site 'stat' setup for all the primary stuff. That keeps police/fire/rescue easily accessible, and the simulcasting of these TG's in multiple zones also helps keep it coming fast.

But for dogcatchers, dump trucks, etc., I keep a separate TSYS for each locality which stays locked out unless I want to engage it.

All the ups and all the downs mentioned here are true, but the system works pretty well in allowing the scanner to cover a wide territory, but to focus on narrow parts of it.

I would add one more drawback: If you like to keep your wildcards active in searching for new TGRP's, having multiple TSYS's with limited TG's can really make those wildcards busy with TG's you already know about--but which aren't attached to your current TSYS. (this is why I listen to the regional system as multi-site. It keeps all my TG's together and I can set the wildcard to ignore them. If I had a separate TSYS for each individual locality, my wildcards would be inundated with simulcast TG's from other localities)

I solve this be having my wildcard attached to my main TSYS, and entering all known TG's that I don't want to listen to as locked-out objects. It takes a LOT of memory to do this, but is generally worth it to keep the wildcard relatively quiet. On my other identical TSYS objects (the ones which stay locked out), I just keep certain objects ready to listen to, but don't have any wildcards.

Not a perfect situation, but remember that you can store 20 v-scanner files. I keep a couple of different v-files for my favorite localities so that I can make the radio perform best to what I'm interested in at any given time. No one programming of the radio is perfect for every purpose, but this radio really shines in the fact that you can easily store programmings which will focus on whatever you're interested in at a paricular time.

73/Allen (N4JRI)
 
Status
Not open for further replies.
Top