Maximum Talk Groups & Group Quick Keys

bc780l · #1 (**permalink**) 11-17-2006, 10:40 AM

Any recommendations on best way (other than pure duplication of systems) to get around the 396/996 maximum number of talk groups per system--as well as group quick key assignments? If, hypothetically, I wanted to program ALL of the talk groups for a large statewide system, I'd ALSO have the problem of not being able to assign an adequate number of group quick keys to realistically be able to manage what was monitored at any one time on that system. Perhaps the recommendation is for Uniden to remove the limitations (they do, after all, have dynamic memory allocation--why can't that be applied to these variables, too?) of maximum "channels" per system and group quick key assignments (for that matter, system quick keys, too)?? Thoughts?

DaveIN · #2 (**permalink**) 11-18-2006, 11:32 PM

I would be great to have unlimited numbers for systems groups and talkgroups, but it would slow things down to a crawl when scanning in the current models. If you want all the talkgroups of a large system or statewide system, you will need multiple copies of the system with the different talkgroups. I'd suggest just systems with the talkgroups that you are most interested in.

bc780l · #3 (**permalink**) 11-19-2006, 11:32 AM

Yes, it would indeed be a crawl IF all groups were active, no doubt. With only the "groups of interest" active, there should be no slowdown. Scan rates are scan rates with all the incumbent limitations. But, in the case of someone who is interested in keeping administrative oversight of a system, it would be great to have all groups in one receiver ... and in a manageable format. (Granted, one in such a role would have much more sophisticated tools at hand, but it would nevertheless be nice to have a cheaper alternative.) I prefer to think of the methods how to do it rather than why not to do it. The current radios just don't take that into consideration, but I'd think with a little tweak they could. Memory is cheap. It's a simple matter of programming for, perhaps, the next release. For now, it's duplicative programming to get the equivalent which could be handled more elegantly with use of that memory.

edweirdFL · #4 (**permalink**) 11-19-2006, 12:09 PM

For EDACS and LTR systems you can use the wildcarding feature, entering the partial AFS info, but you lose the ability to see the specific talk group ID.

Ed

DaveIN · #5 (**permalink**) 11-19-2006, 12:59 PM

I still think the Secure Disk slot option is a good idea. Then we could swap systems, groups, and channels as needed, even between handy and mobile. You could have the whole Radioreference database available on a single SD.

bc780l · #6 (**permalink**) 12-01-2006, 03:48 PM

Removable memory is a good idea. Regardless of the amount of memory, with new state-wide systems, however, it becomes more important to administrative/techs/travellers who want a full state-wide system accessible in the scanner, to have more group quick keys available within the system. Along with this should no limitation on number of talkgroups within a system. Two recent examples which could benefit from this are Michigan and North Carolina. To monitor these systems completely is far beyond the capabilities of the current 396/996 scanners due to nasty little artificial variable limitations which should, ideally, be a simple matter of reprogramming the scanner operating system (and incumbent programming software). I'm just hoping that Uniden thinks about such enhanced system management for the next firmware/hardware/software release(s).

jonny290 · #7 (**permalink**) 12-01-2006, 05:24 PM

number of talkgroups programmed should be a non-factor if you are in ID SCAN mode. It just sits on the control channel and waits for an appropriate TGID; i doubt that it's really slow on the pickup (since it gets the tgid off the air, it can do a very fast matchup to the programmed TGID)

That being said, I recommend programming a system for each general area, and subdividing it that way. 99 quick keys for system on/off, use 'em up

DaveIN · #8 (**permalink**) 12-01-2006, 05:56 PM

Quote:

Originally Posted by jonny290

number of talkgroups programmed should be a non-factor if you are in ID SCAN mode. It just sits on the control channel and waits for an appropriate TGID; i doubt that it's really slow on the pickup (since it gets the tgid off the air, it can do a very fast matchup to the programmed TGID)

That being said, I recommend programming a system for each general area, and subdividing it that way. 99 quick keys for system on/off, use 'em up

Number of talkgroups, that may be true, but attach alpha-tags, to each one and it becoms a memory problem.

UPMan · #9 (**permalink**) 12-01-2006, 06:17 PM

Alpha tags don't affect the total memory availability on the 396 or 996 (only the BC246T and SC230). Other design considerations limit the total number of TG channels possible in a trunking system.

DaveIN · #10 (**permalink**) 12-02-2006, 11:08 AM

I'm amazed at the current dynamic memory ability on the 996 (and the other models). Uniden has come a long way in a short time. I think I have the math right. There is enough memory for 250 talkgroups with 16 alpha characters (4,000 possible alpha characters). Now lets add about 1700 talkgroups? How long would it take to lookup all those *possible* talkgroups and display them without slowing down the ability to Trunktrack?

Example: If I want to travel through Indiana and monitor the statewide SAFE-T system and see the alpha tags for any system I may come in contact with, I would need to create 7 sets of talkgroups (that's 27,200 possible alpha characters). I know I'll never see all of the talkgroups, but if I travel around the state I may see many of them, and would want to know what the talkgroups is when I hear it. The 996 will allow us to put all the trunked sites in one system, but not all the talkgroup possibilities. Add another 1500 talkgroups for Michigan MPSCS, and then another 1300 for Ohio MARCS.

The only way to cover all the possible talkgroup combinations would be to stop and use programming software to upload another set to the radio memory. You would also need to have the Radioreference database available, or previously setup system files for all occasions. I'd like to have another storage method to do this, or at least have on board memory, speed, and configuration to be able to handle a statewide system and all the possible county/city combinations for conventional and trunked.

jastx · #11 (**permalink**) 12-02-2006, 04:09 PM

Quote:

Originally Posted by UPMan

...Other design considerations limit the total number of TG channels possible in a trunking system.

I wonder what they are. Lookup speed shouldn't be a problem, unless a linear search of all talkgroups; instead of a hashtable, binary search or other technique; is being used to determine if the scanner should stop on a particular talk group.

slicerwizard · #12 (**permalink**) 12-03-2006, 09:23 AM

Quote:

Originally Posted by DaveIN

I'm amazed at the current dynamic memory ability on the 996 (and the other models). Uniden has come a long way in a short time. I think I have the math right. There is enough memory for 250 talkgroups with 16 alpha characters (4,000 possible alpha characters). Now lets add about 1700 talkgroups? How long would it take to lookup all those *possible* talkgroups and display them without slowing down the ability to Trunktrack?

Uh, with a binary search of a sorted list, less than 15 simple tests. Oops, make that less than 11. Maybe a millisecond. Probably much less.

How many entries are there in a large phone book? Maybe a million or more? How long does it take you to find the one entry in those million+ that you're looking for? Maybe 15 seconds tops, unless you're having a really bad day? There's really nothing amazing about that.

slicerwizard · #13 (**permalink**) 12-03-2006, 09:41 AM

Quote:

Originally Posted by jastx

I wonder what they are. Lookup speed shouldn't be a problem, unless a linear search of all talkgroups; instead of a hashtable, binary search or other technique; is being used to determine if the scanner should stop on a particular talk group.

They are undoubtedly doing linear searches and not bothering to cache the results. They do this because that's how they've always done it. It wasn't a problem with scanners that were limited to 50 or 100 talkgroups per bank, but now it's a brick wall. Trunked systems never have more than about 25 comms on the go at any one time; with some simple caching implemented, the number of searches performed drops to a handful per second, which is well within the reach of any mobile processor.

You'd think that when progressing from manufacturing bicycles to motorcycles, a manufacturer would upgrade the wheels and tires before selling the product to the customer. Mind you, when there isn't any serious competition, the marketing department prefers to limit the top speed of that shiny new cycle to no more than 25 mph. It'll make next year's model that much more attractive.

jastx · #14 (**permalink**) 12-03-2006, 12:31 PM

Quote:

Originally Posted by slicerwizard

They are undoubtedly doing linear searches...

The maximum number of tests perfromed by a binary search is log2(n) + 1. The logarithmic behavior of a binary search means the list size can be doubled by making, at most, one more test.

It is relatively easy to implement. It would take a little time to construct the lists when the unit is turned on or a list of talk groups changed. This is a good tradeoff as these events happen infrequently but lookups are performed often.

I think it would be a great enhancement in a future release of the firmware. Performance would be substantially improved even if the list size wasn't increased.

slicerwizard · #15 (**permalink**) 12-03-2006, 08:34 PM

Quote:

Originally Posted by jastx

I think it would be a great enhancement in a future release of the firmware. Performance would be substantially improved even if the list size wasn't increased.

It's highly unlikely that they will fix this hobbled firmware. It would be a bad business decision. And no, binary searches would not improve performance with the current list sizes (200 talkgroups) - they already take place in the available time. Shorter search times would just leave the scanner twiddling its thumbs, waiting for new data to process.

jastx · #16 (**permalink**) 12-03-2006, 10:18 PM

Quote:

Originally Posted by slicerwizard

...And no, binary searches would not improve performance with the current list sizes (200 talkgroups) - they already take place in the available time. Shorter search times would just leave the scanner twiddling its thumbs, waiting for new data to process.

This makes no sense to me. Any system always spends 100% of its time. The idea is to make the most of what it does.

If a particular decision can be made in 4.5% (9/200) of the time, the time saved is available to make the overall system more responsive.

slicerwizard · #17 (**permalink**) 12-04-2006, 02:28 AM

Once the processor has evaluated all 200 talkgroups in its list, what would you have it do for the next 5 to 20 ms while it waits for the control channel to broadcast the next OSW? How would you make it more responsive?

jastx · #18 (**permalink**) 12-04-2006, 08:13 AM

Quote:

Originally Posted by slicerwizard

...How would you make it more responsive?

I was thinking there would be more time to make a weather priority check, or something like that.

It seems like we both agree that if the talk group lookup speed is the constraint on the talk group list length, techniques like a binary search could be used to relieve the constraint.

soncorn · #19 (**permalink**) 12-04-2006, 08:46 AM

Quote:

Originally Posted by slicerwizard

Once the processor has evaluated all 200 talkgroups in its list, what would you have it do for the next 5 to 20 ms while it waits for the control channel to broadcast the next OSW? How would you make it more responsive?

It would then be capable of evaluating more TG's than 200. This would allow people to have more TG's programmed in for a given system.

slicerwizard · #20 (**permalink**) 12-04-2006, 08:59 AM

Quote:

Originally Posted by jastx

It seems like we both agree that if the talk group lookup speed is the constraint on the talk group list length, techniques like a binary search could be used to relieve the constraint.

Agreed. That or caching, which is actually less costly to implement, since it has no sorting requirements - a binary search requires that either the talkgroups be sorted (not going to happen, since users want to choose the order) or that extra memory be used to maintain forward/backward pointers for a linked list (which effectively gives you two sort orders for the same list - physical order and link order). If newer scanners have an abundance of memory, they can use linked lists, otherwise caching will suffice.

A 1000 talkgroup per system scanner isn't that far off; as soon as marketing gives the green light...