aprs.fi discussion group

To facilitate peer support and discussion about aprs.fi I have created an aprs.fi discussion group on Google Groups. A bit like Yahoo groups, you can send and receive group mails using email (just like a regular mailing list), or you can use the web interface, or read the posts using an RSS reader.

If you've got questions on how to use aprs.fi, or if you'd like to share tips or tricks, please join the group and send an email there. I'd also like to encourage experienced users to answer any questions posted by others, if you happen to know the answer. I'd greatly appreciate your support - any time I don't need to spend writing emails I can use for developing new features.

CWOP, Traffic view and Service status, and More

Since CWOP (Citizen Weather Observer Program) users moved to their own IS server pool, aprs.fi has not collected weather data from them. I've connected aprs.fi to the CWOP servers to collect that data again, and the CW* stations should now show up. If you don't wish to see them on the map, you can always hide the WX stations in the Preferences.

Several users have also requested that support for the Google Maps Traffic would be added. It's there now, along with a couple of other popular overlays behind the More button. The traffic data is collected using crowdsourcing methods (Google's view), so it's available on those roads where people use Google Maps to navigate (excluding iPhone users).

The heard and gated maps have also been fixed a bit, they no longer load all the other stations in the view. That was a stupid bug on my part. These views have also received some technical improvements and speedups. As a side-effect I erased the 48-hour history tables, so those views (and the "heard by" tables in the info pages) will be a bit empty for the next day or two. Sorry about that.

The info pages now show symbols together with the callsigns in the tables. Hmm, sorting by symbol doesn't seem to work, though.

There's also a new service status view.

Sortable tables and log Y scale

The tables shown on the info page are now sortable - click on the column header to sort, and click on it again to sort in descending order. The "nearby stations" table doesn't sort nicely, though, since it's actually two tables embedded in a single table, and it's sorted as if it was a single table of content. I'll have to figure out something for it.

I've also changed the igate / digipeater receiver performance graph to use a logarithmic Y scale, so that distances with smaller amount of activity are more visible.

Merry Christmas!

APRS receiving performance graph

The graphs page of APRS igates and digipeaters now shows a new graph which tries to describe how well the station's receiver is performing by plotting the number of position packets received from a given distance during a month. There will be multiple lines, one per month, over the past few months. Here are a few examples:

OH2RCH close to downtown Helsinki, but there have been a few bad GPS fixes:

OH7AA fairly quiet on 144.800, peaks generated by stationary digipeaters:

OH6RDK is a digipeater without any activity within 20 km range (the receiver probably does work at that range, though):

VK2TV-4 has an HF receiver:

As usual, there are a few catches:

• The graphs tell more about the amount of activity within a given distance, than the receiver performance at that range. A receiver in the middle of a big city might hear well from a long distance, but there is simply so much traffic close to the receiver that the linear Y scale of the graph hides the position packets from the distant stations. Maybe I should switch to a logarithmic scale, or would that be too confusing?
• Stations transmitting invalid or fake coordinates will skew the stats. 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.
• AIS support is still in the works, I need to add a method to configure the coordinates of the receiver.

Magic UTF-8 support, weighted callsigns and other updates

The aprs.fi service now supports UTF-8 in most APRS packet types, such as messages, comments and status messages. Using UTF-8 enables proper universal messaging for APRS users. The UTF-8 encoding of Unicode is backwards compatible with ASCII, and it can be transmitted without problems on the APRS-IS and the APRS radio frequencies. It does not require the end-user to manually switch between "compatible ASCII" and "unicode" mode depending on the language or destination, since English text (like this) is transmitted in exactly the same way in both ASCII and UTF-8. It also supports all of the special characters in other languages (åäöæø ÅÄÖÆØ ßüÜ). UTF-8 works on findu.com, too.

I strongly recommend all APRS authors to implement UTF-8 encoding in their APRS software for proper internationalization support! To get some UTF-8 testing packets, send an APRS message to the callsign UTF-8, and my testing responder will respond with four messages containing English text, Scandinavian and German special characters, and a few Japanese words.

In addition to UTF-8, I also added a magic recode feature (inspired by the irssi IRC client), which tries to guess the character set of the original packet based on the character distribution. It currently attempts to support ISO-8859-7, ISO-8859-15, CP437 and CP850. Because of the overlaps between these character sets, this feature can not be made to work perfectly - the task is impossible. It's guesswork. To get your characters to show correctly, please transmit them in UTF-8.


Inspired by weighted tag clouds, callsigns shown in the Other SSIDs list are now weighted according to the time of the last position update from that callsign. If the position was updated within 24 hours, the callsign becomes bigger than usual, and the other way around. For example: KJ4ERJ, WB4APR

The position history database table was migrated to a partitioned table. Or rather, the migration was started - new data is being inserted in a partitioned table, and old data is still in the unpartitioned one. This is a very technical change which does not make a lot of difference to most of you folks, but improves things a lot on the server side. I can now delete old history data in 1-day chunks very quickly with a minimal performance hit. Inserting new data requires less disk I/O and smaller memory buffers (thanks to the partitioned indexes).

I've also upgraded aprs.fi to use Ham::APRS::FAP version 1.13, upgraded the web server software, fixed some XHTML syntax, done some performance tweaks on the real-time map, and added support for APRS targets without a current known position (required for receiving telemetry from a station without a known position).

This upgrade was a big one, and required about an hour of downtime. Sorry for the trouble. I hope I didn't break anything this time.

Maintenance break on Saturday 5th of December

On Saturday, roughly between 18 and 19 UTC, I upgraded operating system components and installed security patches. These upgrades required taking the service down for some time, and even data collection was affected for a short while. Sorry for the trouble!

Before the reboot, the master server had an uptime of 681 days. Thanks go to the UPS and the diesel generator - there have been a few small power outages in Espoo during that time.

In the near future I'll be installing a new master server for aprs.fi, the hardware is already waiting for the OS installation in the basement.

I've also bought an 80 GB Intel X25-M SATA solid-state drive (SSD), a very quick flash-based hard disk-like device. The amount of disk I/O operations is starting to become an issue on aprs.fi, so I'm going to try moving the busiest database tables (which are also the smaller ones) on SSD. We'll see how that improves things! It might even allow me to implement some new features (which require additional I/O capacity).