I've been thinking this over for several years and believe it is worth bringing up here. This is not meant to be a complaint so much as an encouragement for Uniden to reconsider their DMA architecture to better serve the customer base. I own a BCD436HP and have previously owned a GRE PSR-800, which is essentially now branded as a Whistler WS-1080. Having said that, I'm very familiar with both styles of programming and understand the pros and cons of each.
In most cases, people wish to program their scanner for a particular region, most of the time for the area they live in. While they may desire to program in other regions for travel, etc, it doesn't change the fact that they are monitoring a particular set of "systems", be they trunked or conventional. As they go about their ordinary use of the scanner, they may have different favorites lists for different areas, schedules, or other purposes. However, whether they are listening to one part of a system now (for example, fire calls), and another later on (police calls), they are still listening to the same system. Perhaps there would be a time when they would desire to listen to both police and fire calls. This is where it gets unnecessarily complicated...
With the current architecture, you would have perhaps a single favorites list with the local trunked system. Now you have to remember which "department" you have programmed into which quick key for that system in order to listen to either police, or fire, or both. If you then say that you don't want to have to remember so many quick keys (favorites, system, department), you could instead set up your scanner to use two favorites lists. Each list would duplicate the exact same trunked system, but would only have the selected department(s) enabled or programmed for that list. That sounds a lot easier for the typical scanner user; now you just remember which favorites list has police and which has fire, etc. But now the scanner scans the same trunked system twice, with each scan looking for different active talkgroups. Isn't there a better way?
This is where I think the problem lies. In reality, Uniden should follow the same idea that Whistler has regarding scanlists, even if they would be implemented as favorites lists in a similar fashion to what they have now. Each actual trunked system (and conventional channel or system) should be programmed into the radio only once. And then the scanner is only going to scan each system once, looking for all active talkgroups (from every active favorites list) on every scan of the system.
There should be two separate, isolated menu items for programming. One would be for programming in systems and departments. The other would be for programming in favorites lists. The systems would be added individually, with absolutely no duplication unless fully intended by the end user through programming. The favorites lists would be added in a similar fashion to how Whistler handles scanlists and scansets. You would set up the same favorites lists (up to 100), however you would select the particular departments and channels from the programmed systems and add them to the favorites lists.
Uniden has better scanners, in my opinion. They have all the bells and whistles. They have Discovery Mode, Analyze Mode, Quick Search, etc. But this programming flaw really makes it frustrating for a serious user to program the scanner. If you were going to utilize all 100 favorites lists in a particular area, you would end up with a lot of duplicated systems. Then when changes are made to those systems, whether it's new or modified talkgroups or additional radio IDs added, all of the lists have to be updated instead of just one. Whistler's architecture makes so much more sense, and it doesn't seem to me that Uniden would strictly have to keep their current architecture, as these changes have to do more with the way the firmware handles the hardware rather than how the hardware handles the radio, etc. Yes, it would be a major firmware revision. But it would be worth it.
In most cases, people wish to program their scanner for a particular region, most of the time for the area they live in. While they may desire to program in other regions for travel, etc, it doesn't change the fact that they are monitoring a particular set of "systems", be they trunked or conventional. As they go about their ordinary use of the scanner, they may have different favorites lists for different areas, schedules, or other purposes. However, whether they are listening to one part of a system now (for example, fire calls), and another later on (police calls), they are still listening to the same system. Perhaps there would be a time when they would desire to listen to both police and fire calls. This is where it gets unnecessarily complicated...
With the current architecture, you would have perhaps a single favorites list with the local trunked system. Now you have to remember which "department" you have programmed into which quick key for that system in order to listen to either police, or fire, or both. If you then say that you don't want to have to remember so many quick keys (favorites, system, department), you could instead set up your scanner to use two favorites lists. Each list would duplicate the exact same trunked system, but would only have the selected department(s) enabled or programmed for that list. That sounds a lot easier for the typical scanner user; now you just remember which favorites list has police and which has fire, etc. But now the scanner scans the same trunked system twice, with each scan looking for different active talkgroups. Isn't there a better way?
This is where I think the problem lies. In reality, Uniden should follow the same idea that Whistler has regarding scanlists, even if they would be implemented as favorites lists in a similar fashion to what they have now. Each actual trunked system (and conventional channel or system) should be programmed into the radio only once. And then the scanner is only going to scan each system once, looking for all active talkgroups (from every active favorites list) on every scan of the system.
There should be two separate, isolated menu items for programming. One would be for programming in systems and departments. The other would be for programming in favorites lists. The systems would be added individually, with absolutely no duplication unless fully intended by the end user through programming. The favorites lists would be added in a similar fashion to how Whistler handles scanlists and scansets. You would set up the same favorites lists (up to 100), however you would select the particular departments and channels from the programmed systems and add them to the favorites lists.
Uniden has better scanners, in my opinion. They have all the bells and whistles. They have Discovery Mode, Analyze Mode, Quick Search, etc. But this programming flaw really makes it frustrating for a serious user to program the scanner. If you were going to utilize all 100 favorites lists in a particular area, you would end up with a lot of duplicated systems. Then when changes are made to those systems, whether it's new or modified talkgroups or additional radio IDs added, all of the lists have to be updated instead of just one. Whistler's architecture makes so much more sense, and it doesn't seem to me that Uniden would strictly have to keep their current architecture, as these changes have to do more with the way the firmware handles the hardware rather than how the hardware handles the radio, etc. Yes, it would be a major firmware revision. But it would be worth it.
