[aprssig] The final WIDE1-1,WIDE2-1 solution!

[Wes Johnston]

I was waiting on an aswer for this too... but I may be able to head it
off at the question....

Pete, I know you know this.... but I want to lay a foundation.... KPC
digipeaters can digi 2 ways (actually, it's 3ways, but for this
discussion, 2).  They can digi with 1)UIDIGI which simple does a
callsign substitution, or 2) they can UIFLOOD or UITRACE.  What we do
know is that UIDIGI does not use the checksum dupe supression that
UIFLOOD and UITRACE do.  The question becomes do UIFLOOD and UITRACE use
the same checksum pool?  In other words if something is digipeated by
UIFLOOD, can it be digipeated again under UITRACE rules?

The only way to  get a single digi to digi a call would be to put WIDE
in UIFLOOD _or_ UITRACE.  If you put it in both, one or the other will
take precedence.. and it'll take precedence the same way each time.  Or
some lid was to run a path like WIDE2-2,TRACE2-2.

Now, if we put WIDE2-2 in UIDIGI, the check sum of that packet is not
placed in with the rest of the checksums for UITRACE and UIFLOOD
packets. but the word WIDE2-2 is replaced with the callsign of the
digi.   Ahh... I'm beginning to see the light.... If a digi were to
catch the first hop as UIDIGI WIDE1-1, then if teh packet came around
again with another WIDEn-n it'd be digipeated again... BUT... it won't
happen because no digi will use WIDE1-1 in the UIDIGI field.... only
home stations, and they don't digi UIFLOOD or UITRACE anyway....

So we have a mutually exclusive case... either your digipeater digipeats
WIDEx-y under UIdigi rules OR it uses UIFLOOD/UITRACE.  I think this
works for the trapN-N as well....because of callsign substitution -
unless some lid runs a whacky path.

Wes

AE5PL Lists wrote:

>Truly I am not trying to rain on the parade but I haven't seen an answer
>to the question that I posted yesterday:
>
>"Was it determined if the KPC 3+ uses the same dupe checking for UIDigi
>and UITrace as UIFlood or does it only look for it's call earlier on in
>the path for UITrace and UIDigi?  If the latter, won't we end up with a
>bunch of dupes again because of the various callsign substitutions?"
>(slightly reworded)
>
>I don't know the answer to the question.  I think this has been asked
>before but I couldn't find an answer in the posts.  I am hoping that
>they are handled the same as UIFlood so only 8.2 firmware and before
>(where dupe checking is VERY broken) would be adversely affected.  But I
>think this question needs to be answered before this configuration is
>settled on.
>
>73,
>
>Pete Loveall AE5PL
>mailto:pete at ae5pl.net 
>
>  
>
>>-----Original Message-----
>>From: Robert Bruninga
>>Posted At: Saturday, April 02, 2005 9:27 AM
>>Subject: Re: [aprssig] The final WIDE1-1,WIDE2-1 solution!
>>
>>    
>>
>>>>>bruninga at usna.edu 4/2/05 9:55:27 AM >>>
>>>>>          
>>>>>
>>Having slept on it overnight (and hardly sleeping at the
>>excitement) I'm still very excited about this solution to the 
>>RELAY and WIDE dupe problem and the fill-in
>>problem.   Just everythig comes up roses... (though we
>>may need some tweaking in LA)
>>
>>1) All legacy paths are dropped.  Everything is simplified
>>2) User recommendations are simple and consistent
>>3) We still get a  universal one hop (WIDE1-1 simply replaces RELAY)
>>4) ALL paths use the perfect n-N dupe-elimination
>>5) We can still use fill-in digis and they can be dumb TNC's
>>6) Each digi can now have 4 traps from 7-7 to 4-4 if they want...
>>7) PacComm digis work seamlessly with WIDE1-1,WIDE2-1
>>
>>Once we get the 13 year old mess cleaned up to this new n-N 
>>Paradigm, then we will have a consistent baseline on which to 
>>begin to develop the network ideas of Pete and many others as 
>>we can get people to upgrade digis to new hardware or 
>>software, because then we only have one consistent legacy to 
>>have to deal with...
>>
>>Am I dreaming or are we onto something here....?
>>    
>>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>  
>