[aprssig] Digipeater Symbol Overlays
spam8mybrain at yahoo.com
Tue Oct 18 15:23:00 CDT 2016
One other suggestion for digipeater overlays is something I do in my APRS client, which is trying to locate "stealth" digipeaters. These are digipeaters that don't beacon a position report of their own, and only comply with the legal station identification rule by tracing their callsign-SSID into the digipeat path.
I worked out an algorithm to guesstimate the position of such "stealth" digipeaters until and unless they send a self-identifying position beacon. To mark them on the map, I used the code ?# (yes, that's an illegal symbol overlay, but it clearly identifies that the station is not playing by the rules). Note that no station should ever transmit such a symbol; I just use it locally to mark my guesstimated positions.
Andrew, KA2DDO author of YAAC
-------- 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 */
panose-1:2 4 5 3 5 4 6 3 2 4;}
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
font-family:"Times New Roman","serif";}
margin:1.0in 1.0in 1.0in 1.0in;}
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
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
my 2 cents.
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:
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
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
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
I'll go back to my original suggestion.
I think the overlay set should be this:
Generic WIDEn-N digipeater
Alternate input (i.e. 144.990MHz) digipeater
I-gate equipped digipeater
SSn-N local net alias 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
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.
aprssig mailing list
aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig