PSR-500/600 new feature idea

[Patch42]

I was involved in a discussion in another forum comparing features of different scanners. In thinking of how I might accomplish certain things with the PSR-500, a new feature came to mind.

The idea is to allow an intermediate construct I'll call 'collections'. Collections would be scannable objects composed of lists of other scannable objects. As scannable objects, collections could be members of scan lists. It would be nice to allow collections to contain other collections, but this could lead to infinite recursion without proper checks when adding something to a collection. Probably best to limit collection members to being scannable objects other than collections.

This is primarily an organizational amenity, though there could be quite a bit of utility in being able to lock out collections.

There are any number of interesting possibilities that come up if collections are available. I live in the Orlando area where there are soon to be two major pubic service trunking systems servicing the city of Orlando, the county of Orange, and several additional municipalities in the area. Say I create collections for Orlando PD, Orlando FD, County Sheriff, County fire, city A PD, city A FD, etc. Now I can easily create scan lists for everything Orlando, everything county, everything city A, etc., plus have orthogonal scan lists for all police, all fire, all dog catchers, etc. So far this is nothing I couldn't already do. The big difference is that by locking out just a few collections I can quickly narrow these lists down to just Orlando PD or just county fire.

One example from the other forum was of a large industrial building fire. You might know from experience that the fire ground talk groups are often used in pairs. You create a collection composed of fire dispatch, fire command 1, and fire ground 1 and 2. You create another collection composed of fire dispatch, fire command 2, and fire ground 3 and 4. If a large building fire occurs you can quickly focus on just one of these collections and hear all the talk groups that will be concerned with this fire.

The basic idea is to provide an intermediate level of organization and also allow rapid reconfiguration for a specific incident you want to follow.

[rdale]

You can do that already... If you have Orlando PD as SL1 and Orlando FD as SL2, you can have SL3 _also_ be Orlando FIre Dispatch, FC1, FG1 and 2. Then at an incident you turn off SL1 and 2 and just select SL3.

[Patch42]

Originally Posted by rdale

You can do that already... If you have Orlando PD as SL1 and Orlando FD as SL2, you can have SL3 _also_ be Orlando FIre Dispatch, FC1, FG1 and 2. Then at an incident you turn off SL1 and 2 and just select SL3.

True, but now you've used one of only 20 available scan lists for something you're likely to use somewhat rarely.

The whole issue came up when someone suggested the 20 scan lists on the PSR-500/600 were not close to sufficient for his scanning needs. You can go read the X vs Y vs Z thread in the General Scanning forum if you want to see all the details, but the scanner he preferred had a vastly greater scan list capacity compared with the PSR-500/600. It had something similar to the collection idea I've suggested here that aided in quickly zeroing in on the groups of immediate interest.

[rdale]

I see what you're saying... Another thing to remember is that it's VERY quick and easy to set up the favorites list with the same thing on the fly, and clear it out when unneeded.

[Patch42]

The favorites list was my first thought too. It does come close.

Where collections would be superior is with being able to pre-configure in a logical manner, being sure you include all the relevant TGs and frequencies, and not having to remember on the spot or find the active channels spontaneously. Like maybe you know that SWAT1 is always used in police sectors 1, 2, and 3, so you put all those in one collection that can be quickly activated if there's SWAT activity in one of those sectors. Or you know that cross-jurisdictional car chases will be on a different frequency in each surrounding county and possibly on a statewide frequency, so you make all those a collection.

[mancow]

Great idea and you probably just made some GRE designer employee of next year.

It really is surprising that they didn't design in more layers. I was kind of disappointed when I realized that in the end it's really just a 20 bank setup.

[captaincraig44]

Originally Posted by mancow

It really is surprising that they didn't design in more layers. I was kind of disappointed when I realized that in the end it's really just a 20 bank setup.

They've got to have something new to justify the price when the 700/800 come out!

[BigJimbo]

So glad to see I wasnt the only one lamenting over the 20 list issue with the 500. I've had my 500 since Easter and after I got the learning curve under my belt it was time to do the biggest job......"getting it all set up."

I spend a lot of time considering how to arrange everything so I can navigate on the fly when something gets going in my area.

The one thing I noticed right away was the 500's lack of what I've been calling "scanning selectivity." My 3 year old BCD396T has it beat hands down. I dont want to enrage all of the 500 owners on here, I know it's a loved radio......and I wouldnt give mine back, I like it too. (my kids go bonkers over the LED)

I am disappointed that there is no intermediate step between the scan lists and objects. One thing I realized is that many 500/old Pro-96 owners may have never had a Uniden with DMA to know what we are talking about.

Im doing the best I can with the 20 lists.

[kikito]

Originally Posted by BigJimbo

So glad to see I wasnt the only one lamenting over the 20 list issue with the 500. I am disappointed that there is no intermediate step between the scan lists and objects. One thing I realized is that many 500/old Pro-96 owners may have never had a Uniden with DMA to know what we are talking about.

Im doing the best I can with the 20 lists.

I've had just about every Uniden and GRE scanner in the last decade and the only thing to "lament" is that the Unidens are still stuck with only 200 TGs per system.

And the Unidens still only have 20 groups also, within a system. True, you can make more systems and have 20 more groups but depending on how you set it up, you're still limited to 20 groups on the Uniden, along with a worse "trade-off" of only 200 TGs per system and a lot of more wasted memory having to duplicate for ever. Our statewide system alone takes 40% of the memory to setup in my BCD396T.

So as usual, depending on how "picky" people are about setting up what they listen to in a scanner, it'll depend on what memory scheme is more inneficient and convoluted. I personally think some people don't need to get so "surgical" or "anal" about having everything so absolutely and neatly divided or segregated, but that's just me.

[mancow]

Yep, that's just you.

As for me, I tend to listen to numerous smaller systems of different types. There's everything from P-25 to LTR in mine. I live in an area where I can pick up several larger metro areas around me and some of those have multiple layers of suburban cities with their own system. The 396 / 996 allow for all of those smaller systems to be called up easily at will. Therefore, I have a need for more sytems and less of a need for a large talk group capacity.

I guess we'll never be happy and that's really what keeps us drawn to it all anyway.

[kikito]

Originally Posted by mancow

There's everything from P-25 to LTR in mine.

In my area too there's quite a mix of systems and things to monitor.

With a combination of things like Temporary lockouts and other features not available in the Unidens, the *22* scanlists in the PSR-500/600 goes a long ways....

[wnjl]

Originally Posted by kikito

In my area too there's quite a mix of systems and things to monitor.

With a combination of things like Temporary lockouts and other features not available in the Unidens, the *22* scanlists in the PSR-500/600 goes a long ways....

I agree...now like the other poster suggested, I have never used a Uniden scanner with DMA, so maybe if I was used to that, I'd find this setup limiting. But as it is now where I live in New Jersey, in between Philly and Trenton with oodles of counties and systems to monitor, I have had no problem managing at all with the 500's scanlists.

[Patch42]

Lest we forget, the objective here was not to start a fight about which model is better. The point was to suggest a new feature that would make the 500/600 even better.

With some systems having hundreds of talk groups, I think it only makes sense for there to be some additional way to help organize them.

[n4jri]

I've always wanted more lists as well. One thing that's helping me is the option of turning systems on and off by locking/unlocking the TSYS. Admittedly, it's no help with conventional systems, but I also keep of couple of different V-scanners for my home area to help match my moods.

73/Allen (N4JRI)

[Curfew]

Talkgroup limit search for isolating certain talkgroup numerical groupings, ie. 16000-17000, 50000- 51500 etc.

Take this and apply it to scanned control channels to find certain talkgroups in use in one system or several.

Some way at identifying patches to a system/s ie. a conventional channel patched to a trunked system, or a trunked system patched to a conventional-without using a computer to see them, it's user selectable to see on the display as a "show CC info" or the like. It automatically shows you the system frequencies patched, the talkgroups patched together, or both.

[DaveIN]

Originally Posted by Curfew

Talkgroup limit search for isolating certain talkgroup numerical groupings, ie. 16000-17000, 50000- 51500 etc.

While I like this idea, I don't think it's possible because it would use additional objects in the memory management system and take away from the scanlists.

[Patch42]

Originally Posted by DaveIN

While I like this idea, I don't think it's possible because it would use additional objects in the memory management system and take away from the scanlists.

I don't know the size of a standard object record in the database, but since the existing limit search objects already have a high and low frequency, it doesn't seem that switching that to a high and low talk group would require any additional space. It would probably need less. The only other thing you'd need is the object number of the related TSYS, and I don't think that requires much space. I don't believe a talkgroup range search object would need to be any bigger than any other existing search object.