Isolating trunked systems
- Thread starter nacsr
- Start date
- Status
That disregards the whole point of having a scanlist...on Uniden scanners, the system dwell time resets even when scanning only the single system, rescans for a control channel constantly, pretty annoying. Do Whistlers stay static on CC when scanning a single system, not locked onto a talkgroup?
Paul
Paul
Isolating Trunked Systems
I think that idea stemmed from all the complaints about Scan speed. That was the first major complaint with GRE PSR800 and my WS1080 after it. People didn't like the 70 steps a second compared to the old TURBO SCAN days evidently. I have Conventional and Trunked talkgroups mixed by Counties. There's no problem as you always can cut back on Dwell time, number of scanlists and delays for individual objects to speed things up. It's our scanner. We can do what we want regardless of what "they" claim. Ha!
I think that idea stemmed from all the complaints about Scan speed. That was the first major complaint with GRE PSR800 and my WS1080 after it. People didn't like the 70 steps a second compared to the old TURBO SCAN days evidently. I have Conventional and Trunked talkgroups mixed by Counties. There's no problem as you always can cut back on Dwell time, number of scanlists and delays for individual objects to speed things up. It's our scanner. We can do what we want regardless of what "they" claim. Ha!
Last edited by a moderator:
Thanks for your reply. I haven't seem a problem,so was curious.
ScannerSK
Member
I know in the Whistler WS1040 and WS1065 scanners that it will not make any difference having them in the same scan lists as conventional channels are scanned as a group and then talkgroup systems (with some enabled talkgroups) are scanned separate from conventional channels.
No matter how mixed up everything is in the memory, the above scanners simply pick out all the conventional channels (which meet the criteria to be scanned) and scan them in order from lowest object number to highest object number and then the scanner moves on to talkgroup systems (with some enabled talkgroups) and then on to other things like limit searches and sweeper searches, etc.
Shawn
No matter how mixed up everything is in the memory, the above scanners simply pick out all the conventional channels (which meet the criteria to be scanned) and scan them in order from lowest object number to highest object number and then the scanner moves on to talkgroup systems (with some enabled talkgroups) and then on to other things like limit searches and sweeper searches, etc.
Shawn
troymail
Silent Key
It's not a problem to mix and match types in scanlists. If you do a location based import on a Whistler scanner, everything that matches various types of activity (Fire Dispatch, Law Talk, etc.) - regardless of trunked or conventional - ends up in a specific scanlist. If it were a problem, they wouldn't do that.
Behind the scenes, the scanner is just taking everthing that was presented to you in these human manageable and readable "groups" (scanlists) and running with it. Ultimately, if you put everything in a single scanlist vs. spreading it over dozens of scanlists, the result inside the scanner is likely exactly the same.
Having said that - in a pinch/hurry - I've created scanlists that do this type mix/match programming. However, in the long run, I prefer to keep things as "separate as possible" in different scanlists to have maximum control of what is being scanned.
Behind the scenes, the scanner is just taking everthing that was presented to you in these human manageable and readable "groups" (scanlists) and running with it. Ultimately, if you put everything in a single scanlist vs. spreading it over dozens of scanlists, the result inside the scanner is likely exactly the same.
Having said that - in a pinch/hurry - I've created scanlists that do this type mix/match programming. However, in the long run, I prefer to keep things as "separate as possible" in different scanlists to have maximum control of what is being scanned.
- Status
