PSR-500 multi-site roam settings

[kikito]

If you are in ROAM, in an area with multiple sites, and the scanner locks in on the cc of the best site, aren't you potentially missing traffic on other sites that STAT would likely find? I understand your stating you don't mind missing marginal or weak traffic, but I don't think I would want my scanner to park on site A and potentially pick up nothing, and miss what was going on on sites B, C, and D, all in my listening area. One could miss a ton of traffic.

That all depends on the type of system and how is setup. What you mentioned is true but not on all systems. Some systems simulcast the same thing on all sites.

Our P25 Smartzone Omnilink trunked system I set it up in STAT because like you said, there's potentially different traffic in every site. But we also have a Motorola Smartnet with several sites and that one I have it set up with ROAM since all the sites broadcast the same thing simultaneously. In that case I want the radio to lock on to the strongest site.

 

[bacon]

CC Hits: Multi-Site “STAT” vs. “OFF”

System: Indiana Project Hoosier SAFE-T (Motorola Type II SmartZone Omnilink)

I have been comparing my PSR-500’s trunk tracking performance with Multi-Site “STAT” vs. Multi-Site “OFF”. I decided to do the comparison when I noticed that with Multi-Site “OFF” I would always have 5 bars on the S-meter (scanning or analyzing only CC of site closest to me) but with Multi-Site “STAT” I would rarely see 5 bars on the S-meter. I have come to the conclusion that STAT option does not work very well. Here is why…

As a control, I used my Uniden BCD396T to monitor just the site closest to me (which also has the strongest signal). While in STAT mode, the PSR-500 missed about 90% of the traffic from that site even though there was no competing traffic from other sites' CCs. In Multi-Site “OFF” the PSR-500 kept up with or even out performed the BCD396T.

ITItseems that when STAT is enabled the PSR-500 does not consistently sample all CCs on each pass. I did have conventional channels sharing the same scan list with talk groups from this system as suggested earlier in this thread by Statevillian but it did no help. In addition, I also tried moving the closest/strongest site CC from the CC01 to the CC02 position but it didn’t help either.

I was wondering if anyone knew if GRE is aware of any issues with Multi-Site STAT or ROAM and if they are planning on addressing it in the next firmware update?

If this has already been posted about, I apologize and ask to be directed to the thread where I can read about it. Thanks.

 

[randyK]

Monitoring a local multi-site system in "Stat" mode with only 4 sites programmed, on each pass it would only lock onto one control channel. The next pass it would lock on to the next control channel & so on until it got back to the original control channel. But when it was the only active scanlist, then it would go directly from one control channel to the next, etc.
But I guess if it checked all control channels every pass, there would be several seconds of scan time you're missing from the other systems. Randy

 

[kikito]

As a control, I used my Uniden BCD396T to monitor just the site closest to me (which also has the strongest signal). While in STAT mode, the PSR-500 missed about 90% of the traffic from that site even though there was no competing traffic from other sites' CCs. In Multi-Site “OFF” the PSR-500 kept up with or even out performed the BCD396T.

This possibly has been brought up by me and others in the past. Is the CC in question happen to be in the first slot of the CC list by any chance?

I noticed something very similar, if not the same, with any strong control channel I put in the first and sometimes second slot of the CC list. To make it work flawlessly I just put an unused or inactive/alternate control channel in the first slot.

I don't remember if GRE has recognized this as a possible problem.

 

[mtindor]

Randy,

I agree with your findings. If you are only scanning one scanlist and that scanlist only is associated with one TSYS object that is multisite STAT, it will go through each active CC and sample it. However, if you have more than one scanlist enabled or a scanlist with multiple TSYS objects and or a multisite STAT TSYS object and some conventional objects, it will only check one CC in the multisite STAT TSYS during each pass.

I don't particularly mind how that functions, but I'll give you a scenario that I don't like:

scanlist 1: about 10 conventional freqs
scanlist 2: associated with a TSYS object set up multisite STAT

If you enable both scanlists, scanlist 1 effectively gets prioritized and the multisite STAT TSYS object essentially doesn't get fully checked on each pass... i.e, the scanning happens like this:

scanlist 1, freq 1 through scanlist 1, freq 10
TSYS object, first multisite CC
scanlist 1, freq 1 through scanlist 1, freq 10
TSYS object, second multisite CC
scanlist 1, freq 1 through scanlist 1, freq 10
TSYS object, third multisite CC
scanlist 1, freq 1 through scanlist 1, freq 10
TSYS object, fourth multisite CC
scanlist 1, freq 1 through scanlist 1, freq 10
TSYS object, fifth multisite CC
scanlist 1, freq 1 through scanlist 1, freq 10
TSYS object, sixth multisite CC

So if you have 6 site CCs in a multisite STAT TSYS object, then it takes 6 full scan runs to check all of that multisite TSYS object, and at the same time the conventional scanlist 1 was checked thoroughly 6 times

Similarly, if you only have one scanlist and it consists of TGRP objects associated with a multisite STAT TSYS and CONV objects, then by the time the multisite STAT system gets totally scanned, each of the conventional objects have essentially been checked n * (# of active CC's in multisite STAT CC) times.

The only time that a multisite STAT TSYS object works like one would expect it to work (sequentially scanned, one right after the other), is when the scanlist associated with it is the only scanlist being scanned and that scanlist does not have any other objects in it besides TGRP objects associated with the TSYS.

So, if you want a multisite STAT setup to receive "equal time" being thoroughly scanned as other scanlists, you need to instead end up setting it up as (in my case) 6 separate standard TSYS objects (multisite off) with the frequencies for each site in its own TSYS object. In that way, the actual system with the multiple sites gets completely scanned during each scan run.

Sure, if you do it as described in the paragraph directly above, it seems a lot slower - in fact, is a lot slower - it is as slow as one would expect it to be if you were checking multiple site CC's per scan run. But, on the other hand you're multiple sites also got equal scanning time per scan run whereas they do not otherwise.

Mike

 

[fmon]

Mike,

Are you entering the same talkgroups in each scanlist for your 6 TSYS or are you using a wildcard?

 

[mtindor]

Mike,

Are you entering the same talkgroups in each scanlist for your 6 TSYS or are you using a wildcard?

A little of both. The system I am referring to in particular is the Ohio MARCS statewide system. I don't load all of the TGRPs. I feel that's foolish as in my area I'd only hear about 20 max except on a rare occasion.

I do my scanning in two ways:

Sometimes I use a scanlist with 25 or so TGRPs that is associated with a TSYS object called MARCS EAST - This is a multisite STAT TSYS covering six MARCS sites.

SOmetimes I use a separate scanlist that is associated with 6 TSYSs, each of which is one of the six sites out of my MARCS EAST coverage area). I have 25 or so TGRPs for each one of those in that scanlist.

I won't create a system without wildcards. I don't live in a major metro area - I'm perfectly fine listening to everything and anything - I have wildcards on all systems to make sure I don't miss any traffic, and if a new TGRP comes up that I find I should add I will add it.

I have both because sometimes I want to make sure it scans sequentially (I enable the scanlist for the non multisite TSYS's). At other times I'm nto as concerned, so I enable the scanlist for the single multisite stat TSYS.

Mike

 

[kikito]

So if you have 6 site CCs in a multisite STAT TSYS object, then it takes 6 full scan runs to check all of that multisite TSYS object, and at the same time the conventional scanlist 1 was checked thoroughly 6 times

Well, those are not exactly new findings, it's been known to work that way and possibly for a reason.

If I was to have even one active TG per CC on my TSYS list, of which I could have up to 8 active CCs at anytime, how long will it take before it finally gets to the conventional lists or other systems if it has to check ALL the CCs associated with that one TSYS first?

Using the default delay of 2 secs on TGs X the 8 CCs, it might take no less than 16 seconds before the radio scans anything else. Then the situation is effectively reversed (and probably worse off) and the conventional or other systems won't be scanned as often. Which one would you prefer?

Seems to me (and as my usual disclaimer, it's just my personal opinion), that the way it functions right now might be the best compromise. Of course this might be something that can be solved to everyone's satisfaction by giving us a menu option to control this behavior. I would stick with the current default, of course.

 

[mtindor]

Well, those are not exactly new findings, it's been known to work that way and possibly for a reason.

If I was to have even one active TG per CC on my TSYS list, of which I could have up to 8 active CCs at anytime, how long will it take before it finally gets to the conventional lists or other systems if it has to check ALL the CCs associated with that one TSYS first?

Using the default delay of 2 secs on TGs X the 8 CCs, it might take no less than 16 seconds before the radio scans anything else. Then the situation is effectively reversed (and probably worse off) and the conventional or other systems won't be scanned as often. Which one would you prefer?

Seems to me (and as my usual disclaimer, it's just my personal opinion), that the way it functions right now might be the best compromise. Of course this might be something that can be solved to everyone's satisfaction by giving us a menu option to control this behavior. I would stick with the current default, of course.

Perhaps not new findings, but findings nonetheless... and new to me. I sure wish I knew if you owned stock in GRE. You'll admit to absolutely no faults or problems with a GRE scanner.

Multisite STAT doesn't work like I believe most people would 'think' it should work based upon the documentation... at least not in the situation where its not the only item being scanned.

If it is only checking one site CC in a multisite stat system per each scan run, it absolutely is a shortcoming. You're right, it most definitely takes longer to check them all, and people want it to take less time. But with it taking less time (essentially only checking 1/nth of the system during any given scan run), you are losing conversations that way. Yes, if you have to scan each site in the system during each scan run, the additional delay also causes you to lose conversations. But that's expected either way.

Let me give you an example:

Let's say you have 9 active scanlists, each with 100 conventional frequencies, and then 1 scanlist associated with a multisite stat TSYS object that has 10 active site CCs in it.

Before every one of those 10 sites in that multisite stat TSYS get checked, the scanner first has to scan through at least 9 other scanlists of 100 frequencies each. That means that you're scanning 900 conventional frequencies x 9 (or 10) for a total of 8100-9000 conventional frequencies per each full scan of the multisite stat TSYS. That's just insane.

Every time I bring up a potential 'problem' or 'shortcoming' or 'non-feature' of the PSR-500, you are on it like flies on crap telling us how its a feature, or its an unrealistic expectation, etc.

Mike

 

[mtindor]

Before every one of those 10 sites in that multisite stat TSYS get checked, the scanner first has to scan through at least 9 other scanlists of 100 frequencies each. That means that you're scanning 900 conventional frequencies x 9 (or 10) for a total of 8100-9000 conventional frequencies per each full scan of the multisite stat TSYS. That's just insane.

How could this type of innefficiency be considered a feature / bonus / benefit in anybody's book? I don't want 900 conventional frequencies checked 10 times per every one time that my multisite stat system is checked. I want my multisite stat system checked completely every scan run, no more and no less... and I want my 900 conventional frequencies to be checked completely every scan run, no more and no less.

Sure, I can do it another way (as I have described that I already do on occasion), but that's not the answer. I see this as a 'bug' or 'shortcoming' in the multisite stat feature that it cannot fully scan all of the sites in that multisite stat TSYS object per scan run.

I realize the delay, but there is always a delay with scanning trunked systems... the more active CCs you scan, the longer the delay -- usually a number of seconds per CC. But teh alternative, which you suggest is a good thing, is to scan 1/10th of the system instead.

Mike

 

[bacon]

How could this type of innefficiency be considered a feature / bonus / benefit in anybody's book? I don't want 900 conventional frequencies checked 10 times per every one time that my multisite stat system is checked. I want my multisite stat system checked completely every scan run, no more and no less... and I want my 900 conventional frequencies to be checked completely every scan run, no more and no less.

Sure, I can do it another way (as I have described that I already do on occasion), but that's not the answer. I see this as a 'bug' or 'shortcoming' in the multisite stat feature that it cannot fully scan all of the sites in that multisite stat TSYS object per scan run.

I realize the delay, but there is always a delay with scanning trunked systems... the more active CCs you scan, the longer the delay -- usually a number of seconds per CC. But teh alternative, which you suggest is a good thing, is to scan 1/10th of the system instead.

Mike

Thanks everyone for all your prompt replies. I'm surprised this situation hasn't been addressed in more detail before. I totally agree with you Mike (mtindor). This is NOT much of a feature/bonus/benefit at all in my opinion either and I am very disappointed.

This TRS scanning is becoming frustrating and expensive. This is the second scanner I’ve purchased (BCD396T the first) thinking it would do everything I wanted only to find out later things don’t work quite the way I expected and/or how explained in the literature. My belief that STAT would first check all CCs sequentially in a STAT TSYS before scanning other TSYS or CONV objects is one of the main reasons I decided to purchase the PSR-500 in the first place. I think the way STAT is explained in the manual is very misleading.

It would be great if GRE would change the STAT feature to allow us to choose whether we want the TSYS to either check all active CCs or check only one CC per scan pass. For me, STAT checking all TSYS CCs every scan pass would be much faster than having to first scan through all the other TSYS and CONV objects in other scan lists before checking the next CC. I wouldn’t necessarily mind having to spend the extra time needed to check for activity on all active CCs. I would just place CCs in the order of which I wanted the TSYS to check first.

 

[kikito]

Perhaps not new findings, but findings nonetheless... and new to me. I sure wish I knew if you owned stock in GRE. You'll admit to absolutely no faults or problems with a GRE scanner.

Don't worry, I don't have stock at GRE and I do the same "defending" for all kinds of products, gadgets, computers, politics and so on. It seems that somebody needs to help balance out the "universal soap box" the internet has become for people to complain just about everything while offering no alternatives or solutions while expecting "somebody else" to fix instantly anything that they consider is wrong. That's all....

I did the same "defending" for the Unidens and just about any new scanner that comes out that I think it's worth defending from what I consider "trivial" complains. And I mostly state facts of how this scanner works and clearly state that it's my opinion when I think something "that ain't broke, don't need fixing". If it's working great for me and many others, why should I admit there's something "deadly" wrong with the scanner? I can't agree to something I'm not seeing or experiencing.

Multisite STAT doesn't work like I believe most people would 'think' it should work based upon the documentation... at least not in the situation where its not the only item being scanned.

And I offered some of the alternatives of how it would work like if it wasn't the way it was now. How do you suggest that this should work instead or be "fixed"? I'm open for suggestions as I'm sure GRE is also. The scanner is working as expected for many people and most are happy with it but obviously they can't make everybody happy all the time on everything.....

If it is only checking one site CC in a multisite stat system per each scan run, it absolutely is a shortcoming. You're right, it most definitely takes longer to check them all, and people want it to take less time. But with it taking less time (essentially only checking 1/nth of the system during any given scan run), you are losing conversations that way. Yes, if you have to scan each site in the system during each scan run, the additional delay also causes you to lose conversations. But that's expected either way.

So what do you suggest? Scan all the CCs at once from a particular TSYS and if it finds an active TG, when it's done monitoring it, it should skip to the conventional scanlists or other TSYS? Or should it look for more active TGs within that CC or finish scanning the rest of the CCs on that TSYS and stop on more active TGs along the way? And while doing all that you have spent over 10 seconds and counting in just a few CCs of that ONE TSYS.

Just saying the scanner should scan all the CCs in a TSYS before moving on to other systems or conventional will just "fix" it for some people and break it for other people. I value the scanning of conventional as much as the trunked systems I scan. So one way or the other it's going to affect one or the other. That's why I suggested that they should make it an user option how we want the scanner to behave when scanning combinations of trunked/stat/roam and conventional. Maybe they could make it like other options we have, like "SearchTunes", which you put a '0' to have the scanner go through the whole range of a frequency search or only do a certain amount of frequency steps before moving on to scan other stuff and come back to it where it left off. I have mine set to 150 on that one. For Multi-Stat maybe we can have '0' for scanning all the sites within a TSYS before moving on or whatever number of sites you want scanned before moving on, up to 31.

Of course, it could also be made simpler and just have an on/off option to behave like it does now or scan through all the CCs of a TSYS before moving on.

Before every one of those 10 sites in that multisite stat TSYS get checked, the scanner first has to scan through at least 9 other scanlists of 100 frequencies each. That means that you're scanning 900 conventional frequencies x 9 (or 10) for a total of 8100-9000 conventional frequencies per each full scan of the multisite stat TSYS. That's just insane.

I think it's insane to be scanning 900 frequencies all at once and not expect much delays! The typical amount of conventional channels that I scan regularly along with trunked systems in Multi-Stat is close to 150. That still pretty quick for the scanner to scan between conventional and trunked sites without much delays in either one (about 2 to 3 seconds on each). I have several hundred more conventional channels along with other trunked systems but I don't activate them often due to the obvious longer delays to go through everything and I would start missing some of the more important stuff I'm interested or care more about. The same scenario would apply to any scanner out there. And when I want to miss even less, I use more than one scanner at a time like many other people do, if it's that critical to monitor everything you want, especially over 900 frequencies....

Every time I bring up a potential 'problem' or 'shortcoming' or 'non-feature' of the PSR-500, you are on it like flies on crap telling us how its a feature, or its an unrealistic expectation, etc.

It's nothing personal against you even though we've been off on the "wrong foot" from the get-go. And like I stated before, I have agreed with you and others on many other things and suggestions for GRE but you're probably only seeing that I mostly defend this scanner, just like I mostly see you criticizing it, even though I do know you have praised it several times before.

 

[kikito]

How could this type of innefficiency be considered a feature / bonus / benefit in anybody's book? I don't want 900 conventional frequencies checked 10 times per every one time that my multisite stat system is checked. I want my multisite stat system checked completely every scan run, no more and no less... and I want my 900 conventional frequencies to be checked completely every scan run, no more and no less.

I personally never said it was a "bonus" or anything like that. I said something along the lines of being the best compromise to devote similar time to TSYS and CONV objects. Obviously, they probably didn't count on people wanting to scan over 900 frequencies all at once without considerable delays. If you're really scanning 900 frequencies along with trunked systems all at once and don't want to miss much, you should seriously consider getting more than one scanner. Even a cheap conventional-only scanner would do.

Sure, I can do it another way (as I have described that I already do on occasion), but that's not the answer. I see this as a 'bug' or 'shortcoming' in the multisite stat feature that it cannot fully scan all of the sites in that multisite stat TSYS object per scan run.

I don't think is because the radio can't fully scan all the sites per scan run since it obviously does it when your scanning the TSYS by itself. It was probably a decision that GRE made thinking it was the best compromise for most people scanning conventional and trunked systems at the same time. They probably can and might change it, so that hopefully they can make a few more people happy.....

I realize the delay, but there is always a delay with scanning trunked systems... the more active CCs you scan, the longer the delay -- usually a number of seconds per CC. But teh alternative, which you suggest is a good thing, is to scan 1/10th of the system instead.

Mike

The delays I was talking about is not just about scanning a CC, which this scanner can scan about 5 different CCs in about 3 seconds if it doesn't stop on any of them for activity. The delays and questions I keep bringing up is when there's active TGs on each CC.

If you have 10 active CCs in one TSYS and you get just one TG active on each, that would make scanning just that TSYS object alone to take no less than 40 seconds. And that's assuming a quick transmission of 2 secs long with the 2 secs default reply delay totaling about 4 secs total per CC going by the method some of you guys want. It would take even longer if the conversations on each TG are more than the 2 secs I factored in, which most times it will be. That's also assuming that you guys want the scanner to move on to the next active CC within the same TSYS after the TG delay runs out. People that have more than 10 active CCs (up to 32) in a TSYS set to STAT will obviously experience even longer times scanning just that single TSYS. By now, you're missing things in other systems and conventional. So once again the "compromise" word comes into play.

Is that what you guys want? You don't care much about any other systems or conventional? Because some of us do. So like I keep mentioning, if GRE changes the current behavior, hopefully they'll make it user selectable.

 

[kikito]

I'm surprised this situation hasn't been addressed in more detail before.

Maybe because it isn't a big deal for most?

This is NOT much of a feature/bonus/benefit at all in my opinion either and I am very disappointed.

Sorry you're disappointed, many of us aren't. With all the resources available out there (forums, Yahoo groups, downloadable manuals, GRE support website, etc.), if this was such a big deal, it would've come out earlier and would've been addressed by GRE with a firmware update fairly soon like they already did for a different issue.

This TRS scanning is becoming frustrating and expensive.

Maybe for you. The PSR-500 has met and many times exceeded my expectations just like for many other people. Is it a complete failure because so far less than a handful of people are upset about how it works in certain specific (and sometimes extravagant) situations? Not in my book....

I think the way STAT is explained in the manual is very misleading.

It seems to work as advertised for me.

You guys have all the right in the world to complain about something you think is wrong on a product you purchased. But I don't see why I don't have as much right to disagree with you and challenge your complains. After all, that's been done regularly in other forums for other brands too and in the end, it always benefits everybody since the manufacturers themselves are probably monitoring and taking notes of what we, the users, discuss about their products.

 

[kikito]

I sure wish I knew if you owned stock in GRE. You'll admit to absolutely no faults or problems with a GRE scanner.Mike

Did you missed my first reply that triggered this latest STAT argument?

As a control, I used my Uniden BCD396T to monitor just the site closest to me (which also has the strongest signal). While in STAT mode, the PSR-500 missed about 90% of the traffic from that site even though there was no competing traffic from other sites' CCs. In Multi-Site “OFF” the PSR-500 kept up with or even out performed the BCD396T.

This possibly has been brought up by me and others in the past. Is the CC in question happen to be in the first slot of the CC list by any chance?

I noticed something very similar, if not the same, with any strong control channel I put in the first and sometimes second slot of the CC list. To make it work flawlessly I just put an unused or inactive/alternate control channel in the first slot.

I don't remember if GRE has recognized this as a possible problem.

The question I asked about the problem has still not been answered. If we're not going to discuss more details about the problem and offer possible alternatives, why keep posting the complains about it? And that last sentence on my reply above means that I don't know if GRE has duplicated the problem and is adding a fix for it in the next firmware release.

Sounds to me like I not only admitted to a problem with the scanner but something that's also affecting me, even though I found a work-around.

 

[mtindor]

There are no alternatives to fixing the problem. Fix it, that's what it's about.

It's not about coming up with suggestions for workarounds to fix a broken "feature." It's about fixing the broken "feature."

What you are wanting is people to chime in and come up with alternative solutions to GRE having to do anything. Well, just like with Uniden, I expect GRE to pay attention to user input and make changes based upon that feedback. What I don't expect is to have to come up with workarounds to everything that you think is just fine and dandy the way it is. You aren't the only user of a PSR-500/600.

Mike

PS: I don't scan 900 conventional frequencies - It was simply an example

 

[Sownman]

If multisite does not work in the manner you feel it should you can enter it as 6 seperate sites instead. I don't see why that is a problem. I have been experimenting with the ICIS system in LA County. For two days I monitored and recorded hits with the 4 sites around me set up as 4 seperate sites 1 or 2 CC per site with 152 TGID per site. Now I have it set as one multisite with 10 CC and 152 TGID's. I'll monitor and record hits that way for two days and decide how I want to leave the scanner programmed. Maybe save both setups in different vscanners.

I know different areas and different experience levels might cause you to want what you want but frankly in my area just the ICIS setup with a few communities offers more to monitor than I can keep up with, When I add LAPD, LA county Fire and Sheriff, CHP, and aircraft back in it will just become a confusing blur.

Steve

 

[mtindor]

Agreed, I can do that... and I have. But right now I"m only monitoring one trunked system regularly that is multisite and a few other conventional frequencieds - so I don't mind that multisite stat isn't working like I think it should. But as soon as I add more systems, the fact that it doesn't work like I think it should work will be a problem and I'll have to resort to exactly what you said, separate sites.

I do happne to have the separate sites in, and I switch back and forth between the two ways of doing it myself just to make a final decision on how I like it.

If I could alpha tag TSYS frequencies (a whole other thread of discontent has already talked about this), then I would definitely want the multisite to work how I think it should work. But since I can't alpha tag TSYS frequencies and I want to know what sites the conversations are coming from, I'll probfably end up going with multiple non-multisite TSYS objects instead of the single multisite TSYS.

I still believe it's a "bug" that it doesn't work how I think it should. I don't think it was intentionally programmed that way, because it goes against how they make it sound like it should work in the manual. Bug or oversight, that's what I'm thinking. Whether it is something GRE is willing to work on is another story.

You're right though, there is an alternative and if I get desperate I"ll use the alternative. I would just prefer not to have to do that.

Mike

If multisite does not work in the manner you feel it should you can enter it as 6 seperate sites instead. I don't see why that is a problem. I have been experimenting with the ICIS system in LA County. For two days I monitored and recorded hits with the 4 sites around me set up as 4 seperate sites 1 or 2 CC per site with 152 TGID per site. Now I have it set as one multisite with 10 CC and 152 TGID's. I'll monitor and record hits that way for two days and decide how I want to leave the scanner programmed. Maybe save both setups in different vscanners.

I know different areas and different experience levels might cause you to want what you want but frankly in my area just the ICIS setup with a few communities offers more to monitor than I can keep up with, When I add LAPD, LA county Fire and Sheriff, CHP, and aircraft back in it will just become a confusing blur.

Steve

 

[kikito]

There are no alternatives to fixing the problem. Fix it, that's what it's about.

It's not about coming up with suggestions for workarounds to fix a broken "feature." It's about fixing the broken "feature."

I don't think is "broken" for the reasons I've mentioned before but like I've also said before, we can agree to disagree.

What you are wanting is people to chime in and come up with alternative solutions to GRE having to do anything. Well, just like with Uniden, I expect GRE to pay attention to user input and make changes based upon that feedback.

You didn't hang around the BCD396T group and forums for the first 18 months it came out did you? Uniden pays attention because of many heated discussions like this one on their lists about similar issues and people's demands. If they don't think something is broken, why would they fix it? And if we don't suggest how scanner manufacturers should fix something in the first place, what makes you think they're going to fix it the way you expect?

What makes you think that GRE is not listening and paying attention? And do you expect them to read people's minds about what you think needs fixing and how should they fix it to your liking without you voicing your opinion or "chiming in"? Do you realize how vague and obstinate your statements quoted above sound? "Just fix it!". OK, what and how? Especiallly after I outlined the possible side-effects to the "fixing" you expect them to do.

This particular scanner has only been out 3 to 4 months and they already came out with a firmware update within the first month. It's confirmed they're working constantly and as we speak with the community and beta-testers and about to release a second firmware update in the upcoming few weeks. Did you expect them to jump up and do something within 24 hours of a so-called problem reported so far by 3 or so people?

What I don't expect is to have to come up with workarounds to everything that you think is just fine and dandy the way it is.

I don't expect you or anybody to come up with work-aorunds. That's why others like me contribute such work-arounds to forums like this for people to use them instead of just sitting back and complaining not doing anything else about it. You can use the found work-arounds if you want until a permanent fix comes up or just continue not enjoying the scanner focusing only on what's wrong.

You aren't the only user of a PSR-500/600.

Well, right back at you. That's exactly what I've been implying all along. Just because some of you feel there's a fatal flaw in the scanner in a specific feature doesn't mean everybody else feels the same and it's affected or experiencing by it.

 

[mtindor]

The difference is that if everybody goes by your opinion, nothing needs changed and GRE can just give up and move on to the next thing.

I want to be the squeaky wheel who makes sure that GRE understands there are issues that can be worked on.

Nowhere did I state that GRE was being complacent or unattentive to our needs and desires. But, on one end of the spectrum we have you - who doesn't seem to think there is anything for GRE to fix. If they were to listen to only you, we'd never see an update. So, I feel compelled to add my thoughts regarding many things I find to be issues that need attention.

One such issue is this one. I described how I believe it should work. I describe why I think it doesn't work as intended or as it should. GRE programmers are the ones who need to figure out how to get from point A to point B.

The only additional thing I could add to assist GRE is to actually provide them with the actual code that is broken/needs modified/etc to fix/update/enhance this functionality. Obviously that is not possible.

I'll try to make it more clear.

GRE: Multisite STAT needs to sequentially scan all CCs in the TSYS object before moving on to the next item to scan when there are multiple scanlists enabled with multiple systems or a combination of a single system and multiple CONV objects.

Mike