[aprssig] Digpeater setup
aprs at kd4rdb.com
Thu Mar 31 12:42:41 CST 2005
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:
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
Robbie - WA9INF wrote:
> 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
> 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.
> aprssig mailing list
> aprssig at lists.tapr.org
More information about the aprssig