[MNAPRS] APRS reliability using PHGR and digis as propagation beacons.

[Doug Reed]

This is explained better on the WB4APR APRS web site (see below). 
Basically, PHGR extends the standard PHGxxxx/ beacon text by adding one 
more character at the end, such as PHGxxxx4/, where '4' (or 6, 8, etc) 
is how many times per hour the station beacons. How many beacons your 
local digi hears will indicate how reliable the path is to/from that 
remote location. This trick is for fixed station beacons, not mobile 
stations.

To evaluate your local area, you would need to monitor the local digi 
and log all beacon packets that are heard DIRECT by the digi. If the 
beacon includes PHGR, you need to count now many times the digi has 
heard that beacon over time and assign a reliability number for that 
location and that digi. If every fixed APRS station in the area is 
beaconing using PHGR, we could use software to monitor the beacon 
packets and generate a map of reliable APRS coverage. Wouldn't it be 
nice to see a coverage map of your area where a green dot indicated 75% 
or better channel reliability, yellow is 50% to 75% reliability and red 
is under 50% reliability? It might be interesting to do it over time as 
well. Will the 1 hour or 4 hour map be different from the 24 hour map?

Another interesting option for anyone running an I-gate would be to add 
a filter that looks for beacons heard DIRECT and computes the distance 
between the two stations. The software can alert you to potential band 
openings by looking for distances greater than 200 miles, or whatever 
number you choose. You can bet that if 2M FM APRS can hear a station 200 
miles away, the band is wide open for 2M SSB contacts, probably a lot 
farther away than 200 miles.....

I admit the propagation technique is probably more useful to stations 
outside the metro areas since there is a good chance that in a busy 
metro area, the propagation beacon can easily be covered by another 
station. But in conjunction with monitoring an APRS-IS feed, this could 
become an automated system for detecting unusual propagation conditions. 
Or with a little software, your home station could be testing all 
stations it hears direct to see how far away they are or if they are in 
a state, grid, or county you need for a contest award. Of course you 
don't need PHGR for the last option, but it is useful for other 
automated data collection and easy to do to your beacon, so why not?

73, Doug Reed, N0NAS.


========================================================================
APRS NETWORK PERFORMANCE MEASUREMENT  (PHGR)                 12 Jan 2009
------------------------------------------------------------------------
                                                                   WB4APR
26 Feb 2003  Original proposal for APRS1.2

This proposal suggests the addition of a BYTE of info to the APRS
packet that indicates its transmission periodicity to make overall
network assessment easier.

Due to collisions and the ability of strong nearby stations to always 
win a collision, general statistics of packets-heard cannot be used as a 
measure of APRS network performance.  The ONLY way to measure the
reliability of an APRS channel is the success rate of the "typical
intended user" in the "intended area of interest".  This cannot be
measured by channel statistics because the stronger stations will
always get through no matter how bad the channel (at the expense of  the 
lower power or more distant station)...

So, the BEST measure of packet performance is simply measuring the
statistical performance of "probe" packets that are transmitted from
"the intended user class station" on the edge of the "intended user
coverage area"...  If he gets in X% of the time, then your network is
operating at X% reliability in that area!

Fortunately, every fixed station has a default beacon rate.  We can
use these as probes, if we know what their periodicity is.  One way
is to add a byte somewhere in the packet that can be interpreted as
a periodicity byte.

Since what normally follows a PHGxxxx string is a delimiter and
additional optional free-format text, we can add a digit to the PHG
string for this purpose, and the only impact is a right shift of
the optional free text by one byte.

Knowing how often a "probe" packet is transmitted from one location,
and comparing that to how often it is received somewhere else can
tell you everything about APRS network reliability.  Imagine a
CONTOUR map showing contours of reliability in your area (derived in
real time!).

The single byte is simply a character 1 to 9 or A to Z added onto the
end of the PHG string which indicates PHG packets-per-hour transmitted.
To show that this is an addition to the PHG string, a trailing "/" is
used as a separator to any other text that follows.

Then software can watch these PHGR probes and COUNT statistics and 
derive REASONABLE reliabilty figures, plots and statistics!

By adding it to PHG, it is 100% backwards compatible to existing
parsing of PHG data...  To give it a name, instead of "PROBES" we simply
call it the "PHGR" data...  Here is the FORMAL SPEC for PHGR:

   PHG is (and remains)  "PHGabcd........"

   PHGR is  "PHGabcdr/......

   Where a,b,c,d are as defined in the APRS spec.
   Where r is the integer rate of PHGR packets XMTD in packets per hour
           expressed as a single byte 1-9 and A-Z (A is 10 for example).

And we add a specific "/" separator between the PHGR and any following
text to help flag this as the new PHGR format.  All existing software on
receive should still receive the "PHGabcd" with no impact, since no
following character was ever specified..   And since the only field that
follows a PHG is a variable length free-text comment field (except DF),
the addition of the "/" on the front of that field does not disrupt
understanding of the comment field.

On transmit, most client applications transmit either a "/" or a SPACE
as a separator before any free text that follows anyway, and these
delimiters are ignored as leading delimiters in the free field
comment text, so in this case, we are just forcing that now to be a "/"
to add reliability in recognizing the new PHGR digit.

EXCEPTIONS:

1) When FREQUENCY was added as the first 10 bytes of free-field text
in the 2007+ time frame, this frequency is offset if the full PHGR is
used, and this will result in failed parsing of the FREQUENCY.  So do
not use PHGR when FREQUENCY is also included in the packet.

2) If a PHGR packet is sent out of its normal schedule (for
example, in response to a QUERY), then the "R" byte is stuffed with a
"0" to show that it is an unscheduled PHGR packet and should not be used
in Statistical analysis of packets transmtted and received unless both
counts are both incremented by one, depending on the choice of the
analyzing software.  Or an OLD PHG format may be sent.

3) It is very important that EVERYONE understand the purpose of PHGR is
for measuring network reliability from a "typical intended user" at
a "particular location in an intended area of coverage" and that by that 
definition, only fixed stations are suitable and obviously should not be 
applied to non typical user stations such as:

    * Wide area Digipeaters (we can all hear them anyway...)
    * Digipeaters or any station with variable rates and paths
    * Moving stations,
    * any stations beaconing more often than once every 6 minutes
    * any stations beaconing less often that once every hour
    * any DF station sending a DF report

4) If you want to measure a mobile over an area, then you dont need 
PHGR! Simply set a fixed rate, drive around, and then count your own hits.

Did I miss something or is this the no cost holy grail of measuring
network performance?  Wow, I'd love to see the kind of analysis and
display software that could use this info...  Especially reliability
contours drawn on maps!

Bob, WB4APR