[aprssig] Digipeater Symbol Overlays
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Tue Oct 18 14:51:15 CDT 2016
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:
> 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
> <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 <mailto: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
> <mailto: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
> 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
> Kenneth Finnegan
> aprssig mailing list
> aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig