PSR-500 future firmware wishlist

[LEH]

Don,

Yes, but I kind of like pushing the volume knob on my 396 and seeing the voltage displayed.

 

[mikey60]

My Firmware wish:

First off, I love the radio - thank you GRE!

When putting multiple towers/control channels in a single system. There is really no easy way to tell which tower you are listening too. Here would be an easy way to tell. If this could be impremented in a future firmware upgrade I don't know.

When you hit "TSYS" and then "Analyz" the radio always takes you to the first channel in the system you have programmed. What if the radio automatically took you to the active control frequency instead? You would then see the system ID and can figure out which tower you are listening to.

As it stands now, you have to thumb thru the channels and find the control channel. When you are dealing with many towers that are within your receive range you still don't know for sure which one you are listening too.

I know with the upgrade just released if you have the "show CC info" option on it now blinks the channel number. This is a good start, but you still have to remember what your channel numbers are.

Adding text tags for each CC frequency would take up a lot of memory. I'd hate to have to tie up 26 object ids on a Motorola system just to be able to have text tags. The CC## on the display is a good start though!

Mike

 

[wwhitby]

Another wish: the ability to use spectrum sweeper and scan at the same time.

Warren

 

[DaveIN]

Warren, you can do that already. Just save the SWPR Object you want to a scanlist. You can do this with limit search as well.

 

[kb8tfe]

TSys Alpha tag AND Talk Group alpha tag

I would really like to see the 3rd line have the trunking system alpha tag AND on the 4th line have the talkgroup ID. These two alternating on the third line makes me have to look at it too long to read what I'm hearing. Having it optional/configurable as to wht displays on what line would be helpful. I know others have mentioned this, but I wanted to put my vote in!

 

[troymail]

I would really like to see the 3rd line have the trunking system alpha tag AND on the 4th line have the talkgroup ID. These two alternating on the third line makes me have to look at it too long to read what I'm hearing. Having it optional/configurable as to wht displays on what line would be helpful. I know others have mentioned this, but I wanted to put my vote in!

I agree I'd like to see some changes (or configurable) on what gets displayed... for example, the VOICE FREQ means pretty much nothing to me (but it might mean something to others).

I had problems while driving in areas I'm not usually in and I hear a conversation -- look down and see either the TG or the system - waiting for it to "alternate"... but you can control that... just reduce the LCD on/off time to something lower (I have mine set to 75 each).

 

[Landman]

I found the alternating tags to be particularly annoying so I set the time for the system tag to its lowest setting so that I only see the talkgroup tag. I like the fact that GRE gave us so many customizable options in this radio. That flip floppy text tag almost made me go with the BC396T instead until I saw that the time for each tag was adjustable. Yes there is a way to stop the Uniden scanners from flip flopping tags too. Just set the tag for each scan list within a given system to the read the same as the system tag itself and it will appear that the system tag stays steady above the talkgroup tag. Its just a matter of personal preference. I'm glad GRE is giving us a choice. What I would like to see on the 500 is a screen mask that will blank out the lines of the display above and below the takgroup tag line. It just makes for a neater and easy to read display when you only have enough time to glance while driving.

 

[walter900]

I see alot of request for improvments, but i havn't seen GRE impliment any of them yet. Could this be an indication that they are just dedicated to fixing there own issues and not go beyond that?? Is thread just a big waste of time or what??

 

[rdale]

1) They have MANY other scanners coming out in the near-term
2) There are still users who have issues with the radio, wouldn't it be better to get all the bugs worked out before adding new features?
3) Why not keep the feature list going, even if they don't make it into the PSR500, maybe they can get into the PSR501?
4) Or is it better to bash them...

 

[W4KRR]

I see alot of request for improvments, but i havn't seen GRE impliment any of them yet. Could this be an indication that they are just dedicated to fixing there own issues and not go beyond that?? Is thread just a big waste of time or what??

Many of the requests are likely things that can't be added with just a firmware upgrade. It would probably take a re-design of the radio to implement some of the things that people are requesting.

 

[Russell]

Desired features;

1. Allow the user to optionally define the SystemID on Moto systems.
2. Allow the use of shared TGRP objects between TSYS systems.

Both of these would be good for wide area system, divergent simulcast layer systems, or different systems sharing freqs that are geographically seperated. Number 1, seems like a releatively easy thing to implement in software. Number 2, might be a problem if the software architecture does not support it.

Russell

 

[kikito]

I see alot of request for improvments, but i havn't seen GRE impliment any of them yet. Could this be an indication that they are just dedicated to fixing there own issues and not go beyond that?? Is thread just a big waste of time or what??

They have fixed, improved, changed and added several things. Just check the release notes for all the beta and final firmware releases. Most of it might not be "ground-breaking" but still. It's been barely what, a month or two since release?. I'm sure there's more to come....

 

[DonS]

Desired features;

1. Allow the user to optionally define the SystemID on Moto systems.
2. Allow the use of shared TGRP objects between TSYS systems.

Both of these would be good for wide area system, divergent simulcast layer systems, or different systems sharing freqs that are geographically seperated. Number 1, seems like a releatively easy thing to implement in software. Number 2, might be a problem if the software architecture does not support it.

Based on what I know about the architecture of "stored objects", #2 is impossible without a bit of re-design. For example, there's no "room" in the memory reserved for TGRP objects for more than one TSYS Object ID.

#1 could be problematic from a trunking perspective... when tuning to a CC, you'd have to wait for SysID info before recognizing any call grant messages. This would lead to some serious delays in many cases. For example: a) MultiSite Stat mode, when the radio is always moving between CCs and b) situations where the CC is "weak" and you barely hear the frequent call grants/updates, but almost never hear the relatively infrequent SysID messages.

 

[troymail]

Would like a setting that allows me to IGNORE delay settings if only one scanlist(system) is active (1-20)... and enable the delay settings as soon as I enable a 2nd scanlist.

and a method to review (and/or clear) all lockouts from a single command

 

[rdale]

Not sure I understand the delay thing - what's the advantage?

 

[troymail]

Not sure I understand the delay thing - what's the advantage?

If I'm monitoring one system in one scanlist, I'm interested in ALL of those channels/talkgroups and I don't want DELAY to hold me from hearing related activity on another TG in that system.

However, if I have > 1 scanlist/system active, I want the delay to hold on the active TG for follow-up conversations. In this case, the lack of a delay can cause miss conversations while the radio steps through the other systems/scanlists.

 

[kikito]

.....and a method to review (and/or clear) all lockouts from a single command

Yes, I agree. I would like to have at least something like the lockout review feature that the Pro-96 has, you press the Func + L/OUT buttons repeatedly to cycle through each locked item. Right now, it's not too bad to scroll quickly through the TGRP objects and find what's locked out *permanently*. The radio does have a nice list of lockouts you can review for conventional objects locked out during searches or sweeps. So I wonder if something like that can be done for TSYS/TGRP objects.

It would also be nice to have a feature to clear all lockouts at once, but I'm guessing you're referring to *permanent* lockouts right? The temporary lockouts it's working great for me. I rarely lockout anything permanently and just cycle the power to restore everything.

 

[bc780l]

Shielding?

Has anyone tried to coat the inside of the case with RF shielding paint? In high cellular RF areas that might help the interference issues many have encountered. I remember the early MX7000 had that problem which was solved by RF paint inside the case--it might be good here.

Edit: Oops, wrong forum thread. Ah, well ... if any responses, move to the correct thread. Tnx.

 

[rvawatch]

id like to see temp lockouts on the sweeper or search feature. i dont think its currently possible...well maybe if it is a programmed object? i dunno..just thought of that. im mainly talking about the dedicated sweeper and searches.

 

[DaveIN]

Sweeper already has temporary (press L/O on an active frequency) or permanent (Func + L/O). You can change it to permanent lockout from the keypad by changing it in the Global menu.