My wishlist for the next "flagship" model...

[Ubbe]

That's not correct. Doing what you describe would slow scanning to the speed of a single receiver.

My proposed second dual receiver mode would have the first receiver to not stop at conversations, that could be a low priority one. It would just register the conversation and send it to the active list and then continue its search. That way it would find the higher priority conversations and not get stuck on lower priority calls and miss all the high priority calls.

The initial mode you propose would work more or less like two ordinary scanners, with the exception that they do not monitor the same conversation, but do not use the full potential of a dual receiver design to give an advantage over two conventional stand alone scanners.

/Ubbe

 

[jonwienke]

My proposed second dual receiver mode would have the first receiver to not stop at conversations, that could be a low priority one. It would just register the conversation and send it to the active list and then continue its search. That way it would find the higher priority conversations and not get stuck on lower priority calls and miss all the high priority calls.

The initial mode you propose would work more or less like two ordinary scanners, with the exception that they do not monitor the same conversation, but do not use the full potential of a dual receiver design to give an advantage over two conventional stand alone scanners.

/Ubbe

It would still miss more overall traffic, because only one receiver is actually scanning. If you divide scanning among 4 receivers in parallel, you're not going to miss any traffic, priority or not, until you're RXing a call on all 4 receivers simultaneously. And that's going to be fairly rare.

 

[jonwienke]

There's also going to be additional overhead involved with tuning a second receiver to the active frequency, in addition to the pointlessness of having one or more receivers doing absolutely nothing when no calls are active, while only one receiver does all of the scanning.

It makes far more sense to have all idle receivers scanning, as long as they are not duplicating their efforts. The algorithm I describe allows for doing so while prioritizing some channels over others. It scales seamlessly to any number of receivers; the routine that picks the next frequency to be scanned only requires that the current time and "last scanned" times be sufficiently accurate. It doesn't need to know how many receivers there are, or how many of them are actively scanning.

 

[trido]

Still like my simple idea for hp 3

Dreaming of unboxing a Home Patrol 3 UPMAN Edition.
P-25 Simulcast
incudes dmr,nxdn

 

[Ubbe]

in addition to the pointlessness of having one or more receivers doing absolutely nothing when no calls are active,

If a system gets active with a call there's a big chance that several more calls will be done in that system.

A system that do not have any calls are probably "dead" until something happens that activate traffic. The active list contains those systems that have had calls and are being scanned by the second receiver that will have a higher potential of monitoting conversations than a scanner that scans a lot of "dead" systems.

/Ubbe

 

[jonwienke]

If a system gets active with a call there's a big chance that several more calls will be done in that system.

That's what the Delay setting is for. I'm not proposing any changes to that.

A system that do not have any calls are probably "dead" until something happens that activate traffic. The active list contains those systems that have had calls and are being scanned by the second receiver that will have a higher potential of monitoting conversations than a scanner that scans a lot of "dead" systems.

A transmission on one talkgroup doesn't normally affect the odds of traffic on other talkgroups, unless there is a major incident. But if that is the case, there will probably be more traffic on multiple systems.

And in a 4-receiver configuration, the if a call comes in on a system, the remaining receivers will continue to scan that system; they will just ignore the active frequency or frequencies. So you have 3 receivers (or however many are not actively receiving transmissions) looking for additional traffic on both the active system, and whatever else is programmed to be scanned.

What you're proposing is less efficient, does not use a multi-receiver system to its full potential, and is guaranteed to miss more traffic.

 

[jonwienke]

One other major feature request:
A SDR stick and SDR# can scan about 10MHz/second when looking for active carriers by looking at the entire 2MHz bandwidth of the sampled output before retuning the receiver, rather than just the slice used by the current frequency. The existing SDS models should be able to duplicate that level of frequency range search performance by using a similar technique.

 

[Ubbe]

...unless there is a major incident.

That's exactly the purpose. Who is interested in listening to traffic cops, it's the incidents we are waiting for to monitor.

But if that is the case, there will probably be more traffic on multiple systems.

Exactly, that's where the triggered group member lists are useful.

/Ubbe

 

[Ubbe]

A SDR stick and SDR# can scan about 10MHz/second when looking for active carriers

Any multi receiver, and doing huge sampling frequency ranges, would require several CPU processors or a really powerful single one. We begin looking at a scanner in the $1500-$2000 range. People are complaining about how expensive the current $600 scanners are. It would be too few potential buyers to spread the total cost on of design, manufacture and retailers cut to make it wortwhile.

Public service scanner listeners are not crazy radio amateurs that have money burning in their pocket waiting to be spent on a $3000 receiver just for the fun of it.

/Ubbe

 

[jonwienke]

That's exactly the purpose. Who is interested in listening to traffic cops, it's the incidents we are waiting for to monitor.Exactly, that's where the triggered group member lists are useful.

/Ubbe

Your proposed method is less efficient, and would always miss more traffic. As long as they are not duplicating their efforts, multiple receivers working in parallel will find any activity, no matter which system, much faster than a single receiver.

 

[N4DJC]

It wouldn't have to be a printed manual. I'd be fine with a pdf on a mini-cd or even online, but there should be something much more complete than what is shipped with the SDS100. If that was all I had to go on I'd never have figured out how to work this thing.

Make it interactive with explanations of terminology.

 

[N4DJC]

Your proposed method is less efficient, and would always miss more traffic. As long as they are not duplicating their efforts, multiple receivers working in parallel will find any activity, no matter which system, much faster than a single receiver.

The Icom R-30 does that with dual RX, the A band is more sensitive though.

 

[Ubbe]

....multiple receivers working in parallel will find any activity, no matter which system, much faster than a single receiver.

I explain badly. It's not a single receiver system. One receiver are constantly searching for active systems and set a priority to what it finds and sends that info to the active list which the other receiver are monitoring.

You are then not forced to monitor uninteresting conversations from two monitoring receivers that have no clue of other more important conversations, as they are stuck monitoring the uninterested calls. You also get everything prioritized to your liking when monitoring only the active list with receiver #2.

Of course you could have 5 receivers, but one or several should always just scan and log to catch high priority calls in different systems.

/Ubbe

 

[eorange]

Many people can't even get past Favorites Lists and "Nothing to scan". Imagine trying to explain how this hypothethical radio works.

 

[jonwienke]

I explain badly. It's not a single receiver system. One receiver are constantly searching for active systems and set a priority to what it finds and sends that info to the active list which the other receiver are monitoring.

You are then not forced to monitor uninteresting conversations from two monitoring receivers that have no clue of other more important conversations, as they are stuck monitoring the uninterested calls.

It's not a matter of explanation, its simply a bad idea. If only one of n receivers is searching for new traffic, you've completely defeated the point of having multiple receivers--being able to scan n times faster than a single receiver.

If one of the receivers picks up something uninteresting, you can skip that transmission and free up the receiver to resume scanning. You're never "stuck" monitoring anything. And the algorithm that divides the scan load among receivers already handles scanning priority.

 

[MStep]

The multiple receiver concept is certainly interesting.... I've been waiting quite some time for the AOR 7400 to materialize, but alas 'tis just a dream at this time. For those interested in AOR's concept, you can check out AOR AR-7400 – coming in 2020 – Nevada Radio

There are a few other mentions of this receiver on other sites, and while it's oriented primarily for aircraft monitoring, it is a very interesting idea. The form factor of the current SDS200 screen would certainly seem to lend itself to something along these lines.

 

[Ubbe]

If one of the receivers picks up something uninteresting, you can skip that transmission and free up the receiver to resume scanning.

Then you will have to sit and nurse the scanner, manually skipping conversations, and in that case would work exactly as my proposed method but you would instead not need to manually do anything, it's all automatic.

My suggestion are an additional second mode to your proposel, so people have a choise of what they think would be most beneficial to them.
It's all in the software that are added to make the most use of the dual receiver hardware that you cannot get with two seperate scanners.

/Ubbe

 

[SQP]

If it can't DECRYPT....ALL encryption, you guys are WASTING YOUR TIME!!!!!!!!!!!!!!!!!!!!!! Just let it go.

 

[jonwienke]

Then you will have to sit and nurse the scanner, manually skipping conversations

You have to do that anyway when a major incident happens, because you can't predict in advance the exact nature of an incident of interest. The exact nature of the incident will dictate what holds or avoids you want to set.

and in that case would work exactly as my proposed method but you would instead not need to manually do anything, it's all automatic.

No, because you can't pre-program priorities suited to a specific incident before it happens. Let me cite some examples. I monitor Virginia STARS, West Virginia SIRN, WInchester City, and Frederick County Virginia. There's no way I can program priorities in advance to properly handle all of the following:

• A car chase on I-81. May involve the Virginia and/or West Virginia state police, depending on exact location, and possibly Frederick County sheriff units. So some combination of SIRN, STARS, and Frederick County would have the traffic of interest, but there's no way to know which before the incident.
• Active shooter in downtown Winchester. The Winchester PD would be the primary responders here, with possible backup from Frederick County or the Virginia state police. So Winchester City, Frederick County, and STARS would be the priorities, in that order.
• Major fire in Berkeley County, WV. This would be almost exclusively SIRN, as pretty much every state and local agency uses that system. But there might be mutual aid activity on STARS, Frederick County, or Winchester City, depending on the magnitude of the incident.

In a major incident, the only way to know if there is mutual aid activity is to continue to scan all of the potentially affected systems with all available receivers not busy actively receiving a call. Limiting actual scanning to one receiver is never a good choice under any circumstance.

One other point: I currently have 5 receivers scanning different stuff:

• BCD436 scanning Frederick County (a collection of conventional analog FM frequencies)
• SDS100 holding on the VA-STARS system, scanning 3 system sites.
• SDS200 holding on the WV-SIRN system, scanning 4 system sites.
• Unication G5 monitoring the Winchester City 800 simulcast system (which has only one site).
• BCD536 scanning everything in my vicinity except the above.

Having 2 simultaneous calls is fairly common; that happens a few times per hour. 3 simultaneous calls happens maybe once or twice a day. 4 or more is very rare, even in bad weather while listening to the snowplows and police, fire, and EMS responding to an endless parade of accidents. With a quad receiver setup, having all 4 receivers busy receiving calls is pretty unlikely--something happening a small fraction of 1% of the time, and only for a few seconds at a time. And unless you have all receivers busy, there's no reason to automatically bump a receiver off a call in the hope that you'll scan and find something of greater interest. That's not going to be the case most of the time, and unless all receivers are actively receiving calls, if there's another call active, it's going to get picked up anyway.

There is no compelling argument you can make to justify limiting scanning to just one receiver, to implement priorities that you can't accurately predict or program in advance.

 

[sonm10]

This thread is a fun read - Jon and UBBE battling out