[aprssig] Re: Tracing SSn-N paths! WOW

Tue Apr 5 10:50:15 EDT 2005

APRS milestone:  New n-N Paradigm is now complete:

The  SS1-1,SSn-N  WORKS! and it identifies the starting
and ending digi as we had hoped!

Sent:           SS1-1,SS3-3
First hop:     DIGI1,SS1*,SS3-3
2nd hop:     DIGI1,DIGI2*,SS3-2
3rd hop:      DIGI1,DIGI3*,SS3-1
4th hop:      DIGI1,DIGI4,SS3*

Perfect.  This gives us point-of-entry and point of reception.
and not the load of the intermediate hops which would 
cause the path to grow in length.  Remember, the only use 
of SSn-N is for state nets where a station in one corner of a 
state has to  seen by another  in the opposite corner and
has to use a larger value of N.  But we don't want the big N
QRM in surrounding states.

See the example on the web page.  In Maryland, the 5
hop path used by a panhandle station to get into the 
statewide weekly net using MD1-1,MD4-4  will only 
generate about a dozen packets (one for each big digi
in the state, and none beyond the borders).   But the
same 5 hop WIDE5-5 would generate as many as 100
copies in a dozen states to do the same thing.

Big States are broken down into smaller ARRL Sections
and so they would use their ARRL section.  Some states
may be too big and not want to do this.  But for small and
or well-organized state communications, it is perfefct.

The New n-N Paradigm is now complete.

* User recommendation is simple:  Use WIDEn-N (small N)
* ALIAS Trapping solves the BIGn-N abuse
* Eliminating RELAY,WIDE gets rid of all of the dupes
* Using WIDE1-1 to replace RELAY still allows "relay-only" digis
* WIDEn-N is now fully traced
* SS1-1,SSn-N now is traced by 1st and last digi and
   greatly limits the QRM when larger N's are needed
* Balloons may use WIDE2-2 and generate no dupes at
  altitude, yet get an automatic 2 hops on the ground.
* Accidents and abuse of RELAY and WIDE are eliminated.

Lets do it!  The WEB page has been updated to these
lastest issues.  The only change that impacts digis is that
now we recommend the "S" overlay for New n-N Paradigm
digis that support SSn-N.  ("L" should still be used if the
state or section SSn-N is not supported.  THe "L" shows
that the digi is capable of "limiting" large N's.

See http://www.ew.suna.edu/~bruninga/aprs/fix14439.html

de WB4APR, Bob

>>> Robert Bruninga 4/4/05 10:10:23 PM >>>
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 >>>
Wes,

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...!
POST TO SIG TO FOLLOW!

Bob

>>> 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
get
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
we
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
of
the packet was at the 2nd digi.....

So, perhaps we need to always include a UIDIGI trap call of WIDE1-1,
so
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
callsign
sub on the digi preceeding it.... I bet you a doughnut and cup of
coffee
that UIFLOOD NOID will only callsign sub when the two numbers in n-n
are
identical... as in WIDE2-2 or W3-3.

In order to make tracablity work, I am thinking we'll have to use
these
"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.
Wes