[aprssig] Digipeater Symbol Overlays

Tue Oct 18 13:36:43 EDT 2016

APRS goal is situational awareness.  Digis have a code field for
identifying over 36 flavors of Digi.  If a digi performs differently than
others, then we should identify that difference.

There is nothing worse than inconsistent results from things that look the
same.  Hence, if a viscous digipeater is going to do something unexpectedly
to a users packet then the user deserves the opportunity to have that
information available to him.

Just my 2 cents.

Bob, Wb4APR

*From:* aprssig [mailto:aprssig-bounces at tapr.org] *On Behalf Of *Kenneth
Finnegan
*Sent:* Tuesday, October 18, 2016 1:25 PM
*To:* TAPR APRS Mailing List
*Subject:* Re: [aprssig] Digipeater Symbol Overlays

On Tue, Oct 18, 2016 at 8:08 AM, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

I'm not a big fan of the concept, but since we're in the area and people
are using them, how about viscous digipeaters?

I'd make the same argument for viscous digipeaters as I will for path
trapping (#L) digipeaters. I don't think it's a defining enough
characteristic to make people have to learn a new digipeater symbol.

I don't understand what we're expecting people to do with the information
about a digipeater being a limited or viscous digipeater. When I'm looking
at a map of digipeaters, I'm really only interested in knowing which ones
are fill-in (1#) and which one's aren't. How do we expect users to react
differently to a V# digipeater on the map than a 1# digipeater?

On Tue, Oct 18, 2016 at 6:25 AM, Robert Bruninga <bruninga at usna.edu> wrote:

I agree that L and P are mostly obsolete, but we need them in the table
because it will take decades before some people change their symbol.

So let's think about this from a forward build view-point. If we are
waiting decades for people to stop using L and P, what is keeping new
digipeaters from being set up using these symbols?

Imagine a new digi operator pulls up symbols-new and scrolls through the
list looking for which symbol to use. He's configuring his digipeater to
trap >2 hop paths, so L seems like the right choice. What did he do wrong
here? L is listed as the WIDEn-N digi with path trap, and that's what he's
setting up.

I wouldn't even list them with a note about being obsolete. If someone is
still running a P# or L# digipeater and local users are constantly asking
them what that symbol even means, it's all the more pressure for them to
consider updating their 10 year old digipeater config.

I did add #W as a new one to cover the generic WIDEn-N, SSn-N with path
limiting as the overall digi we use today if anyone wants to start using it.

Except that in several other places on your website you list #W as
"OBSOLETE RELAY,WIDE digipeater".

If you want us to use W# for WIDEn-N,SSn-N,path trap digipeaters, what is
the difference from S#? I thought we were deprecating L# because we wanted
all digipeaters to trap ridiculous paths, so S# would implicitly include
path limiting for WIDEn-N aliases.

I'll go back to my original suggestion. I think the overlay set should be
this:

 /# - Generic WIDEn-N digipeater

 1# - WIDE1-1/direct-only digipeater

 A# - Alternate input (i.e. 144.990MHz) digipeater

 I# - I-gate equipped digipeater

 S# - SSn-N local net alias digipeater

 X# - eXperimental digipeater

1#, /#, and S# cover the three tiers of traditional stand-alone digipeaters
(WIDE1-1, WIDEn-N, SSn-N and WIDEn-N)

A# digipeaters tell you that alt-input trackers are usable here.

I# tells you that traffic meant only for the Internet doesn't need to be
digipeated

X# tells you that this digipeater is short-lived and shouldn't be planned
on sticking around.

I think that should be it (I might even argue that SSn-N digis should use
/# and advertise their local alias groups otherwise, taking the list down
to five). We shouldn't be expecting users to memorize ten different overlay
codes for when they're looking at a map of digipeaters. Lets keep the
symbol set for this infrastructure simple.

If you want to specifically advertise digipeaters as being path traps,
being on emergency power, etc, define fields to add to the '<' station
capabilities packet. That is far and away more expressive than trying to
encode four different optional capabilities in the single overlay character.

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161018/213707c7/attachment.html>