Forcing a Control Channel

Status
Not open for further replies.

bneilson

Member
Premium Subscriber
Joined
Aug 2, 2004
Messages
882
Location
South Jordan, Utah
I was just curious if anybody had figured out a way to force which control channel is being used at any given time?

I live in an area that on the same system I can copy multiple control channels that carry different traffic. From time to time, it would be nice to be able to force my PSR-500 to only listen to a specific channel and not search for any of the other that are programed.

On my Uniden, I could L/O control channels. This would cause the scanner to skip the ones that are locked out, essentially forcing me to use the unlocked ones. I cant seem to see a way to do this in the GRE...

Any thoughts?
 

JoeyC

Senior Member
Joined
Dec 19, 2002
Messages
3,512
Location
San Diego, CA
This is very simple. Create separate TSYS's with only the control channel(s) you want, associate the TGs with it and assign those TGs to a unique list and turn multisite OFF. You'll only hear the TG(s) associated with the preferred CC.
 

bneilson

Member
Premium Subscriber
Joined
Aug 2, 2004
Messages
882
Location
South Jordan, Utah
Hey thanks JoeyC

The only issue I can see with this method is that it would require duplication of my programed Talk Groups. Since a Talk Group can only be linked to a single system I would have to enter them multiple times.

It would work though, so thanks for the suggestion. I am really looking for more of something that I can do on the fly like I could with the Uniden...
 

RKG

Member
Joined
May 23, 2005
Messages
1,094
Location
Boston, MA
Hey thanks JoeyC

The only issue I can see with this method is that it would require duplication of my programed Talk Groups. Since a Talk Group can only be linked to a single system I would have to enter them multiple times.

It would work though, so thanks for the suggestion. I am really looking for more of something that I can do on the fly like I could with the Uniden...
1) If you can receive multliple control channels on the same system at the same time, it must be a SmartZone system and you are hearing different zones. This is not efficient.

2) In theory, the "ROAM" feature prevents this, but there is a glitch with that feature in that it does not mask control channels for SysID.

3) Best way is as suggested, i.e., to create a separate TSYS for the different zones. You will have to copy over the TG info, but this can be done by selecting and copying via the Edit menu; no repetitive typing required.
 

rdale

Completely Banned for the Greater Good
Feed Provider
Joined
Feb 3, 2001
Messages
11,380
Location
Lansing, MI
2) In theory, the "ROAM" feature prevents this, but there is a glitch with that feature in that it does not mask control channels for SysID.
What does that mean for the end-user?
 

JoeyC

Senior Member
Joined
Dec 19, 2002
Messages
3,512
Location
San Diego, CA
Yes, and really it doesn't use that much memory either to duplicate across separate zones. The only way you are going to have real control over the scanner is to have a separate TSYS for each zone. If you are programming a scanner to roam on a smartzone system and more than one CC meets the criteria to be locked onto, then you can never be sure you are going to catch traffic across multiple talkgroups unless they are always simulcast across the zones.

I think a lot of scanner users make the mistake of programming their scanners to monitor a trunked system instead of to monitor talkgroups across the trunked system. I made this mistake the first time I programmed my PSR-500 with our Smartzone system lumped into one TSYS in hopes that the long-awaited feature of multisite roaming would sort it all out in the long run. No cigar. I quickly learned that the only way to make sure you are listening to what you program is to program each zone separately and mix and match the TGs in the lists as you wish.

I have my scanner crammed with stuff that I couldn't possibly monitor all at the same time. There are 20 V-Scanner folders to hold different personalities that are quickly loaded so memory is definately not an issue with this scanner. And having temporary lockout feature assures me that everytime I turn the scanner on, those that I locked out previously are undone and I don't have to remember which I locked out and where they are.
 
Last edited:

rickak

Member
Joined
Mar 30, 2003
Messages
389
Location
Fort Collins, CO
If you have your configuration saved to a VScanner you can do anything you want to the current config, as you can always reload the base configuration from a V-scanner.

What I have gotten in the habit of doing when I want to do what you're asking is to go into the menu for the TSYS object and just delete all the frequencies but the one I want. This in effect "locks" the others out. When you're done, just reload the config from the V-scanner.

Agreed, a site lockout feature would be nice.

Rick
 

RKG

Member
Joined
May 23, 2005
Messages
1,094
Location
Boston, MA
What does that mean for the end-user?
Sort of a long and technical story, but the bottom line is that your radio could park itself on a control channel in use by a different system, and you'd hear nothing.

SmartZone systems are designed to be monitored on only one zone at any one time.
 

wm8s

Member
Joined
Oct 30, 2004
Messages
773
Location
Houston, TX
SmartZone systems are designed to be monitored on only one zone at any one time.
I hear folks defend the 500's organization frequently by suggesting to have multiple TSYS objects and other workarounds, but I'm curious how they would manage my situation.

I live in a rural area, with a by-no-means-enormous multiagency, multi-tower statewide trunked system. [Compared to Houston's StarNet, Ohio's MARCs, or AEP's multi-state EDACS system, ours is pretty puny.] The entire system has about 700 TGs on it, of which about half are statewide or regional TGs (regional interop, or statewide state agencies), with the balance more local, and with 3,000 or 4,000 individual subscriber radios now (eventually will grow to many times that), around 600 or 800 or so of which are probably statewide and the balance local.

Also, I am fairly frequently within good range of multiple towers carrying multiple different TGs, with no way to know which TGs will show up on which tower.

It's reasonable of me to want, generally, to:
- always have the radio correctly identify a TG when it comes up
- always have the radio correctly identify a RadioID when it comes up
- listen to more than just one system
- not have to reload V-folders every time I move more than a mile

Off the bat, I obviously can't have this, because having all the RIDs in there will be too many. If I use V-folders geographically and live with not being able to ID a radio that's probably not in my part of the state, I'd could maybe squeeze all of the statewide, regional, and local TGs, and the statewide and local RIDs into the radio at once. But there's no way I would have enough memory to replicate the system's TGs and RIDs into multiple TSYS objects to handle the various control-channel limitations we've seen.

And, of course, if I spend all 1,800 of my "objects" on this system, that gives me nothing left for the dozens-of-sites/hundreds-of-TGs/hundreds-of-radios AEP EDACS system, or any of the other roughly 1,000 conventional freq and trunked system TGs in the area...

Is memory really that expensive?

And the fact that the radio doesn't handle multisite trunked systems natively is a huge limitation. As we've seen, you can "fudge" it to a degree for Moto systems, by packing a bunch of CCs into one TSYS's CC table. But that has its limitations (including the overlapping CCs problem]. And that won't work at all on EDACS systems, where the channels must be in the correct LCN slots. In order for me to listen to AEP's multistate system, I have to have a copy of the TSYS object for each tower, and all of the TGs replicated to each of them. This is pretty ridiculous, and won't work for me, because AEP's system has too many towers and TGs to do this, even if you did spend the time whittling down the replication into geographically limited subsets. [And of course forget about finding space for the hundreds and hundreds of RadioIDs.]

Why can't a talkgroup be assigned to multiple TSYS objects? That seems a simple-enough firmware mod. Whenever the TG was scanned, it would scan each assigned TSYS until it got a hit, play it, and move on.

Funny how I got the 500 because of severe limitations in the 996 (like a 250-TG limit per system; what the heck were they thinking?), only to find out that all of the features on the 996 (like multi-site trunking, and GPS-enabled system selection) are missing from the 500. If I could just put the two in a bag and shake them up... now that would be a scanner!
 

rdale

Completely Banned for the Greater Good
Feed Provider
Joined
Feb 3, 2001
Messages
11,380
Location
Lansing, MI
Sort of a long and technical story, but the bottom line is that your radio could park itself on a control channel in use by a different system, and you'd hear nothing.
Send me the slightly longer but not completely technical explainer then :) How would it pick up a CC from an entirely different system? The only CC's in my ROAM are for MPSCS. They aren't used by any other system at any other location in the state.
 

JoeyC

Senior Member
Joined
Dec 19, 2002
Messages
3,512
Location
San Diego, CA
I hear folks defend the 500's organization frequently by suggesting to have multiple TSYS objects and other workarounds, but I'm curious how they would manage my situation.
Obviously it is impossible to have every talkgroup, radioID and system in an entire state and surrounding areas programmed into a scanner and actually have any success in monitoring and following everything on the system with just one scanner.

How many of those 700 talkgroups do you really listen to?
How many of those 700 actually have traffic on them on a regular basis?
How many of them actually carry traffic that you are interested in?
Does one really need to know the identity of every radio that transmits across a system - especially when it doesn't even give the information 100% of the time?
How many simultaneous conversations can you expect to follow with 700 talkgroups programmed? Even if only 5 of the talkgroups have a conversation on them at one time it might take minutes to return to the first one anyway and you will have missed a good portion anyway.

It is nearly impossible to accomplish your situation as you present it all in one memory nor would the radio be able to keep up with listening to everything anyway.

If I were you I'd be the least concerned with programming the RadioIDs or I would break down the talkgroups region-wide and have separate v-scanner folders for the regions.
 

RKG

Member
Joined
May 23, 2005
Messages
1,094
Location
Boston, MA
Send me the slightly longer but not completely technical explainer then :) How would it pick up a CC from an entirely different system? The only CC's in my ROAM are for MPSCS. They aren't used by any other system at any other location in the state.
Your lucky.

Next, let's get out on the table the meaning of trunked "system", or rather, some confusion about this term.

A trunked system is a unique combination of a SysID and one or more control channels, only one of which is active at any one time. The simplest form of this is a single-site SmartNet "system." However, also included is a multi-site SmartNet simulcast system.

Now let's deal with SmartZone. SmartZone is a way of connecting, for control and selected audio purposes, two or more "zones," where now a "zone" means a unique combination of SysID and single active control channel. Each zone acts independently, within its coverage area. However, sometimes a zone will carry traffic that originates on a different zone, depending on the affiliation of "roamers."

Let me illustrate by an example, which will be simplified a bit: the Massachusetts State Police system (which is also used by other state and local agencies). Originally, it consisted of four independent SmartNet "systems." Each had the same SysID, but each had separate control channels. Subscriber units could monitor only one "system" at a time. If you moved from the territory covered by one to that covered by another, you had to manually switch in your radio.

What SmartZone does for you is two things. First, in theory, it will handle the switching for you automatically. It does this by applying a very complicated, and system-specific, set of parameters based on signal strength, BER and a couple of other factors, all of which are designed specifically for this system and tweaked a bit based on experience. Unless your radio has the same values as everyone else on the system, SmartZone auto switching won't be reliable.

Regardless, a SmartZone mobile or portable only listens to only one "zone" ("system") -- and only one control channel -- at a time.

Now, talkgroups on a SmartZone system come in three flavors. A "statewide" TG will be repeated on all of the "zones", regardless of the "zone" on which the channel grant was initiated. These are resource intensive and there are only two on our Massachusetts system.

A "home only" TG will only be recognized on one "zone." If you pass out of that "zone" to another "zone" while selected on a home only TG, and then try to get a channel grant, you will get an error boop.

Finally, a SmartZoned TG is like a "home only" TG except that it will also be carried on another system if a user happens to be affiliated on that other system and selected on that talkgroup, and only as long as this condition exists. If you're selected on a SmartZoned TG and you re-affiliate to a non-home "zone," you're radio will so advise the controller and temporarily bring traffic on that TG into the non-home zone (until you go back home again).

Back to our simplified example. Let us call the four "zones" A Troop, B Troop, C Troop and D Troop. In each "zone" we will have 3 "patrol" TGs. All of these are "home only" except that A PTL 1 is SmartZoned in C Troop (because the jurisdiction the A PTL 1 cruisers is right next to C Troop).

If you are listening to the C Troop "zone" (i.e., the C Troop SysID and C Troop control channel) you will hear all traffic on C PTL 1, 2 and 3. You will not hear anything on any D Troop TG. You will not hear anything on A PTL 2 or 3, and you will not hear anything on A PTL 1 unless an A Trooper's radio has switched affiliation from the A Troop control channel to the C Troop control channel because the A Trooper is near the line and his radio hears the C Troop control channel better than the A Troop control channel.

(Before any Massachusetts people chime in with all of the exceptions to what I've just stated, let me reiterate: this is a simplified description, for illustrative purposes.)

What do you do if you want to hear A Troop stuff and C Troop stuff, and you're on a high enough hill that you can hear both control channels? Use two radios. Or program one radio with two separate "systems" and scan both. However, if you do that, remember that the radio can only listen to one control channel at a time, so it will act as if it were two radios, with only one turned on at a time. If the radio is listening to A Troop's control channel, you won't hear any traffic on the C Troop system.

The PSR-500 and -600 attempt to duplicate the SmartZone feature, in a simplified way. GRE made no attempt to emulate all of the SmartZone parameters, in part I suspect because of complexity and memory limitations, but probably also because, unless you're an authorized user of the system, you will have no access to the engineered values, and with the "wrong" values, the radio will function in an unpredictable way. Rather, the PSR radios attempt to determine all receivable control channels from the list, and then park on the strongest of them as long as the strongest doesn't dip below a value that you can set via WIN500. This is a valiant effort. In real life, though, because of the high variability in derived signal strength from a portable, they tend to jump around. Given that most TGs are "home only" (since SmartZone and Statewide TGs are terribly consumptive of system resources), you don't know what you'll hear.

Remember, no radio can listen to more than one control channel at a time.

Ergo, the way to maximize what you're going to hear is to program each "zone" as a separate TSYS. You can program all of the TGs in the whole state for each if you please (plenty of memory in most cases and by using the copy feature, you only have to type them once), but doing so is a waste because, remember, most TGs are "home only" to only one "zone." Assign each TSYS to its own scan list. Then, based on your knowledge of how the system is laid out and where you are, select the system appropriate for your location (by selecting the scan list for that TSYS). You'll hear as much as can be heard.

Now, if you like (and don't want to take my advice), you can activate two or more scan lists. However, your radio can only listen to one control channel at a time, so what you'll hear is a bit unpredictable.

Sorry; too long an answer, and I'm not sure how much I've helped. This is not a simple subject, and folks spend years learning the intracacies of SmartNet/SmartZone trunking.
 
Last edited:

kevins669

Member
Database Admin
Joined
Dec 19, 2002
Messages
418
Location
New Orleans, LA
I hear folks defend the 500's organization frequently by suggesting to have multiple TSYS objects and other workarounds, but I'm curious how they would manage my situation.
Without hijacking...

I also have a "problem" with being forced to use v-scanner. A big driving force for my interest is identifying unknown talkgroups. In order for the PSR-500 to properly assist me in doing this, the known talkgroups must be in the loaded profile already, and instructed to ignore them on a wildcard, allowing me to only hear unidentified groups when scanning a wildcard on that system. I am way over the 1800 objects already (only have this system in the radio). I wish there were a way for GRE to let us use all that memory at once. Who knows... they keep impressing me. (maybe some more tweaks for CQPSK, too :) )


-- Kevin
 

RKG

Member
Joined
May 23, 2005
Messages
1,094
Location
Boston, MA
Send me the slightly longer but not completely technical explainer then :) How would it pick up a CC from an entirely different system? The only CC's in my ROAM are for MPSCS. They aren't used by any other system at any other location in the state.
See above.
 
Last edited:

kevins669

Member
Database Admin
Joined
Dec 19, 2002
Messages
418
Location
New Orleans, LA
How many of those 700 talkgroups do you really listen to?
For me, see my previous post...

I personally have 90% of my "full" radio not even scanned, they are just there to let the radio find the groups that aren't.

You are right, for those who only like to listen, and those hundreds of groups are divided among agencies in different geographical areas, the v-scanners should be ok.

For my purposes, more flexibility in the memory would be ideal.


-- Kevin
 

RKG

Member
Joined
May 23, 2005
Messages
1,094
Location
Boston, MA
A far more effective (and far easier) way to "farm" active talkgroups on a system is to use something like "Trunker." Tune a control channel and let the system run for 24 hours. At the end, you'll have a list of all of the TGs active on the system during that time, with a hit counter.
 

kevins669

Member
Database Admin
Joined
Dec 19, 2002
Messages
418
Location
New Orleans, LA
A far more effective (and far easier) way to "farm" active talkgroups on a system is to use something like "Trunker." Tune a control channel and let the system run for 24 hours. At the end, you'll have a list of all of the TGs active on the system during that time, with a hit counter.
While you are correct, there are some problems with that... I do have a PSR-500 running multiple applications at home, and one with me during the day.

If the radio let the user make use of the complete memory, that would not be needed. CC decoders do not let me hear the audio. Win500 does record, and give information for the recording as well, but I would have to listen to it all at a later time. There are many, many ways of looking at other pieces of data at the time the TG is active on the system, and a CC decode program does not afford me those same opportunities after the fact.

And think about this... why would I spend $500 + on the scanner to send some data out of it into a FREE program just to have a log? Seems like some of that money would be due Mike, Rick, and others.

The radio should let us store more... GRE should have been more forward-thinking on this, as many states are implementing statewide systems; for others who are average-joe hobbyists, v-scanners get to be a headache. Being able to organize all the info in one master profile would be better for them, too.

Just my opinion, though!

-- Kevin
 

JoeyC

Senior Member
Joined
Dec 19, 2002
Messages
3,512
Location
San Diego, CA
If the radio let the user make use of the complete memory, -- Kevin
The radio does make use of the complete memory. V-Scanners aren't memory and can't be turned into memory. This is the same misconception people have with their computers. RAM and Hard Disk space are two different animals. This is the same idea as working scanner memory and V-Scanner storage.
 

kevins669

Member
Database Admin
Joined
Dec 19, 2002
Messages
418
Location
New Orleans, LA
The radio does make use of the complete memory. V-Scanners aren't memory and can't be turned into memory. This is the same misconception people have with their computers. RAM and Hard Disk space are two different animals. This is the same idea as working scanner memory and V-Scanner storage.
I know what you are saying, but my reasoning is, why even bother with v-scanners? Why not just incorporate more memory to begin with?

Cost can't be an issue... have you seen how much a 1G MicroSD goes for? That would be way cool.

-- Kevin
 

rdale

Completely Banned for the Greater Good
Feed Provider
Joined
Feb 3, 2001
Messages
11,380
Location
Lansing, MI
RKG - I understand your post, as that's how statewide smartzone systems have worked for ages, but I don't understand how you explained that the radio will scan a completely different SYSTEM as you note above. How would it scan a control channel from a different SYSTEM? I've NEVER had that happen since day 1 with this (or any other) scanner...
 
Status
Not open for further replies.
Top