Upman & Uniden Corp: Thanks for RIDs, but I have suggestions

[naSTI]

First off, I really appreciate the effort to get this featured built into the latest firmware.

The feature does leave a little more to be desired:

1) I understand the DMA platform is such that "Systems" can have a separate DB for storing Alpha Tags for radio IDs, which is absolutely fabulous. I also know about the workaround to allow the display of Radio IDs for conventional frequencies once they are programmed in as single-channel P25 systems. Will there ever be a Radio ID display for conventional channels for scanned conventional or regular conventional systems (either with or without Alpha Tags)?

2) On a 3600 baud Motorola system all TGIDs are programmed and known by their Hexadecimal value into radios as per RSS/CPS, but Radio IDs are stored and displayed in Decimal. Instead of one or the other for both types of ID display, would it be possible to have the ability to display TGIDs and Radio ID on the same system in different notation?

3) I can see how i-Calls would be easily identifiable by the ixxxxx-ixxxxx display, but on 3600 SN and SZ standard group (TGID) calls ( read:non-icalls ) Radio ID display always need to be prefaced with "i" instead of 7xxxxx?

4) While we're on the subject of i-Calls and Group Calls, I assumed entering ".12345" would stalk the 12345 radio and unmute any calls (icall or group), but apparently it only unmutes on i-calls. For example, there's one fire dispatch console that is used in special cases and box-calls, I'd like to hear all traffic and only traffic from that console when it is keyed regardless of what talkgroup it is on. Could there be a future release that would allow the scanner to monitor both i-calls plus groups calls (or either)?


==============================

Totally unrelated to Radio IDs:

Direct Entry Mode
---------------------------
When you are *holding on a searched or manually entered frequency* and you mistakenly press a key and the scanner goes into Direct Entry Mode there's no way (that I know) to exit that mode and get back to the frequency you were holding on, it always reverts back to the first entered channel of the first entered system. The only way to get out of Driect Entry Mode is to enter something valid, or press Scan.

Is there a way to cancel or get back to the group or frequency that was being held?



Again, I thank you for the fine work so far, but these are small items that I feel would make the scanner closer to a perfect UI!

 

[DaveIN]

On a 3600 baud Motorola system all TGIDs are programmed and known by their Hexadecimal value into radios as per RSS/CPS, but Radio IDs are stored and displayed in Decimal. Instead of one or the other for both types of ID display, would it be possible to have the ability to display TGIDs and Radio ID on the same system in different notation?

I'm trying to understand why you would want to do this? Right now you can select Decimal (default) or Hex, not sure why you need either, or.

I can see how i-Calls would be easily identifiable by the ixxxxx-ixxxxx display, but on 3600 SN and SZ standard group (TGID) calls ( read:non-icalls ) Radio ID display always need to be prefaced with "i" instead of 7xxxxx?

The classic "T" series used the "7" preface, the XT series use the actual UID as seen on the trunked system.

While we're on the subject of i-Calls and Group Calls, I assumed entering ".12345" would stalk the 12345 radio and unmute any calls (icall or group), but apparently it only unmutes on i-calls. For example, there's one fire dispatch console that is used in special cases and box-calls, I'd like to hear all traffic and only traffic from that console when it is keyed regardless of what talkgroup it is on. Could there be a future release that would allow the scanner to monitor both i-calls plus groups calls (or either)?

I would like this feature also, but it would need to be able to look for a specific UID in control channel data and track it. The XT models can't do that.

When you are *holding on a searched or manually entered frequency* and you mistakenly press a key and the scanner goes into Direct Entry Mode there's no way (that I know) to exit that mode and get back to the frequency you were holding on, it always reverts back to the first entered channel of the first entered system. The only way to get out of Driect Entry Mode is to enter something valid, or press Scan.

Is there a way to cancel or get back to the group or frequency that was being held?

Press the "." key.

 

[naSTI]

I'm trying to understand why you would want to do this? Right now you can select Decimal (default) or Hex, not sure why you need either, or.

Convenience more than anything else. It saves time and less confusion for those of us that deal with RSS and CPS all the time that think of talkgroups as a hex value and radio ids as decimal. It would be nice to not have to bust out the hex converter.

To be honest, I think really that Motorola is the one that got it wrong. From a data-stream standpoint, sure all values should naturally be in hex, it's more efficient. But they should never have bothered having the administrators and field programmers input the TGID values in hex. They should've kept the whole thing (TGID and RID) in decimal notation.

Maybe I should be taking this discussion to big /\/\.

The classic "T" series used the "7" preface, the XT series use the actual UID as seen on the trunked system.

Well yeah, for data entry having the user needing to enter the "7" prefix is just wrong. But my point is why does the RID display as i*****? It should display as 7*****.

I would like this feature also, but it would need to be able to look for a specific UID in control channel data and track it. The XT models can't do that.

Well it can't do that now. I'm not going to try and trivialize it, because I don't have the Uniden source code, but if the scanner waits for "RID + iCall" when in HOLD mode, it shouldn't be a massive undertaking to look for "RID + gCall" for HOLD mode also. No?

Press the "." key.

Ahh.. I figured it out. It's the [L/O] key. (I don't remember seeing that in the manual anywhere, but I could be wrong).

.

 

[DaveIN]

Well yeah, for data entry having the user needing to enter the "7" prefix is just wrong. But my point is why does the RID display as i*****? It should display as 7*****.

Why would it display as a 7 series when the UID is not prefexed by 7? That was a Uniden display number. The XT series do not use the 7 series numbers unless the UID uses a 7. Are you saying you want it to display as the previous "T" series did?

 

[naSTI]

Yes and No. The whole "7" thing is a Motorola trunked addressing scheme. All Motorola SmartNet and SmartZone equipped radios will display 7xxxxx for the Radio ID when voice traffic from other subscriber units is being sent, regardless of iCall or gCall. That prefix is appended by the equipment to the actual radio address. The "7" does not apply to Conventional nor P25 9600 baud systems.

It makes sense during data entry to use the "."xxxxx so if the "i" shows there, that would be fine. But for normal ID display, I'd rather see NO prefix at all or the 7 rather than "i" on 3600 baud systems.

 

[Jay911]

the UID is not prefexed by 7? That was a Uniden display number.

No, it's not. A Motorola radio will display a six-digit number starting with 7 on a Smartzone 3.0 (3600) system and so will their own Centracom Elite dispatch console.

The user ID, as displayed to the user (and manipulated by the user) in a Motorola system, is a six-digit number starting with 7. Any other formats (five digit decimal, hexadecimal, etc) are internal numbering schemes for programming purposes.

 

[DaveIN]

I'm confused. So what you both would like to see is the ability to see a "7" in front of the UID and iCall because Motorola uses it on their portables? I would rather have it display as the Trunker decoders display it myself, but that's fine. I just think you would be the minority. As for EDACS I like the AFS display (or hex) and decimal or hex for iCalls and UID's.

It wold be best to have all the possible display formats to cover all user preferences, but this is why Uniden went from the "7" series of display (in iCalls) in the "D" and "T" series, to iX in the "XT" series, for individual calls, then the UID feature came and continued this existing format.