15/996 Speed Up Trick: Myth Confirmed

[cpuerror]

There have been some questions asked about what is the fastest way to get it to scan through conventional systems. Should frequencies by ascending, descending, or does it not matter?

To answer this, here is what i did. I created 3 conventional systems, each had 500 channels. One system was ascending, one descending, and one was in random order.

I uploaded them and then using a stop watch I timed how long it takes to do each channel. Here is what I got (averages):

Scanning Up: 9.8 Seconds
Scanning Down: 9.7 Seconds
Random System: 17.9 Seconds

So the answer is to make sure the frequencies are sorted to get maximum scanning speed, though it doesn't matter which direction they are in. Having them sorted can nearly double the scan speed.

 

[bwhite]

Well, I guess we know which method not to use. Thanx

 

[pogbobo]

lol looks like some folks will be doing some reorganizing this weekend

thanks for the info!

 

[trunker0205]

lol looks like some folks will be doing some reorganizing this weekend

thanks for the info!

The Arc software will do it for you.

 

[kennyloatman]

I did it (ascending down) My scan speed on my 396t and my 796d has just about doubled.

 

[eraweeb]

Since it has been confirmed that ascending and descending frequencies scan twice as fast as random frequencies, here's one more thing that can be done on a system that has several groups.

Make the first group or bank ascending, the second descending, the third ascending, etc. etc. In other words every other second group either starts low or starts high.

That way as it gets to the end of one group or bank it will be in a higher freq range. As it starts the next group or bank it will be starting at a high range instead of starting at the opposite end. Then the next one will end at a low range and the next starts at a low range, etc.

 

[rdale]

era - you confirmed that has an impact?

 

[Sputnik-0]

I'd wager that ascending/descending organization would save only a few milliseconds between groups at best, heh.

 

[Boomeranger]

There have been some questions asked about what is the fastest way to get it to scan through conventional systems. Should frequencies by ascending, descending, or does it not matter?

To answer this, here is what i did. I created 3 conventional systems, each had 500 channels. One system was ascending, one descending, and one was in random order.

I uploaded them and then using a stop watch I timed how long it takes to do each channel. Here is what I got (averages):

Scanning Up: 9.8 Seconds
Scanning Down: 9.7 Seconds
Random System: 17.9 Seconds

So the answer is to make sure the frequencies are sorted to get maximum scanning speed, though it doesn't matter which direction they are in. Having them sorted can nearly double the scan speed.

Using a stopwatch? Gotta figure some human error into those numbers!

You didn't time 10 groups of 50 channels by chance? Who on earth is going to have a one group, 500 channel system???

Also, that method will foil Priority channel scan order (which I carefully planned out by systems and groups ascending order, as the scanner does),

Andy
Scannist

 

[cpuerror]

Using a stopwatch? Gotta figure some human error into those numbers!

You didn't time 10 groups of 50 channels by chance? Who on earth is going to have a one group, 500 channel system???

Also, that method will foil Priority channel scan order (which I carefully planned out by systems and groups ascending order, as the scanner does),

Andy
Scannist

Yes there is a bit of human error but its not going to be off by 8 seconds. Even if i'm off a bit, it still proves that it scans a lot faster in order rather then in random and that was the point of the test.

I'm just throwing this information out there. If in your understanding you think its flawed, you are free to ignore it.

 

[eraweeb]

Just as a sidebar to all of this, many years ago either Monitoring Times or Pop Com (I forget which) published the best method of monitoring a trunked system on a non-trunking scanner.

It is pretty much the same method that I outlined in a previous post. Load in all of the system freqs in one bank starting with the lowest number first and going up. Then in the same bank repeat the freqs in the opposite order.

"Supposedly" this will give you the greatest number of continuous hits as you monitor the system. Naturally it is not going to "follow" all the conversations verbatim, but potentially it should give you the greatest number of intelligible transmissions especially if you only monitor the same bank over and over.

I remember trying this method at the time on a non-trunking scanner and it seemed to work pretty well. Perhaps someone would like to repeat this experiment now and report on their findings.

 

[rdale]

Of course you can hear, it's just that you can't follow conversations or lock out unwanted comms.

 

[Boomeranger]

Yes there is a bit of human error but its not going to be off by 8 seconds. Even if i'm off a bit, it still proves that it scans a lot faster in order rather then in random and that was the point of the test.

I'm just throwing this information out there. If in your understanding you think its flawed, you are free to ignore it.

No kidding?

Your results are less than stellar. So is your "benchmark".

Can WE take your results to the bank?

Not likely.

Try a 50 group with 10 channels system and get back to us.

Andy
Scannist

 

[DonS]

To anyone who's ever written code that "tunes a radio", there's a very good (not to mention very obvious) reason why tuning frequencies in ascending or descending order can be significantly faster than tuning them in some arbitrary, random order. The difference in "tunes per second" can be a few orders of magnitude.

Presuming Uniden's programmers are at least half-way competent and have at least a beginner programmer's skills at optimization, we can almost certainly bank on cpuerror's results.

 

[pro92b]

No kidding?

Your results are less than stellar. So is your "benchmark".

Can WE take your results to the bank?

Not likely.

Try a 50 group with 10 channels system and get back to us.

Andy
Scannist

Actually he designed a well controlled experiment and his results are quite valid. The more channels in the test system, the less significant the error in timing by hand. I test with 1000 channel systems to get a reading of maximum scan speed, assuming the scanner can take 1000 channels. The fact that nobody runs systems with 1000 channels is irrelevant to the purpose of the experiment and absolutely does not invalidate the results.

 

[scannersnstuff]

"use guy's got to much time on your hands" LOL.

 

[cpuerror]

To anyone who's ever written code that "tunes a radio", there's a very good (not to mention very obvious) reason why tuning frequencies in ascending or descending order can be significantly faster than tuning them in some arbitrary, random order. The difference in "tunes per second" can be a few orders of magnitude.

Presuming Uniden's programmers are at least half-way competent and have at least a beginner programmer's skills at optimization, we can almost certainly bank on cpuerror's results.

The stop watch doesn't lie. 17.9 seconds vs 9.8. Same number of channels.

 

[DonS]

The stop watch doesn't lie. 17.9 seconds vs 9.8. Same number of channels.

I don't doubt that at all, based on my experience in a past job with writing to a few tuners.

 

[cpuerror]

If anyone is interested in doing this test for themselves, you can download the file I created at http://scannow.org/convspeedtest.996 (load it up with FreeSCAN). Your results will probably vary slightly then what I have, but I think it will be very clear that a random system takes a much longer time to scan.

 

[Boomeranger]

YI'm just throwing this information out there. If in your understanding you think its flawed, you are free to ignore it.

Naturally, but you should have at least come up with a "real world" benchmark that benefits people, not something that suits nobody.

I'm certainly not interested in a 500 channel system. A cute stat but it's hardly going to change the way folks program their scanners. That's what you were saying!

Andy
Scannist