[aprssig] An Anniversary Cheer for Stephen Smith

Ron Stordahl ron.stordahl at digikey.com
Tue Mar 28 18:18:26 EST 2006


Comments in line:

Robert Bruninga wrote:
>>>> Ron Stordahl <ron.stordahl at digikey.com> 03/28/06 5:14 PM 
>>>>         
>> My only issue with the WIDE1-1 replacement for 
>> RELAY is that, for example, in an N=3 area 
>> via WIDE1-1,WIDE3-3 results in 4 hops. 
>>     
>
> Yes, and so if it is a 3 hop area, then it should not be 
> used.  This is a user education issue.  When we
> say a 3 hop area, it means 3 hops or less.  Therefore
> WIDE1-1,WIDE2-2  which is 3 hops is the maximum hop 
> desired in this area....   Bob
>   
Yes user education is an important part, but we still need our high 
digi's to enforce the rules.  Which is why so much effort has been put 
into choosing parameters which try to enforce the rules within the 
limits of existing digi firmware. 

My point is simply this...why not set N=2, i.e. trap WIDE3-3 and above, 
in a three hop limited area and ask everyone to use at most 
WIDE1-1,WIDE2-2?  Then the goal would be closer to being achieved. 

Ron, N5IN
>
> it be better to set up the high digi's to limit N=2 and recommend to 
> everyone they use WIDE1-1,WIDE2-2.  N=2 and N=4 areas would have 
> corresponding settings. In most instances high digi's themselves could 
> limit their maximum beacon to WIDE2-2 and reach an IGate.
>
> Of course if we had smarter digi's, then setting N=3 limit would be 
> handled by the digi examining the path specified in the incoming packet, 
> which could deal with such things as WIDE1-1,WIDE1-1,WIDE3-3 which I 
> believe with UIDIGI would be a 5 hop path.  It will be a while for this 
> goal to be achieved.
>
> Ron Stordahl, N5IN
>
>
>
> Robert Bruninga wrote:
>   
>> Yep, that was the last piece of the puzzle to fall
>> into place.  Once we had the replacement for RELAY
>> figured out (in North America), then New-N was off
>> and running!                 Bob
>>
>>   
>>     
>>>>> isobar at bcpl.net 03/27/06 12:09 PM >>>
>>>>>         
>>>>>           
>> Cap Pennell's in a recent message commented that  "The North American "New 
>> n-N Paradigm" is already helping our stations (a lot) to conserve our 
>> limited available airtime on VHF[...]" and also mentioned, in passing, 
>> Stephen WA8LMF.
>>
>> That reminded me of just  how much the "New Paradigm" has improved APRS 
>> throughput in just the last  year, thanks much to Bob Brununga's tireless 
>> prodding. Those RELAY and path discussions were (are) endless and didn't 
>> seem to  be going anywhere. At least now we've eliminated the RELAY problem 
>> and, barring smart software, probably reached a plateau.
>>
>> Cap's message jogged my memory, and a quick check of the archives shows 
>> that only a year ago Stephen proposed:
>>
>>   
>>     
>>> Date: Thu, 31 Mar 2005 15:01:14 -0800
>>> From: "Stephen H. Smith" <wa8lmf2 at aol.com>
>>> ...
>>> Subject: Re: [aprssig] Why RELAY,WIDE... is so bad....
>>>
>>> On the issue of how to combine home digi first-hop-assist with true 
>>> WIDEn-N systems without using first-hop RELAY:
>>> How about a path of    "WIDE1-1, WIDE1-1"    or    "WIDE1-1, WIDE2-2"    ??
>>> Set the alias of the former home "RELAY" digi to WIDE1-1 instead.   If a 
>>> "dumb" home former-RELAY-type digi does the first digipeat, it marks 
>>> WIDE1-1 as used.
>>> Then the true WIDEn-N digi(s) get a shot at the second part of the 
>>> path.   I assume that in the absence of a nearby home digi, a "real" 
>>> WIDEn-N would digi the first hop, then the WIDE2-2 part would cause two 
>>> more digipeats.
>>> The path is compatible with either    first-hop-via-home-station,   or 
>>> with all hops via    n-N-only    true wides and preserves exclusively 
>>> dupe-supressing WIDEn-N type paths. [...]
>>>     
>>>       
>> So a tip of the hat to the originator of the WIDE1-1 concept to solve the 
>> fill-in digi problem.
>>
>> Bob Kirk
>> N3OZB
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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 
>>   
>>     
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>   




More information about the aprssig mailing list