[aprssig] Digpeater setup

[Wes Johnston]

In the kpc3 8.x firmware, UIDIGI uses a different dupe suppression 
method than UIFLOOD or UITRACE does.  UIDIGI looks for it's callsign in 
the path with a * beside it.  UIFLOOD and UITRACE use a checksum on the 
data portion of the packet for dupe suppression.  The good news is that 
kpc3plus 9.x firmware uses a checksum on UIDIGI, UITRACE and UIFLOOD, so 
neither case will happen with the newest KPC firmware..

Here are two examples of how mixing RELAY and Wn-n cause excessive 
dupes.  One way involves mixing and matching UIDIGI and UIFLOOD, the 2nd 
example is multiple first hops under UIDIGI rules.

Case 1: I transmit a packet with a path of RELAY,WIDE3-3.  It is heard 
directly by my local digi.  He digi's it, and it comes out like this: 
KD4RDB*,WIDE3-3.  The neighboring digi hears the packet and decrements 
the WIDE2-2 and it comes out like this: KD4RDB*,WIDE3-2.  Now, my local 
digi hears it again.  The UIFLOOD parm has one hop left, and it will 
digipeat it under the UIFLOOD rules... and it'll look like this: 
KD4RDB*,WIDE3-1. 

My digipeater digipeated the packet twice... once my UIDIGI rules, once 
by UIFLOOD rules.  Since the "left hand" doesn't know what the "right 
hand" is doing.... because UIDIGI and UIFLOOD use two different separate 
dupe checkers, the packet bounces around.

Case 2:I transmit a packet with a path of RELAY,WIDE.  It is heard by 
three home RELAY stations around me.  Each of them forwards a copy to 
the local digipeater.  so the packet arrives at the local digipeater 
three times... Since none of the home RELAY stations do call 
substitution, the packet arrives at the digi 3 times looking like this: 
RELAY*,WIDE.  Since WIDE (without the n-n) is a UIDIGI function, the 
test the digi does to see if it wants to digipeat this packet is "Is my 
callsign already in the packet with a * beside it?".  The answer is no 
in each case, and the digi will digipeat the same packet three times.  
It will come out of the digipeater three times looking like 
this:RELAY*,WIDE*. 

Wes

Robbie - WA9INF wrote:

> Bob,
>
> Robert Bruninga wrote:
>
>>>>> dsparks at pobox.com 3/30/05 11:35:17 PM >>>
>>>>
>>>
>>> ... We now recommend that use of WIDE and RELAY are obsolete ... 
>>> because [they do]  more damage than good.  
>>
>>
>>
>>> ... but  isn't there a role to be played by a modified RELAY digi?  
>>> What about a  setup where such a station keeps track of recent 
>>> [packets] received directly,  and then digis them only *IF* they 
>>> aren't heard being resent by a WIDE digi within a certain period of 
>>> time, like 20 sec., let's say?
>>
>>
>>
>> Absolutely, that is a greaat solution.  But it should not be
>> based on the dupe-generating-RELAY legacy.  SImply let
>> that same algorithm work on WIDEn-N packets at that
>> "fill-in-digi" location.  We must wean ourselves from starting
>> paths with RELAY which has no really good dupe-elimination
>> process in most of the digis out there.
>
>
> Please explain how RELAY causes DUPES? If I am understanding it, a 
> dupe is when a station retransmits a packet that was digipeated by a 
> previous RELAY. Not when two stations digipeats a packet it heard from 
> the tracker direct.. That is not DUPLICATION.. WIDEn-N digipeaters 
> also attempt to digipeat what it hears direct. If that tracker is 
> using only WIDE2-2 in its path, and both WIDEn-N hears it, then 
> digipeats it, isn't that DUPEs also according to the way you make is 
> seem?
>
> So, if home RELAY fill ins are spaced properly, what is the problem? 
> They are doing what they were put there to do assuming that the 
> tracker couldn't reach a WIDEn. No other home station RELAY that 
> doesn't hear that tracker direct, will digipeat the tracker because 
> the RELAY in the original path has been stripped and replaced with the 
> original RELAY.
>
> I fail to understand your statement that home RELAYs cause so much 
> duplication.. Too many definitely can harm a network I agree because 
> of all the collisions of the RELAYs that hear the tracker direct.
>
> So in short, a DUPE to me is a packet sent by a RELAY that was 
> received from another RELAY. It is not a DUPE if two RELAYs attempt to 
> digipeat the same received direct from the tracker's packet.
>
> Same as WIDE by itself, should not cause a DUPE, but if more than one 
> WIDE heard the direct packet, they would digipeat what they heard. 
> WIDE,WIDE or RELAY,RELAY could cause one station to DUPLICATE its 
> previous digipeated packet because it sees RELAY or WIDE again from 
> the other digipeater...
>
>> But it is fantastic if we can have smart-digis do as you
>> suggest.  But just let them work on WIDEn-N and not
>> RELAY that is flooding us with dupes all the rest of
>> the time...
>>
>
> I would assume again that you mean that multiple stations hearing the 
> trackers packet direct that you say is flooding us with all the dupes?
>
> Simple solution is to limit unnecessary home RELAYs.
>
> Robbie
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig