Make the BCD536 work on simulcast, be more responsive(key presses), and add a true remote-head for mobile installations. Oh, and have the memory work like the XT series, so you can turn it on and off and scan immediately, instead of having to wait for the memory to be loaded and saved, especially in a mobile setup.
Wish List For Next-Gen Scanners
- Thread starter jonwienke
- Start date
- Status
X2 for a remote head option and functionality on linear simulcast systems. These two items should already have been addressed in the current generation of scanners.
There's no reason for an integrated GPS to not be handled the way Location Control is now - completely optional and default is OFF.
I know. It's been that way my entire life, and I'm OK with that.
Works for me.
Thanks!
-Jon
omrail
Member
Integrated GPS would be nice. I have a friend that every time we talk about scanners asks me if anyone is coming out with a scanner with it. Just hope it does not add a large amount to the price.
LOL location control is always on when scanning the main database. RTFM. Just think about the stupidity of trying to scan every frequency for every system in the USA and Canada. That is exactly what would happen if Location Control was off.
Point noted. I don't scan the entire database, so I didn't need read that portion of the manual. I'd wager that most x36HP users that aren't already using GPS aren't scanning the entire database either, opting for FLs or the Zip Code method.
There is still no reason to believe that an integrated GPS would not have ON/OFF selectability by the end user.
Using the GPS is the only way to go when traveling. The only time it would make sense to turn it off is when using it as a base station, and you already have the scanner GPS location established, and you were running on batteries for some reason.
SOFA_KING
Member
Think BIG
OK...Here goes...Hope someone actually reads this!
CONDITIONAL SCANNING
How about a totally different way of looking at individual “frequencies” as potential “lists” of defined “channels“? When you examine how (well documented) frequency band channel tables (band plans) are used, and more importantly how frequencies are “reused”, sometimes very aggressively…even in the same system or by the same agency, it makes sense to address “channels” differently. Instead of scanning the same frequency multiple times, stored on different channels with different modes, access codes, name tags, location control data, manual threshold fine tune data and the like, approach it as a ONE TIME scan pass with a list of flexible and definable conditions with different name tags for each condition. This will reduce scan time considerably! Once activity is detected on a frequency, the scanner checks the list of conditions you define, and either opens if conditions match, or passes on by to check the next frequency with a list of defined conditions. Nothing defined? No problem! Those can be bypassed from being scanned.
For example…take one frequency, something semi-fictional like a huge National Park system frequency on 172.0000 MHz. You may have P25 used on the frequency with multiple NAC codes for different tower/repeater locations, and even analog with multiple CTCSS and/or DCS codes used. Instead of having to enter all these as different scanning channels with the same frequency, and wait for the scanner to check each one while it wastes time checking for a match on each channel before it (hopefully) eventually locks onto the matching channel with the activity you want to hear, it only needs to check one time on a single frequency for a list of matching conditions, then quickly open up to hear the activity. Scan time is VALUABLE! You hear little to nothing if it is wasted. And lets say you have another (unrelated) co-channel user on this same frequency you may want to also hear, say on DMR this time, you can also define that as a condition (positive or negative) with a name tag (or name tags for different slot/TG use). One frequency…many conditions. Call it “Conditional Scanning”.
Since frequencies are reused all across the country, and many times used with different modes and access methods, it makes sense to build the database that addresses the “condition” and “location” on a single frequency instead of the other way around. The SAVINGS would be enormous. And you could even add a “Discovery” option to the list of conditions with lockouts for known access codes, talk groups, locations or other system details. That could be recorded with audio (or without) and stored in a sortable list with ALL the mode information and access parameters logged…everything. That list could even be a living database itself for managing everything detected and keeping track of it all. You would probably need the location of the station that heard the specific activity stored in the log files for identification and coverage verification, but that is easy enough…even if you put a manual lat/lon location in your fixed station scanner. You could even have coverage of the specific condition (from base or GPS tracking mobile units) automatically plotted on a google map! Add the ability to “upload” and share data (user selected…some yes, and maybe some no), and you have true power to build a national database with little effort needed by human intervention other than adding identification name tags to what was automatically acquired (collected) in the field. Now that is powerful scanning, searching and database management!
So you have a frequency like 172.0000 MHz. First layer is check boxes for the modes you want to hear:
- P25
- DMR
- NXDN
- Fusion
- D-STAR
- Analog (Coded Squelch only option default, CSQ after no coded squelch detected checkbox option)
Then you have a sub-layer for each mode with different access details for each “channel”. Since encryption is often used, and may not be worth wasting time on by stopping on it, make each “channel” have the option to stop or pass (default) on encryption. Each “channel” has a name tag, delay setting, alert light/sound option, digital threshold adjustment (defaulted to the most common user defined “general” value, if not addressed), rectangle(s) for location control (optional), and can be assigned to a scan list…which then can be assigned to a scan group with multiple lists. If you are “out of range of anything defined” (by using location control), skip the frequency from being scanned altogether (saves a lot of time!) unless you are searching for unknowns in a type of discovery mode. But it is important to allow total control over conditions. The CSQ (carrier squelch) option is the last resort if all other “intelligent” access control options are exhausted (bottom of the list). Some frequencies may indeed be used with analog carrier squelch only, but you would probably want to limit the coverage area of such type reception and make sure it is on the bottom of the list of any other conditions that may be enabled. And there are times you want to detect any type of signal to verify activity or frequency conditions...like with a Monitor button (could be interference or an undefined type of data transmission), but that can have the potential to lock up scanning on noise . Same with encryption however, it is important to capture any usable intelligence (such as NAC codes or User ID / TG) if it is there, even on encryption or data when you want to. You may just need a “grab and go” option while searching (or discovery operation) to prevent unnecessary hang-ups. And remember, data (without voice) going across a system has lots to offer and may be worth logging (at least once). You may not want to hear it or spend a lot of time on it, but it has value for identification purposes. You may want to track it to plot coverage, if nothing else, but not hang up on it all day.
Trunked systems? Yes, I know this primarily addresses conventional use, but trunked systems already do this type of scanning when you think about it. We all encounter the trunked system activity on conventional search, but even that has value and could be used for harvesting data. More thought on how to handle that scenario might be needed (WIP). But we all know that everything we hear out there is not always listed in the FCC database…or sometimes anywhere else for that matter. Searching is still very relevant and useful. But let the scanner manage the unknown data in a way that makes it easy to sift through the known data (search between the cracks and log the results).
There is so much potential in this type of operation. You could even make an interactive map that plots system coverage based off of user reception location and signal strength data. It could even plot tropo conditions! If you ask me, this is the future of scanning. Good software could make it easy to manage. No need to be all that complicated about it. Excel type export/import functions with all the copy/paste/cut/insert/delete options would make maintenance a snap. But you had better put the fastest processor you could practically manage in a scanner like that. You don’t hear what is waiting to be picked up by slow scanner! (like my x36 scanners) And you don’t want the beginning of each transmission being clipped by a slow processor looking for matching conditions. Speed is paramount!
Phil
OK...Here goes...Hope someone actually reads this!
CONDITIONAL SCANNING
How about a totally different way of looking at individual “frequencies” as potential “lists” of defined “channels“? When you examine how (well documented) frequency band channel tables (band plans) are used, and more importantly how frequencies are “reused”, sometimes very aggressively…even in the same system or by the same agency, it makes sense to address “channels” differently. Instead of scanning the same frequency multiple times, stored on different channels with different modes, access codes, name tags, location control data, manual threshold fine tune data and the like, approach it as a ONE TIME scan pass with a list of flexible and definable conditions with different name tags for each condition. This will reduce scan time considerably! Once activity is detected on a frequency, the scanner checks the list of conditions you define, and either opens if conditions match, or passes on by to check the next frequency with a list of defined conditions. Nothing defined? No problem! Those can be bypassed from being scanned.
For example…take one frequency, something semi-fictional like a huge National Park system frequency on 172.0000 MHz. You may have P25 used on the frequency with multiple NAC codes for different tower/repeater locations, and even analog with multiple CTCSS and/or DCS codes used. Instead of having to enter all these as different scanning channels with the same frequency, and wait for the scanner to check each one while it wastes time checking for a match on each channel before it (hopefully) eventually locks onto the matching channel with the activity you want to hear, it only needs to check one time on a single frequency for a list of matching conditions, then quickly open up to hear the activity. Scan time is VALUABLE! You hear little to nothing if it is wasted. And lets say you have another (unrelated) co-channel user on this same frequency you may want to also hear, say on DMR this time, you can also define that as a condition (positive or negative) with a name tag (or name tags for different slot/TG use). One frequency…many conditions. Call it “Conditional Scanning”.
Since frequencies are reused all across the country, and many times used with different modes and access methods, it makes sense to build the database that addresses the “condition” and “location” on a single frequency instead of the other way around. The SAVINGS would be enormous. And you could even add a “Discovery” option to the list of conditions with lockouts for known access codes, talk groups, locations or other system details. That could be recorded with audio (or without) and stored in a sortable list with ALL the mode information and access parameters logged…everything. That list could even be a living database itself for managing everything detected and keeping track of it all. You would probably need the location of the station that heard the specific activity stored in the log files for identification and coverage verification, but that is easy enough…even if you put a manual lat/lon location in your fixed station scanner. You could even have coverage of the specific condition (from base or GPS tracking mobile units) automatically plotted on a google map! Add the ability to “upload” and share data (user selected…some yes, and maybe some no), and you have true power to build a national database with little effort needed by human intervention other than adding identification name tags to what was automatically acquired (collected) in the field. Now that is powerful scanning, searching and database management!
So you have a frequency like 172.0000 MHz. First layer is check boxes for the modes you want to hear:
- P25
- DMR
- NXDN
- Fusion
- D-STAR
- Analog (Coded Squelch only option default, CSQ after no coded squelch detected checkbox option)
Then you have a sub-layer for each mode with different access details for each “channel”. Since encryption is often used, and may not be worth wasting time on by stopping on it, make each “channel” have the option to stop or pass (default) on encryption. Each “channel” has a name tag, delay setting, alert light/sound option, digital threshold adjustment (defaulted to the most common user defined “general” value, if not addressed), rectangle(s) for location control (optional), and can be assigned to a scan list…which then can be assigned to a scan group with multiple lists. If you are “out of range of anything defined” (by using location control), skip the frequency from being scanned altogether (saves a lot of time!) unless you are searching for unknowns in a type of discovery mode. But it is important to allow total control over conditions. The CSQ (carrier squelch) option is the last resort if all other “intelligent” access control options are exhausted (bottom of the list). Some frequencies may indeed be used with analog carrier squelch only, but you would probably want to limit the coverage area of such type reception and make sure it is on the bottom of the list of any other conditions that may be enabled. And there are times you want to detect any type of signal to verify activity or frequency conditions...like with a Monitor button (could be interference or an undefined type of data transmission), but that can have the potential to lock up scanning on noise . Same with encryption however, it is important to capture any usable intelligence (such as NAC codes or User ID / TG) if it is there, even on encryption or data when you want to. You may just need a “grab and go” option while searching (or discovery operation) to prevent unnecessary hang-ups. And remember, data (without voice) going across a system has lots to offer and may be worth logging (at least once). You may not want to hear it or spend a lot of time on it, but it has value for identification purposes. You may want to track it to plot coverage, if nothing else, but not hang up on it all day.
Trunked systems? Yes, I know this primarily addresses conventional use, but trunked systems already do this type of scanning when you think about it. We all encounter the trunked system activity on conventional search, but even that has value and could be used for harvesting data. More thought on how to handle that scenario might be needed (WIP). But we all know that everything we hear out there is not always listed in the FCC database…or sometimes anywhere else for that matter. Searching is still very relevant and useful. But let the scanner manage the unknown data in a way that makes it easy to sift through the known data (search between the cracks and log the results).
There is so much potential in this type of operation. You could even make an interactive map that plots system coverage based off of user reception location and signal strength data. It could even plot tropo conditions! If you ask me, this is the future of scanning. Good software could make it easy to manage. No need to be all that complicated about it. Excel type export/import functions with all the copy/paste/cut/insert/delete options would make maintenance a snap. But you had better put the fastest processor you could practically manage in a scanner like that. You don’t hear what is waiting to be picked up by slow scanner! (like my x36 scanners) And you don’t want the beginning of each transmission being clipped by a slow processor looking for matching conditions. Speed is paramount!
Phil
There are digital modes that go beyond DMR, NXDN, P25, etc... one of which includes Yaesu's System Fusion mode utilized by amateur radio operators. Also, take into consideration that some of us have an interest in decoding certain data modes (including APRS) for example. It's really not much to ask for, all things considered.
That won't happen if the incoming signal is buffered while the scanner is attempting to decode the signal. It will increase latency a bit, but you'll get the entire transmission.
The conditional scanning thing sounds nice in theory, but in practice, it's unlikely to speed scanning up much. Most areas don't have multiple entities broadcasting on the same frequency, for obvious reasons. The only time it is likely to help much is when the database has crappy data and lists all state parks separately in a single Department, even though they all use the same frequency. Putting each park in a separate Department with its own GPS coordinates will eliminate the same frequency being scanned 15 times, without having to redesign the scanner.
SOFA_KING
Member
I have a lot of stations on the same frequencies that can be received at my home location. It happens a lot in the federal world. So either I have to scan with "code search" on using one channel, and remember which areas use what codes...across multiple agencies at times, or if I want the correct name tag I have to scan the same frequencies multiple times on different channels with different access codes, which really slows down scanning and acquisition time. This is not practical. And some systems are intentionally designed that way in an entire region so different towers can be selected. It is stupid to have to enter the same frequency multiple times, but you want to know which transmitter you are listening to. We need a better way to manage frequency use.
Besides, there were more ideas to the post than just that aspect of it. These were good advanced ideas that would make database management easy...and potentially automatic. The old way of doing things is just not practical anymore. We need a better approach.
Phil
seth21w
Member
#1 PRIORITY LSM PHASE 2 SIMULCAST RECEPTION!
#2 Lithium ion battery pack and drop in charging dock, with 12 hour + battery life.
#2 Lithium ion battery pack and drop in charging dock, with 12 hour + battery life.
gwtc199
Member
I'd like to see a true ISO mount scanner, the 536's faceplate is too big to fit some installations. Taking the outer trim on the faceplate and making it removable so the front is the same size as the body of the scanner would be better.
Nothing left to listen to soon. I just don't honestly care anymore as a result.
I would really like to see the SDR market to continue to really take off with that kind of technology.
Software based radio has no limit. It just depends on programming and programmers to kick into high gear.
The scanner market has peaked with Phase I and II as well as DMR - MotoTrbo - and NXDN. There is nothing else scanner manufacturers really can do except to get the streaming for your radio dialed in.
That's about it. With more and more cities and counties locking down their systems the market will never be-able to grow at this point. We have already seen Mount Everest. Not sure where there could be any growth at this point. We have maxed out the potential of a scanner radio.
Software based radio has no limit. It just depends on programming and programmers to kick into high gear.
The scanner market has peaked with Phase I and II as well as DMR - MotoTrbo - and NXDN. There is nothing else scanner manufacturers really can do except to get the streaming for your radio dialed in.
That's about it. With more and more cities and counties locking down their systems the market will never be-able to grow at this point. We have already seen Mount Everest. Not sure where there could be any growth at this point. We have maxed out the potential of a scanner radio.
SOFA_KING
Member
No, not maxed out. Plenty yet to hear.
If you don't like what the government you elected is doing, tell them you don't like it. Demand change. If they don't respond, try something different next time. Get involved in the primary process and promote politicians who answer to the people.
Not only did I talk to top officials who were contemplating encryption on a new system being constructed for my county right now, but I even talked to the radio sales and maintenance people about it. They actually feel the same about it and are trying to urge the Sherrif and others not to go to total lockdown. If they still do, then the best we can do is show up at council meetings, vent our dissatisfaction, and then vote them out.
Back on topic...there is plenty of advancement left to acomplish, and plenty to hear. However, if they STOP advancing the features people want, then the scanner market will surely fade away. In my opinion they are years behind where they should be right now. That's not good for sales.
Phil
If you don't like what the government you elected is doing, tell them you don't like it. Demand change. If they don't respond, try something different next time. Get involved in the primary process and promote politicians who answer to the people.
Not only did I talk to top officials who were contemplating encryption on a new system being constructed for my county right now, but I even talked to the radio sales and maintenance people about it. They actually feel the same about it and are trying to urge the Sherrif and others not to go to total lockdown. If they still do, then the best we can do is show up at council meetings, vent our dissatisfaction, and then vote them out.
Back on topic...there is plenty of advancement left to acomplish, and plenty to hear. However, if they STOP advancing the features people want, then the scanner market will surely fade away. In my opinion they are years behind where they should be right now. That's not good for sales.
Phil
Drumbum
Member
I have an SDR and prefer to use my Tapped BCD396T. better sensitivity .I also can use Proscans band scope for hits while DSD+ decodes
Sent from my VS986 using Tapatalk
- Status
