aprs.fi iOS app for iPhone and iPad!

The new, official aprs.fi iOS application went live on the App Store a week back. It runs on the iPhone and iPad, and currently supports iOS 7 to iOS 9. Purchase once – run on up to 10 devices associated to the same iTunes accounts!

It provides immediate, near-real-time visibility to APRS traffic around you, and has quick search-as-you-type station and address search functions. Zoom around the world as easily as on aprs.fi, or look up stations by their callsign. Multiple stations can be tracked at the same time.

Telemetry, weather, and APRS station statistics can be viewed as graphs.

The new high-resolution symbol graphics look crisp on Retina displays. iOS 9 Split-Screen multitasking is supported on applicable devices (iPad Air 2, iPad Pro, iPad mini 4, and newer). Landscape and portrait modes work too, of course.

Position beaconing to aprs.fi works great, although, as usual, GPS use in the background reduces battery life noticeably. The minimum transmit interval slider can be used to reduce transmission rate, allowing the GPS to turn off for longer periods of time. The app does not require location information, but it can be helpful for automatic map centering and calculating distances.

A little expectation management needs to be done at this point: Some future features will only be available for a small additional yearly price, through an in-app purchase. That price will be lower than the purchase price of the app. The rationale behind this is simple: There's only a rather small number of APRS iOS users around the world, and once most of them have bought the app once, there will be no more income from the app, ever. Having a small, steady income nicely keeps up the motivation in maintaining and improving the application in the future. A few APRS apps have already been practically abandoned on the app store, with no updates in one, two or three years. The original app, simply named "APRS" recently got deleted and replaced with something completely unrelated.

Some new features, and all bug fixes of course, will be free updates. The current version does not even include any support for in-app purchasing yet – it'll maybe come up some time next year, after the base features are ready.

Purchase the app now, and you'll get a nice APRS web site for free!

Frequently Asked Questions

What about Android?

Yes, maybe later. It takes a lot of time to produce these things. I concentrated on iOS mostly because all my devices happen to be iOS, I have some previous experience on iOS development, and APRSDroid is already so good.

Filtering, I wish to hide AIS vessels and/or weather stations?

Yes, that's on the top of my list of things to do, I can't live without them either.

Can not beacon to APRS-IS?

Not yet! This is the aprs.fi app, not an APRS-IS app, so it talks primarily to the aprs.fi service, not other services. Beaconing to APRS-IS will come later, stay tuned.

Connecting to the aprs.fi database makes the immediate real-time view happen, so that there's no need to wait 30 minutes for everyone to transmit their position once after opening the app. On the downside, if aprs.fi happens to be down, the app doesn't do much either. Luckily aprs.fi has proven to be very stable during its operation since 2007.

Messaging?

Yes, of course, later.

New symbol graphics and better support for mobile devices

Old symbols, scaled up, pixels obvious

[updated 2015-11-03: the set is now available on github.]

I've just upgraded aprs.fi to use my new APRS symbol graphics set. The new symbols are drawn in vector format (as opposed to a raster format at a fixed resolution), allowing them to be rendered at larger and smaller sizes without distortion or blurriness. The new symbols are slightly larger than the old ones, making them easier to recognise on modern displays having smaller pixels than the old ones. They're also available in double resolution so that they're properly sharp on the 4K/retina displays found on many modern tablets, phones and computers!

New symbols, scaled up - no pixelation!

One downside is that they are just a little bit bigger than the old ones, taking up more space on the screen. On the other hand, the old ones were a bit too small on modern displays, and the very small resolution did make it hard to understand what the symbol tried to mimic.

The new aprs.fi symbol set is available as open source on GitHub, in both vector (Adobe Illustrator/PDF) and raster (PNG) formats. Other APRS applications may then use them, too, at no cost. Raster renderings are available in 24x24, 48x48, 64x64 and 128x128 pixel resolutions - drawing from raster sprites in apps is usually quicker and easier than working with the vector source material. Having the vector sources makes it possible to improve them and and replace individual symbols easily. If you need to render other resolutions or make some other fine tuning, you can run Illustrator for free for 30 days. The symbol set release even comes with a little piece of javascript which crunches out the 3 PNG files (primary, secondary, overlay characters) at the 4 resolutions in a few seconds.

Naturally I did not draw all of the symbols myself. Many are loosely or strongly based on the original symbol graphics, primarily to keep the familiar and consistent look. Some symbols I obtained from other sources, such as Wikipedia. In those cases I picked SVG versions which allow commercial reuse (source known, and the work is placed on public domain, or with a CC license which allows adaptation and commercial reuse). In any case, the source and copyright information is documented separately for each symbol.

The aprs.fi symbol graphics set does not contain additional symbols for overlays yet, mostly because it takes lots and lots of time to draw them, and the effort it took to create this set was pretty high already. Maybe later!

There is one obvious difference in the new symbol set: the "ham store" symbol has been replaced with a more generic "store" shopping cart, reflecting the current \h symbol definition in the master index. Please use the 'H' overlay character to specify an amateur radio shop.

To complement the symbol graphics, I've previously published a machine-readable (CSV/JSON/XML/YAML) APRS symbol description index, which is easier to integrate in applications than Bob's master list.

Improved mobile device support

aprs.fi will now work better than before on mobile devices. I fixed the signup/login flow and most of the text and data table views to scale more nicely on small devices, allowing  horizontal scrolling of tables. It'll need some more work to make it very nice, but this is a good start.

OpenStreetMap available again

Earlier this year aprs.fi was unavailable for a short while after Google disabled Maps API access due to mixed OSM/Google content being visible on the site.

I now spent a couple evenings setting up OSM again in a way that would not interfere with Google's policy of not allowing Google content such as Street View or address search results to be shown on top of non-Google maps. The result of that work is now live on aprs.fi.

OpenStreetMap maps are again visible, but Street View buttons and controls are hidden while in OSM mode.

While using OSM, address searches are done by using the GeoNames database. City lookups work quite well, but address searches do not seem to work, at least not for Finland. City/country lookups do not return information on how large the found place is, so zoom level does not adjust automatically to cover the place.

Beware: Cookies.

Credit: star5112 / Flickr Creative Commons

This is not the feature I actually wanted to implement next, but here goes.

aprs.fi now displays one of those oh-so-common warnings saying "This site uses cookies". There is some code in there to try to show the warning only to visitors from the European Union, but due to the inherent inaccuracy of GeoIP-type lookups, it may fail either way for some users.

aprs.fi has used cookies from the beginning, just like roughly all the other web sites in the world. Nothing in the use of cookies has changed (they're used everywhere and by everyone), but new regulations set by the European Union, and requirements set by Google, require aprs.fi to display this warning.

Once you click the '✖' button in the corner of the warning, a cookie will be set, so that your selection is remembered, preventing the warning box from appearing again. It'd be annoying if the box appeared every time. If you have disabled cookies, the warning will appear every time, since the web site cannot know if you have dismissed the box before or not, since that information would be stored in a cookie.

More information:

• Google EU user consent policy
• Google EU consent policy FAQ
• Google helping publishers with cookie consent
• Privacy policy of aprs.fi

DKIM, SPF and assorted tricks to get through spam filters

Today I've set up DKIM (DomainKeys Identified Mail) on the aprs.fi servers and within the aprs.fi DNS zone. A week back I already set up the SPF (Sender Policy Framework) records in the DNS, and fixed the reverse DNS information for the IPv6 addresses used by aprs.fi to send out email.

Mike Mozart / Creative Commons / Via Flickr: jeepersmedia

In non-technical terms, this should help GMail and other services to figure out cases of others sending email (spam?) on behalf of aprs.fi, and correctly classify those as junk. It also might help GMail figure out that the registration confirmation and password reset emails sent out by aprs.fi are actually not spam.

It has been a rather persistent problem - GMail has consistently labeled the registration emails as spam, and people have been asking why they're not getting the emails. In all cases the mails have been found in the spam folder. We'll see if this helps!

Thank you to postfix and opendkim for making this a rather easy thing to get going.

Google Maps disabled on aprs.fi temporarily due to a TOS accident

I woke up today to find out that Google Maps are disabled on aprs.fi, and the site is slightly crippled.

Google had noticed that aprs.fi has integrated support for OpenStreetMap map tiles *and* Street View. I hadn't noticed that the combination of Street View on top of anything else than Google Maps is forbidden according to the Maps API Terms Of Service document. Or I had just forgotten about it when implementing OSM or Street View (there was probably a year or two of time between the two, and probably another year or two since I actually read the lengthy TOS).

Google had nicely sent me a few emails to warn about the unapproved combination, first one already on 5th of March. I had moved away from reading emails regularly in Gmail a long while back, but forgotten to arrange for these emails from Google APIs to go to my primary email address. Silly me. Since I didn't respond or do anything about the situation, for almost a full month, they disabled Maps API, which certainly got my attention.

Oh well. OSM support is disabled for now, and I notified Google that aprs.fi is again compliant with the terms. Should be back soonish.

I might put OSM support back later, and remove Street View instead, as OSM is probably more useful in practice at some areas (although admittedly less visual and "cool"). Or maybe make some sort of arrangement where Street View only works if you have Google Maps selected instead of OSM. Have to check with the Google folks if that's OK, there are a few variations we can try. The first thing is to get the main functionality back up, no matter which maps they are.

I'll post updates on Twitter (https://twitter.com/aprsfi) and Facebook (https://www.facebook.com/aprs.fi). Stay tuned.

My mistake entirely, although quite a human one. When did you last read the full text of the license agreement of your new application or mobile phone? :)

Device identification database updated, available for other apps

Most APRS devices and applications transmit an unique AX.25 destination callsign in all their packets, so that receiving stations can figure out which application or device is transmitting each packet. Bob Bruninga maintains a tocalls.txt index file, which lists all the assigned destination callsigns.

Those devices which use the Mic-E encoding to transmit position packets encode the latitude and a little bit of the longitude within the destination callsign, in which case something else has to be done for device identification. Mic-E device IDs are encoded around the comment text, with one character in the beginning of the comment text and zero to two characters in the end of the comment. The Mic-E type codes are indexed in mic-e-types.txt.

Now, when an application such as aprs.fi wishes to automatically decode the destination callsigns and type codes to readable application names, as seen on the aprs.fi station information page, the author of that application needs to collect all the device identifiers from those two files, and somehow convert them to application source code, or a configuration file that can be read by the application. The master files are written with human interpretation in mind, and it's rather hard to make an application automatically parse out the identifiers from them. It needs to be done manually, and whenever new devices or applications are published, all the applications wishing to detect the new ones need to get an update. All softwares authors need to get notified that there are some new devices, and then somehow add the devices in their respective configs. That's quite a lot of extra work that would be better spent writing some fancy new features instead.

OH7LZB-7, correctly identified as a Kenwood TH-D72,
at Mikkeli International yesterday afternoon.
Aircraft and training provided by MIK at Helsinki-Malmi.

For aprs.fi, I initially made a Perl module, Ham::APRS::DeviceID, and published it as open source, so that other software authors could use the index too, and skip the manual labour-intensive part of parsing the master text files. For some obscure reasons a number of programmers have chosen to use other programming languages than Perl, and the module was of limited usefulness for them.

To improve the situation, I converted the device index in YAML (Yet Another Markup Language), which is easy to read and edit by humans, and also easy to read and edit by computer programs. I also wrote a little converter program which parses the tocalls.yaml file and outputs the same data in JSON and XML formats, which are popular file formats for passing data between computer systems.

I then updated the original Perl module to read the YAML file, and removed the old database that was embedded in the code. DeviceID.pm 2.00 and later use tocalls.yaml. I also updated aprs.fi to use the new version of the Perl module, and tocalls.yaml. The update brought a number of new devices to aprs.fi, including the newer Yaesu radios.

Other programmers who wish to do device identification are welcome to download the YAML, JSON or XML files and use those. It should be straightforward to automatically update the device index during an application build, or even automatically update the index directly in the application.

New devices should still be first added to Bob's files, and only then to tocalls.yaml. If you have a new device which has already been added to Bob's index, please make a pull request or an issue ticket to update tocalls.yaml accordingly.