How to authenticate licensed hams?

It would be interesting to provide some methods for two-way communication in the aprs.fi web user interface. Say, APRS messaging from a sort of a web chat, as a simple and obvious example. Or marking their position on the web map and having it seen on APRS-IS. Having tracker devices with an open-source firmware (like OpenTracker and the Finnish HaMDR) opens up more interesting solutions, like remote control, or actively requesting information from a vehicle.

But how on earth could I figure out if an user of the web site is a licensed amateur radio operator, so that he can be allowed to transmit? Automatically, with somewhat strong authentication against an existing database or set of databases, without a need for validating each user by hand? To be useful, it would need to work for more than a few countries (Finland, USA to start with).

It's quite unlikely that the issuers of the licenses (like the FCC in the USA, Ficora in Finland) would bother to create Internet authentication services for their license databases. But the amateur leagues (at least ARRL in the USA, and SRAL in Finland) are already giving out accounts to their web sites ("for members only" features), and I suppose they also know whether each member is licensed or not.

What if the leagues would provide an authentication service using the OpenID protocol? An user would first type in their ARRL or SRAL email address (oh7foo@sral.fi, or n1example@arrl.org), then provide their sral.fi or arrl.org password to SRAL's or ARRL's site, and the authentication result, together with licensing status, would be passed back to aprs.fi (or another "licensed hams only" site).

This would require for the users to be members of one of the organizations providing OpenID authentication. But maybe some individual or organization could set up a trusted OpenID-enabled amateur database, charging each user $2 for the work of validating their license status.

Please, post a comment if you have any ideas for automatically validating the license status of a web site user.

Ham::APRS::FAP 1.12 released

On monday evening I uploaded the new version of our APRS parser on the Comprehensive Perl Archive Network.

Version 1.12 includes a parser for the !DAO! extension, which can be used in uncompressed and mic-e APRS packets to report the datum and an additional digit of position resolution. It also reports the position resolution (in meters) for parsed position packets, depending on the type of the packet (compressed, mic-e, uncompressed), the presence of DAO and the amount of position ambiguity. These improvements were implemented by Tapio, OH2KKU.

I felt an urge to do some slight improvements on it myself before releasing it, and couldn't come with anything that would be both quick to implement and actually useful, so I just added some tests, cleaned up the API and packaging slightly, fixed POD documentation style, upgraded MakeMaker, and added a little example script, just to make CPANTS happier and increase the Kwalitee rating a bit. :)

!DAO! support for greater precision

Tapio Sokura, OH2KKU, implemented the APRS precision and datum option (DAO) in the Ham::APRS::FAP parser last night. Looking at the IRC channel log, he started working on it at around 01:40 AM local time, and finished at 04:33 AM.

A few minutes ago I installed the new parser code on aprs.fi, so those of you transmitting uncompressed or mic-e packets with the DAO extension should now see the improved precision.

Compressed format packets have enough precision (around 1 foot) already, so DAO is not useful with it. aprs.fi properly decodes compressed packets (including speed and course), and compressed packets are the smallest ones (they help conserve valuable channel time on 144.39 and 144.800 MHz), so I would recommend using the compressed format instead of uncompressed or mic-e with DAO.

The only supported datum is still WGS84, no conversion from other datums specified by DAO is done.

Imperial and nautical units for Google Earth KML APRS view

The unit configuration selected in Options now applies to the Google Earth Network Link, which is produced when you click on the Google Earth KML link on aprs.fi. Fahrenheit temperatures are supported, too. US users should get Imperial units and Fahrenheit temperatures by default, UK users should get Imperial units and Celsius temperatures.

If you have installed the aprs.fi Google Earth APRS link before, and wish to change your units configuration, please do the following:

1. Delete your existing link from Google Earth by right-clicking the top-level "APRS:" link and selecting Delete (not Delete Contents)
2. Select your units configuration in the aprs.fi Options window
3. Open a new KML link using the Google Earth KML link on aprs.fi

This way the new units configuration will be copied over to the Google Earth KML link. When you change your configuration again in the Options, you'll need to delete the existing link in Google Earth and open up a new one from aprs.fi.

Some UTF-8 character encoding issues were also fixed in the KML interface.

Little enhancements

Joe, K7JD has been pointing out (for quite a while now) that there's more accuracy in the speed and altitude formats used on aprs.fi than would be appropriate. I've removed the decimal digit from the speed and altitude formatting functions now, since there isn't that much accuracy in the source data anyway.

Max, KG4PID pointed out that the info balloons on the map show really old weather data for stations which have sent even just a couple of WX packets sometime in the last summer. I made a small change to make it only show WX data updated within the past hour.

I've also compressed the big javascript files, so that they will download faster, especially on mobile devices. This process can also be called optimizing, since they will run slightly faster on many browsers, and obfuscating, since they're now much harder to read. Sorry about that.

Firefox 3 beta not working with aprs.fi

Zach Sadecki was the first to let me know that the Firefox 3 beta has some trouble with aprs.fi. I did some testing, and sure enough, it fails sooner or later with some JavaScript errors being printed in the Error Console. It has something to do with the decoding of the XML in the AJAX XMLHttpRequest responses.

I verified the site still works with Firefox 1, Firefox 2, MSIE 6 and 7, Konqueror and Safari, and went to report a bug in the bug tracking system of the Mozilla project, only to find that Zach had already issued Bug 425586 – javascript doesn't run that works fine on firefox 2.0. So, after a bit more testing, I added a comment there. This seems like a FF3 bug to me, one that is a bit hard to work around in aprs.fi code.

Zack also pointed out that the Gecko-based Epiphany browser suffers from the same problem.

It might be useful if you'd happen to find another ajax-based site which suffers from exactly the same problem. Please, drop a comment if you do.

Update: I've installed a workaround for this problem, and it seems to work. I'm re-parsing the AJAX XML using the GXml API.

APRS bulletin group browsing

Tonight I added a small feature to the APRS bulletin board. It can now show bulletins belonging to a specific group, for example MAREA, EI or EVENT.

Directing bulletins to specific interest groups could make the bulletin board scale up a little bit, currently it is filled by just the same old web site and BBS/DX cluster advertisements.

A few days ago I did some programming on the hamdr APRS tracker firmware. It was fun to program C on a 16-bit embedded platform for a change. Tuned it's telemetry transmission a little bit, and added TLL NMEA waypoint sentence support.