Assigning objects to multiple 'banks'...

[b52hbuff]

But let's not forget that the Uniden BCD396T still ONLY allows 20 groups per system. And you only get 10 quick-keys for those 20 groups. For many people and depending how you arrange stuff, you are still limited to subdivide a system in only 10 unique ways. Or you can lump everything into a System but only up to 200 TGs and what would be the point of having all those quick-keys. So you still have to duplicate and/or consolidate, one way or another. You have to duplicate for sure if you want to monitor more than one site at a time. So the PSR-500 with only 20+2 scanlists works more efficient for me and others.

Is your bold comment a typo? I think you mean that it has only 200TGIDs per system.

Otherwise, I don't understand. The 396 has 100 Quick keys. You can assign as many systems to a key. Within each system, you have ten group quick keys to further subdivide the list.

I agree that the multi-site feature is currently better on the GRE. But I don't have any of those in Northern California.

I think if Uniden took their multisite feature on the 996 and increased the limit on TGIDs, then it would be more competitive with the GRE.

 

[DonS]

I agree that the multi-site feature is currently better on the GRE. But I don't have any of those in Northern California.

Sure you do. Within monitoring distance of Los Altos (with a halfway decent antenna, that is), are at least two:
http://www.radioreference.com/modules.php?name=RR&sid=1138 and http://www.radioreference.com/modules.php?name=RR&sid=1316

I'm monitoring both of those from Santa Clara (though I currently only have one site programmed for each).

 

[kikito]

I have a feeling that we'll see more scanlists in future models. I'd like to have 10 or 20 more that I could set up like custom service searches.

What I do now is set up the custom service searches and assign them to a scanlist and keep them locked until I need them or attach them to another scanlist I'm actively using when I want to scan them. Other searches I just leave Unassigned and do the above when needed.

Either way, I wouldn't mind at least a few more scanlists myself....

 

[DonS]

I think I saw it mentioned before, but it might bear repeating...

One way to simulate lots of "scan lists" (or "systems") would be to create duplicate TSYS objects, with small sets of TGRPs in each, but leave the TSYS objects locked out. You could have 10 different copies of the same TSYS, each with just a few TGRPs. The sequence MAN # # # ENT L/OUT (where # # # is the Object ID of the target TSYS) would toggle a TSYS's lockout status. Even with only 20 actual Scan Lists, you could create hundreds of different "scanning combinations", without a lot of key presses to enable/disable individual sets of TGRPs.

EDIT:...

For example, I could create 3 different versions of my local Santa Clara City TSYS. They would all have the same values in the TSYS menu, but I might name them differently. I might put them in Object IDs 100 through 102. In 100, I'd add all of the TGRP objects I might want to ever monitor, except... in 101 I might put just Police, while 102 would have just Fire. The TGRPs in all 3 could all be in the same (single) Scan List. Without changing scan list membership, I could turn off Fire by pressing MAN 1 0 2 ENT L/OUT SCAN.

If I was monitoring all three (all three TSYSs not locked out, running in SCAN mode), and something "big" started happening on the Fire talkgroups, I could focus on Fire by pressing MAN 100 ENT L/OUT 101 ENT L/OUT SCAN.

I think the fact that we can enable/disable an entire TSYS (along with its associated TGRPs) largely mitigates the fact that we only have 20 "actual" scan lists.

 

[kikito]

But let's not forget that the Uniden BCD396T still ONLY allows 20 groups per system. And you only get 10 quick-keys for those 20 groups.

Is your bold comment a typo? I think you mean that it has only 200TGIDs per system.

Otherwise, I don't understand. The 396 has 100 Quick keys. You can assign as many systems to a key. Within each system, you have ten group quick keys to further subdivide the list.

Nope, not a typo.

The BCD396T does have 100 System quick-keys and each system has 10 Group quick-keys. That would make a total of 1,000 unique quick-keys.

However, each System only allows you to split talkgroups in up to 20 Groups. Those 20 Groups have up to 10 quick-keys to share. Yes, you can assign many systems (up to 400 total) to the same quick-key if desired. But that does nothing about the limitation of having to duplicate each system's talkgroups and having only 10 unique quick-keys per System. Page 125 of the manual also confirms the 20 group limit per system. It was at that time I started consolidating stuff. And now with the PSR-500, I consolidated even more again. Each time without much problem or inconvenience.

Is that better or worse as far as explanations go?

P.S. The PSR-500 also allows you to assign as many systems as you want to a single scanlist.

 

[DonS]

P.S. The PSR-500 also allows you to assign as many systems as you want to a single scanlist.

Technically, no it doesn't. TSYS objects are not associated with scan lists.

TGRP objects are associated with zero or one TSYS objects. TGRP objects are members of zero or more (up to 22, if we include FAV and SkyWarn) scan lists.

 

[scanfan03]

Hey, that's exactly how I'm using mine too!


The Multi-Site feature is great. I use STAT on our P25 system, ROAM on a Mot 2 and leave it OFF on a Mot Hybrid. It tracks them flawlessly and as expected. The other great trunking feature is the LTR AutoMove. It also works great.

I couldn't get the AutoMove feature to work unless I was monitoring a Wildcard TG. I stopped using it because I don't ever scan a system in open mode (or ID search). One thing I hate is how hard it is to put a system in open mode. I know I can put a wildcard in and then scroll to it while keeping it locked out. But that takes up more memory and takes more time compared to other scanners.

 

[DonS]

I couldn't get the AutoMove feature to work unless I was monitoring a Wildcard TG. I stopped using it because I don't ever scan a system in open mode (or ID search). One thing I hate is how hard it is to put a system in open mode. I know I can put a wildcard in and then scroll to it while keeping it locked out. But that takes up more memory and takes more time compared to other scanners.

It seems to work fine here. I "scrambled" the 20 TSYS frequencies for the only LTR system I can really hear here, uploaded to the radio, and it's rearranging them as it receives transmissions.

EDIT: I can see in the CCDump output text like "LTR:T0258:17: 0-18-18-109-10:wrong HR-swapped-updated:Call:TGID-0-18-109 VC- 490.062500"

EDIT2: The above CCDump text means: "We got a message on LTR TSYS 0258 (decimal 600). We were on freq #17, but we heard a message that could only be on HR #18. The message was heard on the wrong HR #, so we swapped 17 and 18 and updated the TSYS."

 

[b52hbuff]

Nope, not a typo.

Is that better or worse as far as explanations go?

Thanks for the clarifications. Since I so infrequently use extra 'sub' groups (e.g. more than the 10 limit of sub group keys.), I forgot that you have had 20 sub groups. I think they are such a pain to configure w/o a sub-group key, I didn't bother.

 

[b52hbuff]

Sure you do. Within monitoring distance of Los Altos (with a halfway decent antenna, that is), are at least two:
http://www.radioreference.com/modules.php?name=RR&sid=1138 and http://www.radioreference.com/modules.php?name=RR&sid=1316

I'm monitoring both of those from Santa Clara (though I currently only have one site programmed for each).

Once again you are correct.

I don't listen to Marin.

I do have San Mateo County programmed in, but as Wayne educated me, despite the number of sites shown, all you need to program in is north and south systems. In the SMC case, there are much less than 200TGIDs, and duplicating these between the two systems wasn't too bad.

I agree if we had a system like the San Diego RCS, with hundreds of TGIDs, (like the Alaska system), then I'd be more inclined towards GRE's memory layout. I also agree that Uniden's implementation of multi-site trunking in the 996 still has a serious shortcoming with 250 TGIDs.

btw, in one of the Uniden forums, there was a big discussion about how much work a radio would need to do to be able to do a TGID lookup in the amount of time you have in the control channel data stream and still be able to tune/mute/unmute the audio depending on the radios programming.

How did this limitation get overcome in the GRE? If you have many hundreds of TGIDs programmed for a TSYS, how does the radio have enough time to decode and search the list? Caching? Improved search? Or could this contribute to missing calls?

 

[DonS]

btw, in one of the Uniden forums, there was a big discussion about how much work a radio would need to do to be able to do a TGID lookup in the amount of time you have in the control channel data stream and still be able to tune/mute/unmute the audio depending on the radios programming.

How did this limitation get overcome in the GRE? If you have many hundreds of TGIDs programmed for a TSYS, how does the radio have enough time to decode and search the list? Caching? Improved search? Or could this contribute to missing calls?

I don't see why it should take more than a few milliseconds, even with a scanner's "not so powerful" processor, to look through a list of several hundred, or even several thousand, TGIDs. The time it takes to look through such a list should be insignificant when compared to the time between CC messages. When I saw that discussion in the Uniden forums, I was somewhat flabbergasted that "time" was described as the reason behind limiting the number of TGIDs per trunking system.

 

[kikito]

Technically, no it doesn't. TSYS objects are not associated with scan lists.

Technically that's true and technically that's what I meant.

I guess I'm still stuck with the system concept when referring to scannable objects like in this case.

 

[kikito]

I couldn't get the AutoMove feature to work unless I was monitoring a Wildcard TG. I stopped using it because I don't ever scan a system in open mode (or ID search).

Just like Don, I also tested the feature by scrambling the frequencies and the scanner re-arranges them within a couple of minutes. It'll be interesting to find out what could be happening with the system you're monitoring because it works for me too.

One thing I hate is how hard it is to put a system in open mode. I know I can put a wildcard in and then scroll to it while keeping it locked out. But that takes up more memory and takes more time compared to other scanners.

The way I do it is by keeping all my Wildcards in one scanlist. I usually just scan them along with everything else most of the time. When I want to go to one of them specifically, I hit MAN then scroll quickly between scanlists by using the side arrows to get to my Wildcard scanlist and then scroll with the up/down arrows to find the specific one.

For me it's actually quicker and more versatile the way "open" mode is in this scanner. When I want to strictly search for new TGs, I just disable all the scanlists and leave only the Wildcard scanlist in Scan mode. That way it wont stop on the stuff I already have programmed but disabled.

 

[scanfan03]

Just like Don, I also tested the feature by scrambling the frequencies and the scanner re-arranges them within a couple of minutes. It'll be interesting to find out what could be happening with the system you're monitoring because it works for me too.



The way I do it is by keeping all my Wildcards in one scanlist. I usually just scan them along with everything else most of the time. When I want to go to one of them specifically, I hit MAN then scroll quickly between scanlists by using the side arrows to get to my Wildcard scanlist and then scroll with the up/down arrows to find the specific one.

For me it's actually quicker and more versatile the way "open" mode is in this scanner. When I want to strictly search for new TGs, I just disable all the scanlists and leave only the Wildcard scanlist in Scan mode. That way it wont stop on the stuff I already have programmed but disabled.

You've given me a very good idea. I could just put the wildcards in the NS list.

Anyways: Don did you see my post about how the PSR-500 won't track TGid 0-08-008 on a local LTR system here. Specifically this one: http://www.radioreference.com/modules.php?name=RR&sid=3296. I ended up putting all frequencies in the right LCNs (I think this problem might have something to do with the LTR home repeater function problem).

 

[kikito]

btw, in one of the Uniden forums, there was a big discussion about how much work a radio would need to do to be able to do a TGID lookup in the amount of time you have in the control channel data stream and still be able to tune/mute/unmute the audio depending on the radios programming.

How did this limitation get overcome in the GRE? If you have many hundreds of TGIDs programmed for a TSYS, how does the radio have enough time to decode and search the list? Caching? Improved search? Or could this contribute to missing calls?

I'll go out on a limb on this subject for the benefit of everyone, even me, hopefully.

I thought the way it was done was the scanner examines the control channel data stream to see what's active. When it sees a talkgroup active, it checks the programmed stuff to see if it's already there in order to display it's alpha-tag and if it's locked out and other attributes you might've given to a particular talkgroup i.e. Flash LED, Audio alert, etc. And it does that comparison in few milliseconds.

So in other words, the time delay and/or "CPU power" needed to monitor several hundred or even a thousand talkgroups should be measured in relation to how quickly the scanner can compare what's currently active in the control channel stream with what you have programmed and NOT from a standpoint that the scanner is going through the whole list of each programmed talkgroup like it does for conventional frequencies to see if any of them are active.

Am I completely off on that? Or can anybody elaborate on what actually takes place when scanning a trunked system, especially related to the PSR-500.

 

[b52hbuff]

I don't see why it should take more than a few milliseconds, even with a scanner's "not so powerful" processor, to look through a list of several hundred, or even several thousand, TGIDs. The time it takes to look through such a list should be insignificant when compared to the time between CC messages. When I saw that discussion in the Uniden forums, I was somewhat flabbergasted that "time" was described as the reason behind limiting the number of TGIDs per trunking system.

But the time gate isn't from message to message is it? It's from message to the start of the voice. If the scanner kept unmuting squelch in the middle of a conversation, it'd get annoying very quickly.

 

[DonS]

But the time gate isn't from message to message is it? It's from message to the start of the voice. If the scanner kept unmuting squelch in the middle of a conversation, it'd get annoying very quickly.

I'm not sure I understand.

You've programmed a TSYS along with some TGRPs you want to monitor. You hit "SCAN". The radio finds the CC and starts monitoring it. A "message" containing a TGID appears on the CC. The radio looks through your list of programmed TGRPs to see if that TGID is interesting. If it isn't, the radio continues monitoring the CC. If it is, the radio determines the VC frequency, tunes, and unmutes audio.

If, when the radio saw the interesting TGID in the CC's data, the conversation was already in progress (i.e. it was some sort of "update" message), you'd start monitoring in the middle of the conversation. If the message was an initial "grant", then you'd start monitoring at the beginning of the conversation.

AFAIK, every trunking scanner works this way.

The question, as I read it, was whether looking through a large list of TGRPs should/could impact "speed". I don't believe it should. From the time the message appears on the CC until the radio tunes to the VC shouldn't be more than a few milliseconds. Acquiring SQ on the VC and unmuting might take a little more time, but it shouldn't be enough to result in any perceived "delays".