aprx is APRS iGate / digipeater server software for the *nix environment by Matti Aarnio. In my case, I am developing and running on RPi / Rasbpian Wheezy.
This article comprises notes on the digipeater module as modified over recent weeks to address shortcomings in its operation.
VHF APRS performance in capturing position reports (posits) of moving stations is very dependent on low channel utilisation, and means to restrict the area over which posits are heard are key to achieving good performance.
Hopcount
Determining hopcount reliably is fraught with problems. The designers of AX.25 did not have the foresight to include a mandated hop count in the header, and the scheme used by APRS is exploitation of the TRACE concept blended with Bruniga’s “New N Paradigm”. The problem is that there are not detailed unique specifications of how a digipeater must modify frame headers, and various authors implement their own ideas. There are main issues:
- some digipeaters do not do call sign substitution to provide a trace path so actual digis cannot be reliably counted; and
- some packet originators choose path elements of WIDEN-m where m<>N, and an observer of a packet in transit cannot imply hops consumed from the WIDE trace entries.
Issue 1 is likely to result in an underestimate of hops used, but that will not unfairly discard packets.
Issue 2 is likely to result in an overestimate of hops requested, and so it is unsafe to limit on a perception of hops requested unless the packet is heard direct, as it may unfairly discard packets.
Notwithstanding these problems, most digis do provide a trace path of packets, and whilst not perfect, it is usable.
My changes to the aprx code count the non-generic callsigns in the via path that have the H bit set (Has been repeated) in the received packet, and will discard the packet if that number is greater than maxops specified / digi sections of the aprx.config. maxhops can be from 0 to 7 incl. So, maxhops can be used to separately limit the number of hops overall and for each digi source.
My recommendation is to set maxreq to 2 or less, and depend on the digi hop count to limit the lifetime of packets. Maxreq could be set to 3 to stop excessive packet paths closer to the source.
For a fill-in digi, the DIRECTONLY facility is a simpler restriction to configure, but maxreq is still effective.
DIRECTONLY
The digi code has been revised to flag any packet that has the H bit set on the first entry in the VIA list as not direct, so packets that are not so marked will be the only packets repeated in DIRECTONLY mode (save some repeats of faulty packets for diagnostic purposes). The changes made should make this process more reliable.
Filtering
My own view is that the use of VHF APRS for effective real time posits for moving stations is at odds with use for ‘batch’ traffic like messaging etc… though I know that some people think it has reached its use-by-date for posits and is only good for batch traffic.
Recent experience has shown a dramatic improvement in tracking performance in my own area when the mindless iGating of a fellow’s buddies three repeater hops away ceased (and some of those buddies’ posits had already been heard three times in this area).
To preserve channel bandwidth for ‘time-is-of-the-essence’ traffic, I have implemented a filter to demonstrate methods of restricting the propagation of traffic wider than needed to have a good chance of being submitted by one of several iGates. More in a following note after trial in a wide area spot.
Getting my fork of aprx
The repo is at https://github.com/owenduffy/aprx .
Periodic Debian package builds for RPi are at https://owenduffy.net/files/aprx/ .
Update
15/10/2014
Updated to show use of maxhops as per commit 2b55e7a (see man page).