[aprssig] Tracing SSn-N paths! WOW

Tue Apr 5 16:36:00 EDT 2005

I think the main point here is that it looks like you're trying to 
achieve a level of network accuracy that is second only to a purely 
directed network.  We have done a lot to increase the accuracy and 
capacity of the 144.39 channel in many areas of the country.  We also 
worked hard to do it in such a way that the common users is not required 
to have a masters degree in network design to run an APRS station.  I 
think some of the proposals in the last week cross the line of what is 
acceptable as far as dupes and accuracy is concerned and what is 
understandable to the common user.  We will never completely eliminate 
dupes, packet collisions, and 100% station-to-digi accuracy unless we 
move beyond what the common APRS user can understand!

Bottom line - I think we have found the happy medium.

73
Phil - AD6NH

Robert Bruninga wrote:

>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.
>
>Bob
>
>*----------------------------------------
>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 >>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>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
>>
>>_______________________________________________
>>aprssig mailing list
>>aprssig at lists.tapr.org 
>>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>>
>>
>> 
>>
>>    
>>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org 
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>  
>