[Xastir] Smart RELAY digipeating

[Curt, WE7U]

On Wed, 1 Dec 2004, Tapio Sokura wrote:

> I've been watching the traffic on the local 2m APRS network for a while
> with Xastir RELAY digipeating enabled using a serial kiss tnc (without
> kernel ax.25). I haven't looked at the source code (yet), but it looks
> like Xastir digipeats all RELAY packets it hears, as the basic rule
> goes. This results in my station repeating packets that a WIDE
> digipeater 10 km away already digipeated. And then the WIDE digipeater
> digipeats the frame again after Xastir has done the RELAY digipeating.

Question:  Is Xastir digipeating packets for which the "digipeated"
bit associated with the RELAY callsign has already been set?  This
is usually represented by a '*' following "RELAY" on a non-KISS TNC.
If so, the code needs to be fixed to ignore those packets.

I'm curious as to how the WIDE digipeater is digipeating on "WIDE"
before Xastir can digipeat on "RELAY", unless the digipeater is
doing preemptive digipeating and skipping over at least one call
that hasn't been used yet.  I think DigiNed might be capable of
doing such things.


> What I'd like to see is a RELAY option, where I could define a few
> (WIDE) digipeater callsigns that prohibit, when seen in a digipeated
> packet, Xastir from RELAYing the same packet again. This would probably
> require a random (say 2-8 seconds) delay for waiting for the digipeated
> packet before making decisions whether to RELAY or not a given packet.

I think we'd be getting into the realm of "things best handled by
other software".  Digi_Ned would be the prime candidate here.

If you take your KISS TNC and enable it as an AX.25 kernel
networking port, then Xastir and Digi_Ned should both be able to
talk to it.  In that case, turn off RELAY digipeating in Xastir and
let a real package take over digipeating.


> The players:
>    R: fixed station running Xastir with RELAY digipeating enabled
>    M: a mobile station, uses RELAY,WIDE,WIDE path
>    W: a WIDE digipeater
> R and W have a reliable radio path between them
>
> Situation: Both W and R can hear the mobile station. R is using the
> current simple Xastir RELAY digipeating code. The following chain of
> packets is seen:
> frame   packet path
> 1       M -> APRS via RELAY,WIDE,WIDE
> 2	M -> APRS via W*,WIDE,WIDE
> 3       M -> APRS via R*,WIDE,WIDE
> 4	M -> APRS via R,W*,WIDE
>
> We can see that the last two retransmissions are redundant, because the
> W digipeater already got the packet and there's no need for R to
> digipeat the packet.

It looks like the WIDE digipeater is also enabled for RELAY, and
that's why you're seeing the extra packets.  Makes sense.


> Now if Xastir postponed the decision to RELAY or not for a few seconds
> after receiving frame 1, it could watch the band for possible digipeats
> of the packet.

I think that's beyond what we want to be doing, although we kind of
do a similar thing for igating:  If someone else beats us to it we
try to skip igating to RF.


> After thinking what I wrote above for a moment, maybe this could be done
> without user specified digipeater configuration so that whenever a
> packet that is a candidate for RELAYing is heard again on the band, i.e.
> digipeated by anyone, it would not be sent again. Dropping the
> digipeater checking/configuration option might decrease the reliability
> of the network a bit, but on the other hand if a station has RELAY
> digipeating enabled, it should be able to reach a WIDE with a good
> probability.
>
> So what do you think, would this be worth the coding trouble? If this
> was implemented, turning RELAY digipeating on would never hurt (much)
> even in a crowded area. But say if 10 stations configured for dumb RELAY
> digipeating heard a packet, there would be at least 9 extra packets
> heard on the band. If duplicate checking was done before RELAYing,
> ideally the other nine would not key their transmitters after seeing the
> packet is digipeated.

The way to implement this most simply would be to keep a queue of
recently heard packets, like we do in the igating code, and look up
each one before deciding to digipeat.

I'm not interested in writing it, and I think you can see from the
above that I tend to think that implementing that in Xastir would
probably be the wrong place.  I do see some advantages in being a
nice neighbor RF-wise though, as your last couple of paragraphs talk
about.

I still think Digi_Ned would be the right place to implement
something like this, as its main focus is smart digipeating.  If it
doesn't already have provisions for this, Henk might be willing to
add them.

--
Curt, WE7U			         http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"