Back button should now work!

Ocicat kitten, 5 weeks, (c) Heikki Hannikainen

Last night I spent a couple hours trying to improve URL navigation on the aprs.fi real-time map. The back and forward buttons have behaved quite weirdly for some time, and that simply needed to be fixed. The upgrade went in just a few minutes ago.

With the help of the HTML5 history API I think I mostly got it right now. It is of course likely that I missed some corners, so keep the feedback coming - either in blog comments or posts on the discussion group.

Basically, the browser history now only gets a new entry when the user initiates a "major change" in the map status: a new callsign or a new address is searched. Those new history entries can be navigated using the web browser's back and forward buttons.

Minor state changes, such as changing the time range / tail length parameters, and any changes not initiated by the user, should only update the current browser history entry. After first looking up station A, then looking up station B, and then changing time range, clicking back will take you to station A. Clicking forward will then take you to station B - with the changed time range! Try it out, you'll see what I mean.

Naturally this won't work so nicely with steam-powered web browsers, or the oldest boat anchors out there.

Christmas is coming, and postcards need to be printed, so I was required to take some kitten photos with seasonal props yesterday.

Amateur Radio Questions and Answers

Amateur Radio Stack Exchange is a question and answer site for amateur radio enthusiasts. It's currently in public beta, and a lot of good questions already have great answers.

The Stack Exchange Q&A site format is very popular in programmer circles - take a look at Stack Overflow for example - good questions and answers get voted up, and the best answers are prominently displayed, unlike in traditional discussion groups and mailing list archives where the good bits are often buried in the middle of a lot of uninformed answers and chatter that is only slightly related to the original question.

If you've got an amateur radio related question, please post it there. If not, try answering one of the unanswered questions. It's actually a lot of fun!

The site is currently in a beta, and needs a little push (questions, answers, votes) to keep going.

Start with the instructions on the About page.

aprs.fi upgraded on 2013-10-20

Photo unrelated to upgrade! Some floppies we found at the
OH2K club station while cleaning and discarding old stuff.
Quite nostalgic stuff for me.

I just finished upgrading aprs.fi. It's been a while since the last full upgrade (a few small patches have been applied in the meanwhile). Here's a summary of the changes:

A fix for Internet Explorer 11. The real-time map view now loads and works on IE11, which has just become available to the general public.

When running on a mobile device (ipad, android tablets, etc), the callsign input form field no longer gets focus automatically during the map load process. It tends to pop up the on-screen keyboard, which is quite annoying. On non-mobile devices the automatic focus still happens, so that you can start typing in a callsign right after opening up the site.

Google Maps API code upgraded to version 3.13. I somehow suddenly get flashbacks from Donald Duck comics. Odd.

Some internal code refactoring was done in the API and authentication code. If all went well, no visible changes to anyone.

aprs.fi within iOS 7 Safari web browser

When opening aprs.fi using the iOS 7 Safari browser on an iPad Mini, the browser is quite consistently killed by the operating system due to an out-of-memory situation, especially if there are a lot of stations in your area to show. This looks pretty much like the browser crashed, but the device's console log displays the OOM errors quite nicely. The same happens when I try to use Chrome. It worked pretty fine on iOS 6 on the same device.

It seems to me that iOS 7 grabs more memory itself, leaving less memory available for the applications, and the devices with 512 MB memory (or less) don't have enough to load aprs.fi in the browser when a lot of stations are brought to view. iPad Mini and iPad 2 have 512 megabytes, the original iPad 1 has 256 MB, the 3rd- and 4th-generation iPads ("new iPad") have 1 GB (specifications).

Sep 22 19:53:51 Minipad MobileSafari[1407] : Received memory warning.
Sep 22 19:53:53 Minipad MobileSafari[1407] : Received memory warning.
Sep 22 19:53:54 Minipad com.apple.launchd[1] (UIKitApplication:com.apple.mobilesafari[0xe421][1407]) : (UIKitApplication:com.apple.mobilesafari[0xe421]) Exited: Killed: 9

The same probably applies to iPhones, but I didn't upgrade to 7 yet.

There's not much I can do about this, other than make it somehow load less stations and lines on the map initially.

Or release a native iOS application which doesn't process the map data in Javascript, and will be able to keep its memory use lower that way.

Presentation at Ham Radio 2013, Friedrichshafen

I've prepared a presentation for the Ham Radio 2013 event taking place this weekend in Friedrichshafen. The title of the presentation is "Providing authenticated amateur radio services on the Internet", and it'll be held at Conference Center East, room Paris, at 14:00. Same time and place as last year!

How can we provide Internet services restricted to amateur radio users with reasonable guarantee that non-hams do not gain access to the services, without an awful lot of manual work by the service provider and mailing license copies for every service? Current practices, alternatives, a proposal for better future implementation of distributed trust using X.509 certificates, and a demonstration of an implementation for a web service.

If you're an user of authenticated amateur radio web services such as the APRS-IS network, or Echolink, or Logbook of the World, this should be interesting. If you're developing a service like this, or would like to develop one, it should be especially interesting.

There's a catch, though. Due to a surprising event I won't be able to fly to Germany myself this weekend. Fortunately Erik Finskas, OH2LAK, has agreed to act as a proxy and present my material there! Not a bad deal, since he happens to be a seasoned professional in the right field, and has applied the presented technology both at work and in the linked UHF repeater network in Finland.

Join Amateur Radio on Stack Exchange

Stack Exchange is the latest internet gizmo at the crossroads of a forum, a wiki, a blog and a poll. The end result is a question and answer site which is much more qualitative and easier to search than any ordinary internet forum. Programmers and system managers may know it from the well-established Stack Overflow. In contrast, the amateur radio section is still at its infancy. It resides as a recreational topic in a staging area inauspiciously called “Area 51.”

Here is where things get serious and where your help is needed. Stack Exchange will not open a new Q&A site until they are absolutely sure that a critical mass of members will commit to actively participating. They are quite categorical about it and the vetting process is ruthless. “Area 51” is literally scattered with the mutilated remains of Q&A sites that were once to be. Yet, the amateur community at large cannot afford to miss out on this unique opportunity! This is why we need you to be part of the group of pioneers who started the Amateur Radio Stack Exchange site by following this link and commit!

Text by Serge Y. Stroobandt, ON4AA, CC BY 3.0

Updated statement on PRISM at aprs.fi

Last night's "statement" was generated using the PRISM involvement denial statement generator, and is not completely serious. Hopefully it'll serve as a little reminder of the privacy aspects of APRS. If you care about your privacy, you probably should not transmit your location to the public. With APRS, you have the privilege of switching your beacon on and off at any time, and it's sometimes a good idea to exercise that right. Some other tracking systems don't let you do that.

APRS data, like all other amateur radio communications, are public and unencrypted, and can be received, recorded and archived by anyone. With APRS, it's just easier to do so.

As for aprs.fi: there have been no requests from governments to aprs.fi at any point. They can just pull the data from the APRS-IS without asking if they happen to care, or use the aprs.fi web UI to look at whatever historic data there is – just like anyone else.

Statement on PRISM at aprs.fi

Dear aprs.fi users,

You may be aware of reports alleging that aprs.fi and several other APRS sites have joined a secret U.S. government program called PRISM to give the National Security Agency direct access to our servers. We would like to respond to the press reports, and give you the facts.

aprs.fi is not and has never been part of any program to give the US or any other government direct access to our servers. We have never received a blanket request or court order from any government agency asking for information or metadata in bulk, like the one Verizon reportedly received. We hadn't even heard of PRISM before yesterday.

When governments ask aprs.fi for data, we review each request carefully to make sure they always follow the correct processes and all applicable laws, and then only provide the information if is required by law. We will continue fighting aggressively to keep your information safe and secure. Any suggestion that aprs.fi is disclosing information about our users’ APRS activity on such a scale is completely false.

We strongly encourage all governments to be much more transparent about all programs aimed at keeping the public safe. It's the only way to protect everyone's civil liberties and create the safe and free society we all want over the long term. We here at aprs.fi understand that the U.S. and other governments need to take action to protect their citizens’ safety—including sometimes by using surveillance. But the level of secrecy around the current legal procedures undermines the freedoms we all cherish.

Embedded maps disabled temporarily

While investigating the problem with the Google Maps API I've disabled the embedded maps feature temporarily. Sorry for the trouble.

It now returns a blank page, so you'll see empty space where the map should be rendered. No errors should be shown to your web site visitors.

The map fails to load for some site visitors, giving an error about Google Maps API being disabled for the site. The error message does not seem accurate, since aprs.fi is nowhere near its usage limits, and an immediate reload of the page typically loads just fine. The error is sporadic, happens to some users all around the world, but not everyone (I haven't seen it), on all browsers (IE, Firefox, iPad, etc). The issue is being discussed on the aprs.fi discussion group.