[aprssig] Digipeater Symbol Overlays

spam8mybrain 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 */
@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://www.tapr.org/pipermail/aprssig/attachments/20161018/c8bab468/attachment-0001.html>


More information about the aprssig mailing list