I believe the PSR800 was designed to be used in simple ways to make it easy for a novice user to get up and running. This means one of two things:
- a simple "standard" load of a system with a few options like which agency categories/groupings (for conventional frequencies), trunked sites and categories (e.g. RR grouping like "Fire", "Police", "Services", etc. )
The user has the option of loading some or all of the system in placing the data in one or more scanlists. However, there are some limitations.
- a "location based" (city, zip code, etc.) load. This uses location and the RR "tags" ("Law Dispatch", "Law Tac", "Interop", etc.) categories and allows the user to select which of those categories they want loaded. Of course, this gives you less/no control over which systems and conventional frequencies are loaded. It also automatically assigns the frequencies/talkgroups (objects) to a scanlist that matches the tag values.
But you know all of that already....
If the software (either on the radio or in EZ Scan) maintained all of the control (i.e. use the "location" based imports/loads), it could probably do more to provide a better "update" process that reflects the RR library updates each week. But given that users have the first option (standard imports) and also completely manual programming options via EZ Scan, it's nearly impossible to perform updates against that programming without likely messing it all up and irritating the user.
If GRE were still working this (and the software doesn't already work this way), I'd recommend that if the VScanner/VFolder is set to "Set Location = ON", the configuration should maintain how the import was performed (i.e. which City and/or Zip codes and TAGS were used on the import) and perform the update using those same options (to include import of new things that match). Of course, the user in this case would ceding all control to the software (Note: if the software detects even the slightest manual "tweaking" in the Vscanner/Vfolder, it would then need to just do the update style it does today.
Anything can be done with the software with unlimited funding and time - but that's never the case or an option.
As far as how I program --
Like many other users, I migrated over time from radio to radio with the last before my PSR800 being the PSR500. The 500 gave me alot of options (LED and alert settings, ignore status bit, etc) that I used. Additionally, I've always tried to split trunked systems across multiple scanlists for beyond even the RRDB categories or TAGS, For example, programming of my home county system:
Scanlist 1 - Fire Routine (dspatch, medical calls, etc.)
Scanlist 2 - Fireground
Scanlist 3 - Fire Admin
Scanlist 4 - County Police Routine
Scanlist 5 - State Police
Scanlist 6 - Sheriff
Scanlist 7 - Airport Fire
Scanlist 8 - Airport Police
Scanlist 9 - Police Priority Dispatch
Scanlist 10 - Emegency
etc. - you get the idea
The last two are interesting in that the system is a Motorola which when using the status bits, allows for detection of things like a radio's emergency button being pushed and when patches are setup (in most cases for this system indicates a priority dispatches over several talkgroups simultaneously).
Then of course there are the options/ability to configure lights and audible alerts...
All of this is custom because before the EZ Scan radios and Uniden's HP-1, everything was custom. Some of us went much more custom than others.....
When I started with the PSR800, I made every attempt to carry over this custom programming. It can be tedious but it's really about what you want in your programming. But that comes at a cost. That is a decision you are making at the start and when you do, you've committed yourself to custom programming that can be difficult to maintain and/or change over time - particularly for a system that is new and/or constantly changing. However, those of us who do this type of programming see this as a big part of the hobby and love all of the "nerd knobs" or bells and whistles.
Over time I've moved away from significant custom programming but mostly because I'm more interested these days in tracking new systems and identifying new talkgroups (I'm not the basic "listener user"). The majority of custom programming I do now is limited to:
- always manually setting the backlighting and recording options
- splitting trunked system sites (and sometimes even the control channel frequencies) over multiple scanlists (which means using the "duplicate system" option in EZ Scan software and then locking out sites and frequencies).
- SKIP or LOCK out known talkgroups to focus on the new/wildcard hits
Having said all of this - it's obvious that the PSR800 was not envisioned to be a "nerd knob" radio. To understand this, take a look at all of the settings the PSR500 provided and compare that to the PSR800 setting options. Huge difference. Even more obvious is the lack of a alphanumeric keypad on the PSR800. It was intended to increase the user base (which would be great for all of us for many reasons) by lowering the bar to entry and simplifying use for the inexperienced user while also providing a few of the basic bells and whistles that could optionally be used by the more experienced user. Again, it's a question of time and money how much is included in the radio and you can never be everything to everyone...
The two things I'd consider (if not cost prohibitive) in improving on the PSR800 would be:
- bring the alphanumeric keypad back
- provide two clear and distinct types of firmware that could be installed at the user's wish on the radio:
NOVICE: a true novice user EZ Scan/PSR800 type (scaled back version of the current PSR800 design)
ADVANCED: something closer to the PSR500 firmware that includes the basic import programming option which could then be tweaked through the keypad or PC software
As a huge bonus - rather than making the choice of these options at the radio (global) level, make these options at the VScanner/VFolder level (e.g. folder 1 could be a NOVICE folder and folder 2 could an ADVANCED folder).
