[aprssig] Digpeater setup
Henk de Groot
henk.de.groot at hetnet.nl
Sat Apr 2 09:26:55 CST 2005
Robert Bruninga schreef:
> Agree, completely. The algorithm you describe is perfect
> for fill-in digis and would be a great boon to APRS. I think
> DIGI__NED can do it?
No, it can't. The algorithm described requires the packet to be saved for
transmission at a later time. DIGI_NED currently works packet by packet,
it receives them, processes it and if needed sends the packet to the
output ports. After that it only retains a litte information about the
packet for DUPE checking.
(note: for sake of readability I will address the "fill-in" digi as RELAY,
I know that the RELAY alias is depricated).
This proposal (hold off to see if the main digi digipeated it and then
send if it was not the case) has been up before. I have not found a good
way to implement anything like this without major drawbacks.
My bigest problem is that this method can change the order of packets. If
a mobile station uses corner-pegging for example and due to this sends 2
packets within a short time then the first packet could be delayed by the
RELAY while the second one is heard direct by the digipeater. So then
after a while the RELAY sends the first packet and the two packets will
travel in reverse order through the APRS network. This will flip the
direction of the mobile or make is jump backwards.
APRS is a real-time system so I think delaying packets may lead to very
Another problem is that you not always receive you digi error free, so you
may not hear the echo from the digi, this leads to double transmissions of
the same packet.
Further more there are implementation problems:
1) First of all you have to know that the first reception is the original
and not a copy. DIGI_NED has code for that, but it is not as simple as it
looks at first glance (especially when taking digipeating on destination
SSID in consideration).
2) Each original packet has to be timestamped and saved so it can be
transmitted later. But: does this apply to all packets or only specific
packets like position packets? So does how does a generic digi know about
the type of packets it receives. Currenly the DIGI_NED digipeater core
doesn't know anything APRS specific.
3) How to detect that a copy came from the main-digi. Especially with the
now "old" WIDEn-N this was a problem. You could just as well get a copy
from another RELAY.
4) The main-digi should not do the same kind of waiting. In fact, there
could also be several other RELAY stations all waiting for the main-digi
and then send the packet at the same time. So there needs to be a
distiction between being a main-digi and a fill-in digi and there should
not be more than one fill-in digi in the area.
I think that the only correct way for a RELAY to work, is to use overlap
sending - i.e. transmit simultaneously with the DIGI. When the DIGI did
not hear it, it hears the packet from the RELAY. If the DIGI heared it,
then the DIGI and the RELAY transmit at the same time taking only 1 packet
worth of time. If I understood Bob correctly in the past, this was the way
APRS is supposed to work. It provides a very simple fail save mechanism to
deal with these kind of situations without requiring anything smart from
the fill-in digi and without introducing extra delays or risk messing up
the packet order.
More information about the aprssig