[aprssig] Digipeater Symbol Overlays

[Lynn W. Deffenbaugh (Mr)]

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
>     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/65940f0e/attachment.html>