mtindor said:
I think here is where we always have problems. You and I consider different things as 'bigger issues', at least in some cases.
And that might very well be part of it.
For instance, the alpha tagging of TSYS frequencies is a moderately sized issue for me that I think either (a) can be addressed very easily with no impact to those people who never alpha tag trunked frequencies and with minimal impact to those who would alpha tag by virtue of them losing some possible storage for some other talk groups, or (b) cannot be addressed because allocating the needed space for the additional information would mean that all users, not just those wishing to alpha tag TSYS freqs, would have less storage of talk groups as a result. It has yet to be determined (or nobody has of yet totally convinced me that B is the absolute fact).
I couldn't make any factual comments or even strong opinions about this one as far as being possible or not since I'm not quite familiar with the inner workings of this scanner. But I tell you something in your favor, for the longest time we were told there was all kinds of barriers that would make it very hard to have more than 200 TGs or so in scanners. And look what we have now: we can virtually have up to 1800 hundred of them in just one system! Of course, that took several generations and completely new radios and technology to accomplish. But still....
I expect alpha tagging of trunked frequencies - The 396/996 were out first. If they do it, this should [or should have been able to].
Well, yes and no. They're very different scanners and memory structure. And they both have 'fixed' things in software and hardware. This could be one of those things that are fixed on the GRE. I don't know.
One more thing to consider, there's this ugly thing called PATENTS, which wouldn't surprise me that Uniden could've patent in a very wide manner anything related to that kind of feature. It's not impossible for that to happen. I've seen a lot of hard to believe patents out there. A recent example was the company that wanted to patent the acronym for Push-to-Talk: 'PTT'. Go figure.
But the feature belongs there and should have been planned for. (this the first actual "bash" against GRE)
I think this is where I have my objections about some of the stuff you and others are requesting (almost demanding) and how. I can agree with you if it was something detrimental to the functioning of the scanner. Maybe the STAT "issue" is kind of detrimental depending on who's point of view you're on. But this CC alpha tagging I really consider it a "trivial" or "cosmetic" preference. I know we both have listed our reasons to think our way, so the only thing we can do is stay in disagreement and wait for GRE to do something or not.
I think it should behave the way I stated, and I believe that making it option-based would be kind of silly because it goes against what multisite STAT is supposed to do [at least my interpretation].
I don't think the option-based thing is silly. And STAT is more about how the radio uses the programming based on the type of system. Like Simulcast system are better setup using ROAM. If it wasn't for STAT, we would have to setup everything like in the BCD396T, every CC in it's own system and so on. But we already have a really similar option like what I'm suggesting with STAT for when you do a search linked to the regular scanning cycle. And it's a very good point to bring up since it's illustrates my concerns about changing the way STAT works from another point of view, perhaps a clearer one.
I have a search setup for 162.000 to 174.000. I have it assigned to a scanlist that I can turn on and link to the rest of the primary stuff I scan regularly. At first I noticed that the scanner would search the WHOLE range at once and took a while as expected to go from 162.000MHz to 174.000MHz in 12.5kHz steps. Because of that and needless to say, I didn't activate that search often.
Later I found the option called "SearchTunes" which when set to 0, it searches the whole range of frequencies that you set up per scan loop. Or you can input any number between 1 and 9999 which refers to the amount of frequency steps the scanner will search before moving on and scanning the next TSYS or CONV. object. In my case I'm using 150 which it's really adequate and only spends about 2 seconds searching a chunk of the range per scan loop and moves on and comes back later to where it left off for another 2 seconds.
I haven't decide yet which way I would prefer for an option like that to function on STAT.
One way is to have the option to tell the radio the amount of CCs to be scanned per TSYS before moving on. You could set it to '0' to have the radio scan the whole TSYS and every CC in it before moving on like you want. Or you can tell it how many CCs to scan befoer moving on.
Another way could be to have the option to tell the radio how long should it spend on each TSYS. Like a delay to spend on each TSYS regardless of how many CCs it has scan before moving on.
Yet another option in conjunction with all this would be an on/off selection which when OFF it would behave like it does now and when ON, it would follow the options describe above. Or vice-versa.
No matter how you slice it, it still comes down to delay. It isn't additional delay being imposed because it's a multi-STAT object done Mike's way. It's additional delay that is going to be there no matter how you do it, by virtue of anyone's wanting to scan umpteen TSYS's.
So I don't think it is any worse with my suggestion than it would be to substitute a multisite STAT TSYS for multiple regular TSYS objects that covver the equivalent listening area.
Well, once again and in my opinion, yes and no. If someone has 6 different Public Safety trunked systems all setup with multiple CCs in STAT mode. By virtue of what scanning is, which is getting a quick sampling of everything you have programmed in order to get the "big picture" of the action around you, I would think it's more beneficial to accomplish that by having the scanner sample one CC from each TSYS at at time and a different one on every scan loop.
Otherwise, done "Mike's way", you can have the scanner stuck for a long time in just on TSYS like I've shown examples of before and it could all be "mundane" traffic like records checks while you could be missing a police pursuit in another TSYS.
In other words, once you find something of interest to you from the "big picture" sampling of each TSYS, then you can pause and or zoom in the action.
I doubt that. I can see how this would appeal to you. But you do realize that if you have 5 or 6 sites in that STAT TSYS object and it bails out after hearing a TG on the first site CC, then you're going to miss the conversations that may be found on the other CCs because it bailed out to scan other TSYS or conventional objects. It's the same as I'm talking about above. It's an inherent delay, or potentially less delay with more of a priority to other objects versus the full scanning of the STAT TSYS object. Somewhere along the line, with all of this scanning of multiple TSYS objects (or a single TSYS multisite STAT object) incurs delays that eventually become unbearable and make the system not worth scanning. That's just an individual breaking point, that is different for each user.
Mike
The more we discuss this STAT thing, the more obvious it becomes that it's a personal preference more than anything. The less stuff you scan at once, the more insignificant the "issue" you're bringing up about STAT. If somebody only has 2 scanlist with less than 30 frequencies in each, it should take less than 2 seconds to go back to the STAT TSYS.
There was a similar issue, one of many, with Uniden's CloseCall on the BCD396T. Some people would complain that their regular scanning was getting interrupted every 2 seconds for CloseCall to do it's thing. Well, that's to be expected just like the regular Priority feature we've had for so long. But still, people were bent that they didn't like the interruptions to their transmissions. YET, just as many people liked it the way it was since you'll be most likely to catch a transmission that way. How Uniden solve the "issue"?
They made the
option called: Close Call Do-not-Disturb. Which would check CloseCall only when the scanner was idle and not currently monitoring a transmission. The only catch? It was implemented in their next mobile scanner (BCD996T) and not in the current handheld where the idea originated. Either way, OPTIONS are not a bad thing.....
