[aprssig] Tracing SSn-N paths! WOW

Robert Bruninga bruninga at usna.edu
Tue Apr 5 15:31:36 EDT 2005

Re: SS1-1,SSn-N

>>> ad6nh at arrl.net 4/5/05 2:00:01 PM >>>
>NO, it's not so beautiful.  It's too much - too damn 
>complicated, and the packets end up being very long!  
>Just leave it alone, please!!!!

Agree.  This path is not for everyone nor for routine.  It is 
just a capability that can be used in situations where needed.

I am sure you dont need this in SoCal.  Here in Maryland
hardly anoyne needs it either.  But, we do have about 10 
people at the extreme ends of our state that do.  So it is
just an option where needed.

Everyone else just uses the simple and universal WIDE2-2.


Robert Bruninga wrote:

>Another great New n-N Paradigm trick!!! (I hope)
>Up till now, with SSn-N being supported in the UIFLOOD
>parameter, so that we can move WIDEn-N support to 
>UITRACE that is traaceable, we gave up traceability
>on the SSn-N path.  So I recommended setting ID to ON
>so that at least the path arrrives as DIGI2*,SS3-1 for
>example where the LAST digi is identified.
>But (drum roll please)....  if we use SSn-N with a leading
>SS1-1,SSn-N we get the best of both worlds!
>It will arrive like DIGI1,SS1*,DIGI2,SS3-1
>Thus identifying the FIRST digi and the LAST digi
>in the path as heard by this station!
>And since the only time anyone really will be using
>the SSn-N path is the guy that lives in the far corner
>of a state and needs to use SS5-5 to hit the opposite
>corner (without QRMING 150 digis in all directions)
>then the path wont grow to huge proportions!
>It always arrives as DIGI1,SS1*,DIGIn,SSn-N
>Wow, what am I overlooking?
>Is this beautiful or what?
>de WB4APR, Bob
>>>>Robert Bruninga 4/4/05 10:03:32 PM >>>
>Yes SSn-N will be untraceable.  
>So I receommended ID ON, so that at least we
>get to see the LAST hop.  But since we KNOW it is
>untraceable, and is using UIFLOOD, then we KNOW
>the digi on arrival of DIGI2,SS3-1 is the LAST digi.
>Yes, we could encourage a path of SS1-1,SSn-N
>and arrive as DIGI1,SS1*,DIGI2,SS3-1 which might
>not be a bad idea EXCEPT that the Kenwood screwed
>it all up and really bombs the network if NOID is selected.
>So I thought setting ID ON wil get rid of that problem too.
>Wow, I love this...!
>>>>Wes Johnston <wes at kd4rdb.com> 4/4/05 9:44:28 PM >>>
>This is off sig...
>Bob, if we use WIDE1-1,WIDE2-2 , and we're heard by a home relay, we
>WIDE1-1*,WIDE2-2, and the first "real" digi that hears us gives us
>DIGI1CALL*,WIDE2-1 .  We know the entry point into the network - well
>know the entry point close enough.
>On the other hand, if we use WIDE1-1,WIDE2-2, and we're heard by a
>"real" digi, we get WIDE1-0*,WIDE2-2 .  Upon being heard by the next
>digi, we'll get DIGI2CALL*,WIDE2-1 .  We now "think" the entry point
>the packet was at the 2nd digi.....
>So, perhaps we need to always include a UIDIGI trap call of WIDE1-1,
>that if a digi hears a WIDE1-1, it repeats it under UIDIGI
>call-substitution rules instead of UIFLOOD rules.
>I know that WIDE is presently used by UITRACE, but that still leaves
>UIFLOOD untraceable.  And we'll be using UIFLOOD for our SSn-n lans. 
>I'm simply using WIDE here in the context of UIFLOOD because it's what
>we're accustomed to dealing with. 
>And the one element, universal path of WIDE2-2 is untraceable.... when
>it's UIFLOOD.
>This also has be wondering what happens when we have NOID set and
>UIFLOOD sees a pre-depreciated WIDE2-1... it bet it won't do a
>sub on the digi preceeding it.... I bet you a doughnut and cup of
>that UIFLOOD NOID will only callsign sub when the two numbers in n-n
>identical... as in WIDE2-2 or W3-3.
>In order to make tracablity work, I am thinking we'll have to use
>"pre-depreciated" path names to stop UIFLOOD NOID or ID from callsign
>sub'bing on us..... and thereby making us loose the entry points....
>SO.... W1-1,W2-1 is two hops.... W1-1,W3-2 is three hops.... W1-1,W4-3
>is four hops
>Food for thought.  Kept this off sig to avoid confusing the masses.
>aprssig mailing list
>aprssig at lists.tapr.org 

aprssig mailing list
aprssig at lists.tapr.org 

More information about the aprssig mailing list