This section of the Aprs.fi user guide describes the info pages.
The info page summarizes most information aprs.fi has on an APRS station, item, object or AIS vessel. It shows the collected information in a table, a small static map with the most recent received position, and provides links to other pages with more details and history.
If the packets seems to have originated from the RF side of the network, the path advisor will comment on the relative "goodness" of the packets APRS path settings. The advisor report appears right after the Last path on the info page. It will count the amount of total hops the packet seems to have traversed, and if the number is higher than 3, the path is considered suboptimal.
The advisor also suggests using the New-N paths of WIDE1-1,WIDE2-1 or WIDE1-1,WIDE2-2 which seem to be the most commonly accepted paths. It also gives advice on invalid usage of RELAY and WIDE1-1 when they're not the first component of the path, and suggests replacing RELAY with WIDE1-1.
There are different opinions on "good" settings, and there are regional differences too. I believe the settings offered are good for most environments. It doesn't really matter so much if one uses TRACE or WIDE, as long as the total amount of digipeaters isn't very large. 2 is good in areas with good coverage digipeaters and igates, 3 is usually good elsewhere. 5, 6 or 7 is, well, not good.
The info page also gives advice if the packet transmit rate seems high. It calculates the arithmetic mean (average) interval between recently transmitted packets. If the average interval falls below 30 seconds, the following advice is shown:
This station is transmitting packets at a high rate, which can cause congestion in the APRS network.
If the interval falls below 15 seconds, the following advice is shown:
This station is transmitting packets at a very high rate, which causes serious congestion in the APRS network. This could be considered an abuse of the network resources.
Up to last 50 packets from a station are considered, but the backwards-going lookup stops at the first 1-hour gap between packets, the intention being to look at the last or current trip of a vehicle. The interval is only calculated if there are at least 3 packets in the last trip. Because an average is used, this shouldn't trigger too easily from bursts generated by Smart Beaconing.
There are some ideas how to make this more meaningful. I've been thinking of an algorithm to calculate some sort of fuzzy "network loading" value by multiplying the packet rate by the amount of digipeater hops requested in the packets and using the result to trigger the nagging. This would allow a higher rate to be used with no digipeater path, but trigger more quickly when a 3-hop path is used. It would also handle proportional pathing by looking at the path of each packet separately.
This is a table of other nearby stations which have transmitted their position within the past 30 days. To see a longer list, click on show more.
aprs.fi collects monthly summaries of digipeater and igate statistics. The info page shows both a table of digipeaters and igates which heard the given station, and (if the station is a digipeater or igate) which other stations where heard by that station. The most recently updated entries are shown using a larger font.
These statistics are usually somewhat correct, but there are several caveats, and as you've probably heard – there are lies, damn lies, and statistics.
On the info graphs page various station statistics are shown in diagrams:
Graphs for which no data is available are not drawn. Currently, the graphs only go back a few days, but this will probably improve in the future.
aprs.fi user guide