Flagging untrunkable systems

[ka3jjz]

As I've been overhauling the trunked systems articles found in our wiki, I have also added warnings about those systems that either can't be trunked at all (OpenSky, for example) or can be trunked using external utilities (such as Motortrbo, ProVoice, LTR MultiNet, etc.). Wiki templates have been built to flag such systems.

Given that the Home Patrol style radios download trunked systems along with everything else, I would imagine that it would also download these types of systems, regardless of the fact that these radios can't trunk them. It's confusing to the newcomer and probably frustrating as well since the system would be imported, but if they try to use it, they find they can't. I don't own one of these radios (yet) but if this is the case, it's a pretty signficant oversight.

It's also a bit misleading not to flag these types of systems the same way that X2-TDMA and Phase 2 systems are. Again, a newcomer would try to import trunk systems like MotoTrbo or Open Sky using the web service without knowing they can't be trunked.

So how about adding some warning messages (like the one used for Phase 2 systems) for the other types of trunks that can't be tracked? Here are a few examples of what was done in the wiki...

LTR Multinet

G and D Communications - the RR Wiki

LTR Passport

Teton Communications FleetTalk - The RadioReference Wiki

LTR Net

MobileTech Communications - the RR Wiki

MotoTrbo

Fleet Talk Houston Connect Plus - the RR Wiki

Fleet Talk Houston Capacity Plus - the RR Wiki

MPT-1327

Wolverine Power Supply Cooperative - The RadioReference Wiki

ProVoice

Honolulu County - The RadioReference Wiki

OpenSky

CLEMIS Public Safety Communications - The RadioReference Wiki

Of course something could be coded for iDEN systems but we don't have that many in the wiki yet.

In addition I think it would be a real good idea to at least flag these kinds of systems in some way during the database downloads done by the Home Patrol style scanners, as well as the RS and GRE scanners that also take a full download of the database

Mike

 

[ofd8001]

Agree completely. Be nice to have a similar flag for talkgroups that may be shown as encrypted for the same reasons.

It's very possible that a novice user may see where such systems are being downloaded through a program such as Sentinel. However the systems are not being scanned. So this novice user may think there is a problem somewhere and be frustrated unnecessarily.

 

[SCPD]

untrunkable?

 

[pinballwiz86]

untrunkable?

He probably meant unscannable.

 

[ka3jjz]

Actually both terms apply in some cases. Systems like Open Sky or ProVoice can neither be trunked nor scanned conventionally by a scanner (yes, I realize that the db is also used by professionals, that's why I'm being specific here). On the other hand, LTR Passport and MultiNet systems are not trunkable by today's scanners, but their freqs can be conventionally scanned.

And currently talkgroups are flagged as 'T' (Phase 2 TDMA), 'E' (encrypted) and other combinations - I don't know that this functionality would need to be expanded, except in the case of a LTR mixed system, such as one that is both Standard and Passport. You could make a case for marking such talkgroups with a 'L' to indicate a LTR type that is not scannable (it would cover LTR Passport, MultiNet and Net, and any other LTR system type). LTR Standard talkgroups would continue to be marked 'A' (analog) since this is the only LTR type that current scanner technology recognizes.

So as you see, there are 'flavors' of both concepts that should be addressed more clearly...Mike

 

[ka3jjz]

I sit corrected - LTR Net systems are backward compatible with LTR Standard, so they should be trackable by todays scanners.

Here's an example of a db entry for a combo LTR Standard/Passport system - it doesn't have any talkgroup listings yet, but this is a good example as it covers a wide area

Teton Communications FleetTalk Trunking System, Various, Multi-State - Scanner Frequencies

Mike

 

[tampabaynews]

I would be careful about labeling entire systems as unscannable just because certain voice modes may be present.

For example I monitor an EDACS system that has (1) Analog talkgroups (2) Provoice talkgroups and (3) talkgroups with a mix of both depending on the conversation.

I've also seen some talkgroups marked as encrypted on various systems in the database when they're not necessarily encrypted all the time.

But I would be all for flagging obvious systems like MOTOTRBO and Opensky.

 

[ka3jjz]

That's why the text for the ProVoice message says 'systems or talkgroups' realizing that some systems, like yours have a mix of both. But thanks for your vote of approval in any case

Mike

 

[KE5TLF]

You imagine wrong. Uniden/HP/Sentinel doesn't import things it can't monitor. (e.g. HP-1 Sentinel doesn't pull "T"DMA flagged TGIDs)

Been a while since I used any but afaik the various program authors for other radios have at least a some things in place in their software to deal with unsupported things too. (e.g. I know in most any of the few cases I recall you have to go out of your way to pull in "E"ncrypted TGIDs)

 

[mikewazowski]

You imagine wrong. Uniden/HP/Sentinel doesn't import things it can't monitor.

Sure it does. D-STAR and NXDN are two that it imports that it can't monitor.

UPMan has said on here that they stopped filtering after people complained.

 

[ka3jjz]

In that case, there should be something (a message, anything...) that explains that these systems can't be monitored

As a precedent, I cite FreeScan. That software will at least warn the user that the system s/he is trying to import can't be trunked but allows it to go forward.

Yes, that's an application level (meaning: Sentinel) fix that would need to be applied, but at least the user would have some idea why it can't be received. I could even envision a flag that Sentinel could check and trigger a message that explains to the user about the restrictions. That's not so far fetched; there's a flag now that sets systems up for rebanding.

As of right now, a user is left completely in the dark. Not particularly good design for a database (I do it for a living...)

Mike

 

[ka3jjz]

Here's what happens in FS if you try to import, say, an Open Sky System...

File:FS warn untrackable.JPG - The RadioReference Wiki

Look at the bottom right of the panel. Unfortunately the list of 'warned' systems in FS isn't complete (I've asked him to update his list on his 'to do' list), and the message lacks a bit of detail, but you get the idea. It's a good start.

I think Assaf queries the System Voice or Type - that would be simpler than adding a flag. Of course the message would need to be a bit more tailored for systems like the one in Tampa that's a mix of EDACS Standard and ProVoice, but that's a matter of programming. As I mentioned earlier, I nuanced the warnings in the wiki to cover that possibility - it can also be done here.

One could also store that message in a 'remarks' type field if there is such a thing in Sentinel so that screen space isn't wasted.

There are a number of possible avenues here. The goal here is to warn the user who might be new to scanning without flooring him/her with a lot of tech geek stuff...Mike