SDS100 Scan Direction

[CameronCole]

Hello,
There is a white arrow on the top left of my scanner screen under my signal bars. I have read and found out that it is the Scan Direction. What is Scan Direction and how do I use it? Also, how do I turn it on/off?
Thanks in Advance!

 

[letarotor]

You don't turn it on or off. It just simply is what it sounds like. It tells which way your radio is scanning the frequencies and talk groups.

Here's a short example. Let's say you program in the following:

Frequency 1
Frequency 2
Frequency 3

Or...

TGID 1
TGID 2
TGID 3

When the scanners scanning forward, it's going to start with 1 and move towards 3 as it scans the channels. And if you're scanning in reverse, it starts with 3 and goes to 1 in order.

It's that simple. If you miss a transmission before you can hit the Hold button and you're scanning a lot of channels, you can scroll the rotary knob to the left and it will scan backwards towards the channel you missed. You might be able to catch traffic on the missed channel quicker and then hold on the channel rather than wait for it to scan all the way through everything you have programmed to come back around to that channel. That can be real helpful when you have a lot of stuff programmed / scanning.

I hope that helps...

Brian
COMMSCAN

 

[jonwienke]

Talkgroups are NEVER SCANNED. Only conventional channels and trunked site frequencies are scanned. The scanner does an indexed database lookup when it hears a talkgroup ID in the control channel data, so you can program thousands of talkgroups for a system with no measurable difference in scan speed.

 

[trentbob]

The sds100 is not the first scanner to show this direction arrow. The only use it has ever had for me was if I am doing a limit search and I don't push Channel button fast enough to stop on something, I can back up manually and find it.

 

[Ubbe]

If I remember correctly from the debug file a SDS100 scans TG's at a rate of 10/mS. So if you have 10,000 TG's programmed and the detected TG isn't included in that list then it would take one additional second until the scanner begins to go to the next site, if you do not have ID search on. If the detected TG matches with the last one in the list it would take one second until audio are heard and the info are shown on the display.

The scanner needs to stay at least 1,5 sec on a control channel to properly decode the data and perhaps someone has 1,000 TG's associated with a site and that would only add a worst case of a 0,1 sec delay, so shouldn't be any major issue. The CPU in the scanner are scanning thru the TG list, stepping thru it one increment at a time, in a similar way to how it scans channels.

/Ubbe

 

[doctordialtone]

The CPU in the scanner are scanning thru the TG list, stepping thru it one increment at a time, in a similar way to how it scans channels.

I think you're wrong.

The scanner looks at the control channel to determine where to tune. It doesn't scan talk groups.

See post #3

 

[GregOH]

Scans sites up from A to Z and repeats and down from Z to A and repeats.

The only thing I use it for is if the scanner stops on something that I'm not interested in, I'll turn the knob one click clockwise and hope it lands on a different channel once it stops on that site again.

 

[jonwienke]

If I remember correctly from the debug file a SDS100 scans TG's at a rate of 10/mS. So if you have 10,000 TG's programmed and the detected TG isn't included in that list then it would take one additional second until the scanner begins to go to the next site, if you do not have ID search on. If the detected TG matches with the last one in the list it would take one second until audio are heard and the info are shown on the display.

The scanner needs to stay at least 1,5 sec on a control channel to properly decode the data and perhaps someone has 1,000 TG's associated with a site and that would only add a worst case of a 0,1 sec delay, so shouldn't be any major issue. The CPU in the scanner are scanning thru the TG list, stepping thru it one increment at a time, in a similar way to how it scans channels.

/Ubbe

Wrong. It takes less than 1/10s for talkgroup info to show scanning the WV-SIRN system, which has over 1500 talkgroups programmed. Talkgroup lookups are indexed by talkgroup ID, so doubling the number of programmed talkgroups does NOT double the lookup time.

 

[Ubbe]

.... someone has 1,000 TG's associated with a site and that would only add a worst case of a 0,1 sec delay, so shouldn't be any major issue.

Wrong. It takes less than 1/10s for talkgroup info to show scanning the WV-SIRN system, which has over 1500 talkgroups programmed.

We seem to agree of the time it could take to scan thru the TG list at the rate that the debug file shows.

/Ubbe

 

[jonwienke]

No. The time per talkgroup isn't linear, because it's not scanning the list. It's doing an indexed lookup, using some variation of binary chop, so lookup time doesn't increase linearly to N, it increases with log of N (N being the number of programmed talkgroups), with a certain amount of overhead for initializing variables, etc.

 

[JoeBearcat]

I think you're wrong.

The scanner looks at the control channel to determine where to tune. It doesn't scan talk groups.

See post #3

Doc is correct. Talkgroups are decoded - not scanned.