Warning messages for untrunk systems

Tom, I suspect that this would be a pretty big change, but is there any thought being given to adding a warning message - much like the database already does for P2 systems - for those trunk systems that are untrunkable or unmonitorable (Open Sky, for instance)?

We are already doing this in the wiki for just about all the applicable types (we don't have many iDEN systems in the wiki - if we did, I'd develop a template for them, too...) if you would like to see some examples

Mike

Such warnings need to be phrased according to what tools are available for tracking them. For example, P25 Phase 2 requires certain model scanners. TRBO and the other "business" digital protocols require either scanner modifications or SDRs, in addition to decoding software. Even with the software, some types are not "trunkable" yet.

None of the above are totally unmonitorable.

Keep in mind that Open Sky and iDen (and we do have a few of these in the database) are not trunktrackable nor decodable.

As for tailoring the warnings to point to the apps that can handle them, the warnings in the wiki do precisely that. They even include the new ProVoice decoding that Uniden just started offering.

Mike

ka3jjz said:

Tom, I suspect that this would be a pretty big change, but is there any thought being given to adding a warning message - much like the database already does for P2 systems - for those trunk systems that are untrunkable or unmonitorable (Open Sky, for instance)?

We are already doing this in the wiki for just about all the applicable types (we don't have many iDEN systems in the wiki - if we did, I'd develop a template for them, too...) if you would like to see some examples.

Click to expand...

A prominent mention in the System Notes field should be sufficient and can be done by any admin without any changes to the back-end programming of the site. If monitoring is possible through alternate means, a link could be provided to a how-to Wiki page.

Certainly that could be done for any future systems - but what about the numerous systems we have now?

Mike

ka3jjz said:

Certainly that could be done for any future systems - but what about the numerous systems we have now?

Click to expand...

That's part of an administrator's job, to keep up with changes like this. . . .

I'll post a gentle nudge in the Admin forum. Since the system type/flavor is noted in the summary list it shouldn't be too hard to find the systems needing attention.

Here are all the templates we use for trunk system warnings...perhaps they can be used as a model

Templates-List: General Use Only - The RadioReference Wiki

Mike

ka3jjz said:

Here are all the templates we use for trunk system warnings...perhaps they can be used as a model

Templates-List: General Use Only - The RadioReference Wiki

Click to expand...

Great, thanks.

I'll snoop deeper to see if adding an automatic warning based on system flavor would be easily accomplished, but I suspect the easiest would be the Text Description field.

I know this is an old thread, but it's mine :.>>

Any progress on this issue? Looking through the various trunk systems in Maryland, none have any warning messages.

If a 'nudge' is being insufficient, perhaps it's because they don't know we already have templates designed for this very purpose that they can copy...

Mike

ka3jjz said:

... (we don't have many iDEN systems in the wiki - if we did, I'd develop a template for them, too...) ...

Click to expand...

So far, I have found only one iDEN system in the Wiki, but it is deprecated:
Southern Company LINC 800 MHz (Alabama)

Hope this helps,

Many in the database...

Google Search: "iDEN Standard" site:radioreference.com/apps/db/


http://www.radioreference.com/apps/db/?sid=4585
http://www.radioreference.com/apps/db/?sid=5740
http://www.radioreference.com/apps/db/?sid=4174
http://www.radioreference.com/apps/db/?sid=5918
http://www.radioreference.com/apps/db/?sid=5354
http://www.radioreference.com/apps/db/?sid=1651
http://www.radioreference.com/apps/db/?sid=130
http://www.radioreference.com/apps/db/?sid=6449
http://www.radioreference.com/apps/db/?sid=5683
http://www.radioreference.com/apps/db/?sid=4875

http://www.radioreference.com/apps/db/?sid=353 (Deprected)
http://www.radioreference.com/apps/db/?sid=5761 (Deprected)

One thing that would need to be planned for when doing such a warning would be how easy it would be to catch all entries that would need to change once scanner technology catches up. For example, those DMR systems that previously were not monitorable but with the latest updates from both Uniden and Whistler can now be.

If the message in the database was created to be a template of some kind (as it is in the wiki), then all one would need to do would be to change the template - then everything that calls it is automatically changed. We are going to need to do this in the wiki, for example, when Whistler comes out with their NXDN firmware for the TRX1 and 2. Here, at least, it would be a piece of cake, and it would be similarly easy in the database if this approach were used.

And insofar as identifying these systems (and potentially installing the template), a bit of dynamic SQL could handle this rather easily. If every trunk system form has a miscellaneous or news area, that, to me, would be the logical place to put the warning with some sort of box to make it stand out if the area that's being used for the Phase 2 system warnings doesn't exist on every trunk system form.

Mike

By way of clarification, see this entry....

Prince George's County Trunking System, Various, Maryland - Scanner Frequencies

This form has a warning for the Phase 2 system - if this text area exists in all trunk system forms, then this could be used to house the template, where it's needed. If not, then using the miscellaneous or news areas would be a logical alternative. It is a bit inconsistent, but it avoids the need for a form change across all trunk system entries

Mike