New Uniden Scanner announcement at SEMA 2025
- Thread starter communicore_
- Start date
One thing to do is only enable the "Service Types" your interested in...
Work they say?! I’m in!
What’s pulled in via zip code and or gps is determined by the range you have set. Some stuff in the database has huge ranges set and even thought it’s far away from you, it can overlap your range, even at 0. That’s the reason why that happens.
So if that’s happening to you now, it will do the same on the 150.
Whether you use a GPS, or manually enter your location by zip code, or actual latitude & longitude, there is no difference in the range for systems to monitor. Using a zero for range in your scanner, you'll still hear systems & channels that are in the range setting in the database. The range the scanner uses in determining which systems to monitor is the sum of the range you set (in the scanner) and the range of the system or site as listed in the database. Imagine a circle with a radius of, say, ten miles for a system. Now, imagine a circle with a radius of what you set in your scanner. If these two circles intersect, that system would be scanned. Even if you set the range in the scanner to zero, if your location is within the range radius for the system, it would be scanned. See this for a more complete description of how location & range works.
That's especially true for systems in the "nationwide" category.
I ALWAYS use "zero" I want to hear what's in front of me, not behind me..... I have asked UJE for exactly that, GPS is very precise (within a few meters) at its best. If anyone has an algorithm please share
.
If there was only a way to not scan those encrypted talk groups while GPS scanning by adding a few new Service Type categories like...Law Dispatch/Tac/Talk ENCRY....Fire Dispatch/Tac/Talk ENCRY. The database administrators would have to update those talk groups to reflect the new Service Types, and a new Sentinel and Firmware would have to be updated so each user could modify the preferred Service Types they'd like to monitor. Many systems, especially statewide systems have encrypted talk groups that the scanner will "skip" but does a momentary "pause" no matter the range setting and delays scanning and causes users to potentially miss the first part of conversations. Just a future suggestion...
Ubbe
Member
Its easier to comprehend if just saying that a range set in the scanner will be added to a sites range. If a site has a 25 mile range and the scanner are set to 5 miles then that site will have a 30 mile range.
/Ubbe
Ubbe
Member
I've suggested a setting in the scanner for ranges that allows a selection of "Use DB/FL ranges" or "Use own range of XX miles" for sites as well as allowing both negative and positive offset values to its current scanner range setting to be added with a minimum for a site to not be lower than 5 miles or so.I ALWAYS use "zero" I want to hear what's in front of me, not behind me..... I have asked UJE for exactly that, GPS is very precise (within a few meters) at its best. If anyone has an algorithm please share
The scanner will have to detect when a minimum distance have been reached in your position, lets say 3 miles from the latest stored value 3 miles ago, to be able to tell in what general direction you are travelling, not to false trigger whenever you make a turn, and then the scanner would calculate the same longitude and latitude changes times 5, probably a user selectable multiply value, and add to your current GPS position and use that value for site selection and unselection.
It shouldn't be more than a 5 minute job to the firmware to check if "scan ahead" are enabled and add that offset value to the location when it checks sites locations and ranges. But I don't know how useful that "scan ahead" feature would be to most scanner users. It would probably be more suited for a DIY project using a Raspberry Pie or Ardunio processor between GPS and scanner to convert location data to fool the scanner thinking you where way ahead of your current position.
/Ubbe
GPS sets the location. period,full stop, that is ALL that it does. No difference if you use a zip code, set a lat/lon. etc.
While I agree in principle, this would be quite a clunky approach in terms of relational data. You have one true or false parameter that you are trying to apply to an entry: Encrypted or not encrypted. Rather than creating 25 new tags, this data should be stored in its own field. The Home Patrol Database (HPDB), as we all know, is created from the RR DB. The RR DB sports a column called "Mode" for both conventional and trunked entries. If the value of this field ends in "E", the channel is encrypted. It seems that the HPDB does not implement this field, but that can change. This would require adding a field in Sentinel under both conventional and trunked ("T-Freq" and "C-Freq" in *.HPD terms) channels, updating the sentinel UI to support these new fields, adding a setting along the lines of "ignore encrypted channels" with a scanner menu entry (via a firmware update) and a sentinel UI, and it would also necessitate updating whatever mechanism is used on their end to export the RR data and build the HPDB to look at the value of the mode field and set the encryption flag in the HPDB.
Alternatively, they can make the edit to the HPD data under the hood, and provide the option when updating the database to automatically apply "Avoid" to all encrypted channels and talkgroups. This would require them to store the encryption flag and update the HPDB accordingly, but would not require a UI overhaul or a firmware upgrade for the scanner. It would just require a small Sentinel patch. The HPDB is downloaded in one large HPD file and then "built" into multiple per state files. If the master file would store the encryption flag, Sentinel can use this data to apply avoid to all the encrypted channels while building the per state files. There would only need to be a single checkbox somewhere that you can tick that says "Apply avoid to encrypted frequencies while building the Database" or something like that. This would most likely be the least expensive to implement, and would achieve the desired functionality of allowing us to leverage the power of the RR DB to quickly lockout/avoid encrypted channels and talkgroups, and would definitely be a welcome feature.
How long does it take to recharge the battery? @jasonhouk
The "Jon" internal GPS works within seconds
GPS acquisition can be dependent on alot of variations. I don't think its fair to say one gps is better than the other.
Agreed, I was indoors under a metal roof! 🤣
CollinsURG
Member
- Joined
- Jul 19, 2025
- Messages
- 137
- Reaction score
- 173
There is cold start (takes minutes) and warm start (takes seconds). If a GPS receiver has recent almanac data it just needs to update ephemeris data. If it has been off a long time or the location has changed by a significant amount since last startup, then it will have to locate satellites again and update the almanac. Obstructed views will slow down data acquisition depending on the density of the obstruction.
Last edited:
I'm just taking a guess here...
You probably can turn the GPS off in the 150 thru the menu when not using it...
The mod that Jon was doing I believe the GPS board was always powered using it or not... Hence the quick acquisition...
You probably can turn the GPS off in the 150 thru the menu when not using it...
The mod that Jon was doing I believe the GPS board was always powered using it or not... Hence the quick acquisition...
Good guess, you can enable or disable the GPS through the settings menu.
Last edited:
Jason, any luck comparing the 2 radios on air band? Know your busy but would like to see that comparison.