Single-target APRS packet paths

The APRS packet path plotting now works while tracking a single target. As a natural side-effect, all of the stations used as digipeaters and igates by the tracked target will also be shown on the map.

On Saturday I also made some significant changes in the backend code, which should make it scale out a bit better. I added some more in-memory caching which should speed things up so that the addition of things like APRS packet paths will not cause a significant performance hit.

"First heard" algorithm fix, and APRS-IS server failover

I've just fixed the "first heard by" algorithm to mark the igate as the first receiving station, when an intact WIDE1-1,WIDE2-1 path is seen. It was incorrectly guessing that the packet might have been digipeated because there is a WIDE2-1 in there, but the untouched WIDE1-1 clearly says that the packet has not been digipeated yet.

I've also added support for failing over to secondary APRS-IS servers automatically, so now I don't have to do anything manually if my own APRS-IS server fails (or is taken down for maintenance). This should prevent today's outage from happening again.

A little outage in APRS data collection

While I was at the hosting site adding memory to the second aprs.fi frontend today, I also did maintenance on the Sun Enterprise 4500 server which hosts finland.aprs2.net (the Tier 2 APRS-IS server which aprs.fi uses as the data source) and the aprs.fi backup database. So I configured the primary aprs.fi server to connect to another APRS-IS server while finland.aprs2.net was down, but made a mistake in the configuration, so the APRS-IS data collection broke. I didn't notice the alarms which it triggered, because I was working hard with the memory upgrade and the Sun reboot.

As a result, aprs.fi didn't collect APRS data between 11:35:43 UTC and 14:21:13 UTC. Sorry about that, I'll try to be more careful next time.

The memory upgrade itself went fine. The server should perform quite well for a while now.

Frontend memory upgrade on Sunday

I'll be upgrading the second aprs.fi frontend web server from 4 GB to 8 GB of RAM tomorrow. I'll do the installation some time during Sunday afternoon Finnish local time (that'll be Sunday morning in the US). I'll move it's IP address to the primary frontend server for the duration of the upgrade, so the service should be available all the time (unless something unexpected happens).

The upgrade should speed up the second frontend a bit (not that it would really have been slow before), and make it do the job for another year or so. It's been a gig or two on the swap before, but there hasn't been significant swap I/O happening normally, so it hasn't really been a problem. This is just a proactive upgrade to keep it performing as well as before, with the increased usage.

Multi-hop APRS path display

I've now improved the APRS packet path display to show multi-hop packet paths. The other limitations are still there: If one of the hops is well outside the current view, that hop will not be displayed on the packet path display.

Hrvatski APRS

Thanks to Gordan, 9A6AIV, aprs.fi is now available in the Croatian language! That brings us to 19 languages, which I find quite amazing.

APRS path lines

Quite a few of you have asked for some sort of visualization for APRS packet paths. I've just finished a partial implementation of it, and installed it on the production aprs.fi system.

It currently shows the path of a single packet, when you point an APRS station or a track point with the mouse cursor. In the screen shot on the right I had the mouse cursor pointing to the oldest waypoint of OH7FDN, and that position packet was relayed by the digipeater OH7RAA, and forwarded to the APRS-IS by the igate OH7AA.

There are a couple of limitations in this implementation:

1. It currently only shows the first digipeater found in the path, and the igate.
2. The digipeater and the igate must be visible on the map (or just outside the visible map area) - you might have to zoom out to make them visible.
3. The digipeater and the igate must be visible on the map - if you're tracking a single station (you've just searched for a callsign), you'll have to click on "stop tracking".
4. It currently only works in the real-time view - it doesn't work if you select a day in the past (because it only shows a single station in that mode).

I'll try to improve it in the future, and get rid of these limitations. This is just a start... feedback is welcome!

Features like this always come with a performance penalty. To provide the additional eye candy I'll have to pass on more data to the web browser. It will consume a bit more memory, and make the web browser slow down some more. I certainly hope it's worth it.

Deleting old PHG data

You can now delete your PHG circle by sending the PHG extensions with zero power, zero gain: 'PHG0000'. Some users have been testing PHG with their mobile station's callsign, and need to hide the old circle after finishing with the testing.

If you simply stop transmitting the PHG data, it will still be present in the aprs.fi database. There are a bunch of digipeaters using multiple different comment texts in a round-robin fashion, and some of them only transmit the PHG extension once per three position packets. So, if I'd delete the PHG data from the database whenever the PHG extension is missing, those digis would only be shown with a PHG circle 1/3rd of the time.

Magyar translation

Thanks to HA5CQZ (flicker) and HG1DFB, there's now a Hungarian translation of aprs.fi running! Thank you, guys!