[Xastir] Smart RELAY digipeating

Henk de Groot henk.de.groot at hetnet.nl
Sun Dec 26 08:13:44 EST 2004


Hello Curt, Tapio and others,

I have a huge backlog on my e-mail (blame my QRL), hence, a very late 
response from me...

At 08:44 1-12-2004 -0800, Curt, WE7U wrote:
>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.

As I read it, both Xastir and the DIGI reacted on the RELAY call.

(the > lines are from Tapio Sokura <oh2kku at iki.fi>)
> > 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.

Yes, that looks like an option. Currently all digipeater implementations 
receive a packet, process it and then queue it for transmission. Your 
proposal means that then next recieved packet should de-queue a packet 
already in the transmit queue. Also a digipeater shall not change the order 
of packets, so that means that *all* packets for transmission shall be delayed.

I discussed your kind of proposal before with Bob on the APRSSIG. Bob has a 
different view: overlap sending! That means that if the packet is received 
by Xastir and the DIGI, both queue it for transmission and send it right 
away (in other words: at the same time). No air time is wasted and the DIGI 
will not repeat the packet send by Xastir since it does not receive it due 
to its own transmission. Other stations will receive either the copy send 
out by Xastir or the one send out by the DIGI. Due to the FM capture effect 
only a limited station will receive neither due to interferrence of both 
stations, but that happens when they are in the same area as Xastir and the 
Digi. In that case there is a very good chance they got the original packet 
and do not need the copy!

This is the way Bob thinks it should work, advantage is more efficient use 
of the specturm and the most rapid way to spread packets. There is no real 
drawback. Some hams are horrified by the suggestion to send simutaneously - 
we all learned that his is not-done - here is a situation where we have to 
utilize it...

> > 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.

By using an intelligent digipeater you can save 1 transmission in this 
scenario, the WIDE should not do step 4) if it rememberd that it already 
send the same packet in step 2). DIGI_NED will not do step 4).

When using overlap sending then 2 and 3 happen at the same time, it will 
only take the time of 1 packet transmission. Now you see why Bob wants 
overlap-sending since otherwise the time for 1 packet is wasted and it also 
introduces 1 packet delay.

> > 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.

So, instead of postponing Xastir should send the packet immediately and not 
wait for the digipeater to start its transmission...

>I still think Digi_Ned would be the right place to implement
>something like this, as its main focus is smart digipeating.  If it

Yes, that is in general the way to go, but in this case there is no 
problem. Just make sure that Persist is set so that is doesn't postpone 
transmissions (255 on normal TNC's, 0 on Kenwoods and maybe Alinco's). So 
you receive, process and queue and when the channel is clear immediately 
throw out the packet. Both Xastir and the Digi will assess that the channel 
is clear and throw out the packet at the same time (together with all the 
other RELAY stations you have in the area). With this approach there is 
also no problem to have many RELAY stations in the area. A weak station 
will hit only one RELAY, a strong station will be heard by the DIGI anyway. 
All the RELAY stations together take only 1 packet time. Think about it, it 
takes a bit of mind bending but in the end you have to agree this might 
acutally work as Bob envisioned.

Kind regards,

Henk.





More information about the Xastir mailing list