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

[jonwienke]

@JoeBearcat this is my official wishlist for what I'd like to see in the next generation of scanners.

1. They should have multiple receivers, say 2 in the handheld and 4 in the base/mobile. All receivers scan the same favorite list(s), but they divide up the load in the following manner:
   • All unique frequencies are parsed from the active scanlist, and added to an active frequency list. Each unique frequency gets one and only one entry in the active frequency list. Close Call, priority weather channels, etc are entries in this list.
   • The active frequency list gets updated whenever Location Control or the user toggle active scan items.
   • Each entry in the frequency list is assigned a "last scanned" timestamp flag, and a priority multiplier that can be set between 0.1 and 10.0. The default priority multiplier setting is 1.0.
   • Each time a receiver is done checking a frequency, it updates the "last scanned" timestamp for that frequency to the current date/time before moving on.
2. When a receiver is ready to move to the next frequency, choosing the frequency to scan next is done as follows:
   • The difference between the current time and the "last scanned" time is calculated for each frequency. This must happen after the "last scanned" timestamp for the previous frequency has been updated, so the frequency just scanned gets pushed to the bottom of the list of stuff to be scanned.
   • Each frequency's difference value is multiplied by its priority multiplier to give the frequency a priority score.
   • The frequency with the highest priority score is scanned next.
   • Scan priority is no longer a binary yes/no option, but a sliding scale, where a priority 10 setting means a frequency gets scanned 10x as often as a frequency with a priority 1 setting, and a 0.5 priority gets scanned half as frequently as priority 1.0.
   • Close Call, weather, and other priority channels no longer need a Do Not Disturb option, they just get a high default priority setting, e.g a priority of 10.0 so Close Call or a priority weather channel get checked 10x as often as Pudunk Garbage Service. That ensures they get checked with a high priority, but doing so never interrupts a call in progress.
3. Channel holds are assigned to the next available receiver when the hold is placed, and the hold only pauses the assigned receiver. All of the other receivers continue scanning as described above.
4. Received audio is buffered, and if multiple transmissions are received simultaneously, they are added to a playlist in the order received.
5. The playlist user interface has MP3 player style controls: first, previous, next, last, fast forward, rewind, and a horizontal scroll bar to go to a specific spot within the clip, etc.
6. When a clip is playing, the applicable favorite list, system, department, channel, frequency, color code, RSSI, etc are displayed on-screen. The clock shows the time the current point of the call was received, rather than the current time.
7. New transmissions are added to the end of the playlist as they are received, and can be monitored live.
8. Older transmissions drop off the playlist after either a certain amount of elapsed time, or once the playlist grows beyond a set size. The user can set clips to be deleted when they are more than an hour old, or when the total length of the playlist exceeds a set time. The age and total length settings should be separate, with the playlist total maximum length value limited to prevent bogging down the scanner or overflowing available memory.
9. The playback interface should probably be touchscreen-based, to update the REPLAY function with something a lot more intuitive and user friendly, and make it easy to navigate audio clips coming in from multiple sources simultaneously.
10. ADD BUILT-IN GPS TO THE HANDHELD MODEL!!!!!!
    • When on, the GPS does not need to run continuously. Once a fix is acquired, it can go into sleep mode, wake up once per minute or so to get a new fix and send it to the scanner, then go back to sleep.
    • GPS is turned on/off in the location menu, or a dedicated button on the keypad.
    • If GPS is built in, the ZIP code and auto locate menu entries can be deleted, and the ZIP button replaced with GPS.
    • Automatically sync the RTC with the GPS when the GPS is active. This is supposed to happen with current models, but the current implementation doesn't seem to work very well. Even after running for several days with GPS connected and active, sync only happens to the nearest minute, and there can be up to a minute between one scanner and another updating the clock display from 14:55 to 14:56. (Consider this a bug fix request for all current models.)

 

[starwtc]

I like the built in gps idea on some models but the more addons a higher price.
I would like to have volume control over radio id's!

 

[AB5ID]

+1 on items 4-8 but that might take some horsepower if looking at a 10Mhz chunk of spectrum.

 

[trentbob]

I'd like it Jon, I'm thinking the SDS radios with some additional tweaks will be their Flagship scanners for quite a while.

You would be the one who would know exactly what is needed or would be wanted in such a radio. No question about it.

So as we discuss this, let's talk about the elephant in the room, the R&D, Uniden's business model as encryption spreads faster than the virus and cost. A plus here is they don't have to think about or consider any viable competition as there isn't any.

I'm one of those people that would pay! Whatever it cost, lest we not forget radios like the Electra Bearcat 101 in 1975 that cost $399.99. About $1,900 in today's money and worth every penny. Makes the SDS radios look like a bargain. As we discuss this are people willing to pay extra bucks for these additional options?

I would!

 

[u2brent]

I would like to have volume control over radio id's!

Avoids as well on RID/UID's.. Not just TGID's (To ignore just that one subscriber)

 

[jonwienke]

Bu

I like the built in gps idea on some models but the more addons a higher price.
I would like to have volume control over radio id's!

Built-in wouldn't have to add more than about $20 to the unit cost. It would be insignificant compared to adding the cost of the extra receiver(s), audio buffering, extra display functions (touchscreen UI), and the computing horsepower to make it all work.

 

[jonwienke]

Some thoughts on cost:
A multi-receiver scanner could take the place of multiple single-receiver scanners, with the added advantage of coordination and scan prioritization among all the receivers not doable with several single-receiver scanners. A quad-receiver scanner would be more versatile and effective than 4 single scanners, and could replace them at a lower per-receiver price.

Additionally, if the receivers were built in a daughterboard module form factor like computer RAM, you could sell the scanner with 2 receiver modules installed, and maybe 6 vacant slots the user could populate with additional receiver modules later as budget allows. Bonus points if the handheld and the base/mobile used the same receiver module.

 

[trap5858]

I would like to see built in blue tooth technology

 

[tumegpc]

I would like Uniden to make a NON-SDS Handheld scanner with a touch screen, Bluetooth, P25, DMR, and NXDN. There are many of us that don't have LSM issues. Something along the line of the Yaesu FT3D! Which includes a drop-in charger with an AA Battery option. It's about the same size as the 396XT.

 

[ProScan]

My ideal scanner
Same UI, functionality, display size with all the info, & colored display as the SDS200 except:

• Dump the SDR design and go with a conventional RF design similar to the 996P2 except change the discriminator to a IQ type of demod.
• Change the Micro USB to a Mini USB connector.
• Add a full html5 UI to the built in Web Server and allow user injected html, javascript, & css code.
• Add extra fields to the protocol (F-List, Trunk, C- Group, etc) that will retain the values after a scanner write & read. There's extra fields now that appear to be reserved but they don't retain the values. This would be perfect to add notes or other info.
• Make a portable type exactly the same.
• {edit} Fix the rtsp audio code module. As it is now, if the Ethernet connection disconnects > 60 secs. or the app or computer abnormally shuts down, the rtsp audio stops working and requires a reboot.

 

[TailGator911]

I would definitely pay the extra cost for the extra add-ons. Let's not forget the waffles now.

 

[trentbob]

You know JD, I fought like hell not to say we must include the waffle maker. A fond reference to Paul... I'm very happy you brought it up. You're funny

 

[Patch42]

Whatever features might end up in a new model, I'd like somebody at Uniden to insist it not be released until a thorough and complete manual is available. The manual should explain EVERY feature in exacting detail, and give examples of how that feature might be used in the real world.

 

[Nasby]

#1, An AGC that works!!!!!!!!!!!!

All the fancy features in the world ain't worth squat if the audio levels constantly suck.

 

[MStep]

Whatever features might end up in a new model, I'd like somebody at Uniden to insist it not be released until a thorough and complete manual is available. The manual should explain EVERY feature in exacting detail, and give examples of how that feature might be used in the real world.

Hi Patch.... wow, you're talking the old days of my first Tandy TRS-80 computer with accompanying 300 page, loose-leaf bound 8.5 x 11 inch manual. And that was just for the actual hardware. A program like a word-processor or spreadsheet would involve another 200-300 pages and instructions, examples, computer practice sessions, and more. Unfortunately, I fear that those days are over. I certainly agree with your request, but I'm afraid that the Internet has spoiled most companies from supplying all but the barest operating instructions and count on perplexed users to garner information here online.

And truth be told (and I'm as guilty as anyone else), most folks end up powering up the device before they even look at the manual. Everyone loves instant gratification. On the plus side, and I think we all do it, those instruction manuals do help pass the time while poised on the throne!

 

[Patch42]

Hi Patch.... wow, you're talking the old days of my first Tandy TRS-80 computer with accompanying 300 page, loose-leaf bound 8.5 x 11 inch manual.

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.

 

[jonwienke]

One other thought: when a control channel is found for a trunked site, the scanner should cache that frequency, and check it first every time it revisits that site, until it fails to find a control channel on that frequency. This would eliminate the small scan speed penalty incurred when all site frequencies are entered, and the control channel is near the bottom of the list of site frequencies.

 

[Ubbe]

Each time a receiver is done checking a frequency, it updates the "last scanned" timestamp for that frequency to the current date/time before moving on.

I would like to add a second mode option to that.

One receiver are just scanning and not monitoring. When it finds activity it sends that info to the active list that the second receiver are scanning and monitoring.
If the first receiver detects activity with a higher priority it will put that at the top of the active list. If DND are selected the current call that are monitored will finish and when it continues scan it will pick the one from the top of the list. If non-DND are selected it will interupt the current monitored frequency or TG and immediatly pick the higher priority call from the active list.

Having one receiver do all the checking for activity and let the second receiver monitor it, will let the scanner be more active without any dead time while scanning for active systems.

There should also be a group function that triggers from one member of the group.
Lets say it's pure conventional frequencies and a fire brigade channel gets active. Then it's a high probability that also other services are active like the sheriff channel. They are configured to be in the same "incident" group. If one of the channels get active it automaticly includes the others in the same scan group even if they havent' yet been detected to have activity.

If one mil-air channel gets active it automaticly includes the other mil-air channels in the scan group.

If there's no activity in a group for a certain time, perhaps 15 minutes, the "incident" are probably over and the group are released and cleared from the scan list. That "incident" group could be used in todays one receiver scanners if it works like some sort of priority system that gets scanned more often, like at each 5th system, or 10 sec, whatever comes first, in a scan list.

/Ubbe

 

[GTR8000]

One other thought: when a control channel is found for a trunked site, the scanner should cache that frequency, and check it first every time it revisits that site, until it fails to find a control channel on that frequency. This would eliminate the small scan speed penalty incurred when all site frequencies are entered, and the control channel is near the bottom of the list of site frequencies.

Most modern Uniden scanners already do just that. Watch an x36HP or SDS when scanning between multiple sites/systems...it immediately locks onto the last known control channel; it never searches through the entire list of frequencies each go around. This behavior is especially apparent if you use ProScan: watch the small frequency box below the display and/or the Site Frequency field on the Tests & Extras tab where you can see the actual frequencies the scanner is tuning to. It jumps directly between last known control channels.

Edited to add: Naturally the scanners are caching the last known control channel, otherwise after a voice call ends it would need to hunt for the control channel all over again, which it clearly does not do. Anyway, it's easily observable as I mentioned.

Direct from Paul: How does trunked scanning work in a Uniden?

 

[jonwienke]

Having one receiver do all the checking for activity and let the second receiver monitor it, will let the scanner be more active without any dead time while scanning for active systems.

That's not correct. Doing what you describe would slow scanning to the speed of a single receiver. What I describe allows all idle receivers to scan at full speed without duplicating their efforts.