[aprssig] Digipeater Symbol Overlays
spam8mybrain
spam8mybrain at yahoo.com
Tue Oct 18 16:15:09 EDT 2016
One other problem here is that no one is going to update those antique digipeaters' beacons to indicate they have unfriendly behavior, such as RELAY or WIDE aliases. If they could do that, they could fix the darn things to be compliant with modern standards.
Andrew, KA2DDO
-------- Original message --------
From: "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>
Date: 10/18/16 3:51 PM (GMT-05:00)
To: TAPR APRS Mailing List <aprssig at tapr.org>
Subject: Re: [aprssig] Digipeater Symbol Overlays
I concur Bob. I suggested the
differentiation for the Viscous digipeater specifically because it
DOES behave differently and not known it can drive a local user to
distraction. If I'm sitting right next to a (non-differentiated)
WIDE1 digipeater that is actually Viscous, I could wonder a long
time why it isn't digipeating my WIDE1-1 packets when in fact, I
was also in range of a WIDE2 digi that was copying me direct.
Until and unless I hide from the WIDE2 digi while still in range
of the Viscous WIDE1 digi, I would never see it digipeat.
If the behavior is different, then the differentiation should be
made IMHO. Saying it in comments or capabilities is nice, but
that's even more of a free-for-all land than the symbols.
Lynn (D) - KJ4ERJ - Adding my $0.02 to yours.
On 10/18/2016 1:36 PM, Robert Bruninga wrote:
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
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/
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161018/54939feb/attachment.html>
More information about the aprssig
mailing list