[aprssig] Digpeater setup

[Henk de Groot]

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

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.

Kind regards,

Henk.