Aprs.fi Info pages

This section of the Aprs.fi user guide describes the info pages.

Info page

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.

  • Comment : The station's comment text, transmitted together with the position.
  • Last status : The most recent status message transmitted.
  • Location : The last known location of the station. The coordinates are shown in the preferred format (see Preferences if you wish to change this). A maidenhead QTH locator is also shown, and a list of some cities or towns which are close, together with distance and bearing from the each town to the station.
  • Last position : The time when the last known position packet was transmitted.
  • Course : The course information from the last position packet (if available).
  • Speed : The speed information from the last position packet (if available).
  • Last telemetry : The most recent telemetry measurements received.
  • Last WX report : The most recent weather report from the station.
  • Last path : The APRS packet path from the last position packet, complemented with the APRS digipeater path advisor, where applicable.
  • Positions stored : The amount of position packets stored in the database.
  • Packet rate : The average interval between packets.
  • Other SSIDs : A list of other APRS stations having the same callsign but different SSID. The ones which have recently sent a position are shown with a larger font.

Path advisor

Path good image

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.

Packet rate advisor

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.

Nearby stations

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.

Stations heard by X, and stations which heard Y

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.

  • The APRS-IS network that feeds the APRS packets from the igates to aprs.fi does duplicate suppression. Only the first gated copy of a packet traverses the entire network. All other duplicate copies seen within 30 seconds after the first packet are dropped by APRS-IS. A packet which is heard by multiple igates normally gets credited only for a single igate.
  • A lot of digipeaters do not add their own callsign in the packet's path when retransmitting a packet. aprs.fi cannot possibly know about those.
  • A lot of digipeaters do callsign substitution instead of insertion, replacing original path components. A packet with a path of OH7RDÖ,WIDE2-1 could have been a WIDE1-1,WIDE2-1 packet in the first place, and gone through OH7RDÖ and another unknown digipeater.
  • The aprs.fi "first heard" algorithm tries to go on the safe side: if it's not sure, it doesn't count as directly heard. But even then, some incorrect overly long paths are shown.
  • Stations transmitting invalid or fake coordinates will skew these statistics. If the transmitting station claims to be 1000 km away (due to a bad GPS fix), my best guess can only be that the station actually is that far away.
  • Items and objects are not shown here, since they are usually far away from the transmitter which transmitted the packets.

Info graphs

On the info graphs page various station statistics are shown in diagrams:

  • Amount of APRS packets transmitted per hour
  • New positions received per hour (positions which are actually new and different from the previous transmitted position)
  • Reported speed of the station
  • For digipeaters, igates and AIS receivers:
    • Amount of packets heard per hour (very much underestimated, due to APRS-IS duplicate filtering)
    • A monthly receiver performance report
  • For igates:
    • The amount of packets gated to the APRS-IS per hour (underestimated due to duplicate filtering)

fullblock

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.

  • OH7RDA, a digipeater, does not show a speed graph, but there is a nice receiver distance report in the end.

aprs.fi user guide