Class-based links, transmit rate advisor, SSL and other features

I'm having a few days off from work, so I've just installed a rather big upgrade to aprs.fi. There will be bugs and complaints from these, but I think I'll have time to look into them during the following days. So, what's new?

Class-based links and support for targets having the same name

aprs.fi has for a long time had serious problems when multiple tracking targets share the same name. There are an awful lot of AIS vessels having the same name, and those always had to be looked up by their MMSI. APRS stations (and objects and item names) could also overlap with the AIS vessels. I've now implemented proper searching functions to look up these stations and select the interesting ones from a list. To make it possible to link to these stations I've had to add a target class identifier in the links.

• a stands for APRS
• i stands for AIS

Let's use Aurora as an example.

• http://aprs.fi/Aurora will search for all stations having the name Aurora, and show a list. Since the real-time map can show multiple targets at the same time, you can check many checkboxes and get a view tracking those stations.
• http://aprs.fi/a/Aurora jumps directly to the APRS station.
• http://aprs.fi/i/306784000 is a link to an AIS ship having the name Aurora.

If the station's name is unique, old links with no class identifier will continue to work as before: http://aprs.fi/OH7RDA

SSL for sensitive pages

The sign-up, password recovery, login and account pages are now protected by SSL/TLS (2048-bit RSA + up to 256-bit AES). This keeps your password safe from eavesdropping when you're using this site over an untrusted network. I believe the password safety to be on a good level now, since they're also stored in the database using an industry standard safe method (PBKDF2).

I used a free SSL certificate provider, and some more marginal or old browsers might complain about the certificate not being trusted. Sorry about that, please disregard the warning or use a browser which trusts StartSSL's certs.

Packet transmit rate advisor

This has been suggested by several users. The info page now calculates a median interval between packets transmitted. If the median falls below 25 seconds, the following advice is shown:

This station is transmitting packets at a high rate, which can cause congestion in the APRS network.

If the median falls below 13 seconds, the following advice is shown:

This station is transmitting packets at a very high rate, which causes serious congestion in the APRS network. This could be considered an abuse of the network resources.

Up to last 50 packets from a station are considered, but the backwards-going lookup stops at the first 1-hour gap between packets, the intention being to look at the last or current trip of a vehicle. The median is only calculated if there are at least 8 packets in the last trip. Because a median is used, this shouldn't trigger too easily from bursts generated by Smart Beaconing.

There are some ideas how to make this more meaningful. I've been thinking of an algorithm to calculate some sort of fuzzy "network loading" value by multiplying the packet rate by the amount of digipeater hops requested in the packets and using the result to trigger the nagging. This would allow a higher rate to be used with no digipeater path, but trigger more quickly when a 3-hop path is used. It would also handle proportional pathing by looking at the path of each packet separately.

I'm sure some people will be annoyed a bit by this and some rock-throwing might occur. Please be gentle and pick some smaller rocks first. The algorithm is new and it'll be revised. The intention is good – to provide advice in sensible tracker configuration.

Amount of persons on a ship shown when available

The most recent SVN versions of gnuais can receive and upload this information.

Some smaller fixes

• Cursor focus is moved to callsign input field when the real-time map is loaded
• Fixed lat/lng in XML export
• Better string translation moderation tool
• Google maps API is no longer loaded in translation tool

O2 UK mobile users - your operator is breaking this site for you.

In a comment to a previous blog post on iPad/iPhone, Steve notified us that aprs.fi often does not work on the iPhone when used on the O2 UK 3G mobile carrier. It works fine on the same iPhone when he switches from 3G to a Wi-Fi connection.

Well, it turns out that O2 in the UK is running a transparent proxy server which compresses and modifies the web pages in many ways. Their intention is to make the pages smaller so that they would use less of their valuable radio bandwidth, but they ending up breaking the web experience really badly for their users. Here's what they do (information from Stuart Roebuck's blog and O2 user forums):

They re-compress images so that they look ugly on a device which has a bigger screen (such as the iPad, or a laptop connected to the iPhone).

Their proxy downloads CSS and JavaScript files and inlines them inside the HTML page before returning the HTML to the customer's phone. Normally the CSS and Javascript would be downloaded to the phone once when the first page from aprs.fi is downloaded, and after that they would be cached in the phone's memory so that they would not be downloaded again with the following pages. Now they're downloaded again and again with every page.

The CSS and JS code is actually much larger than most of the HTML pages downloaded from this site!

The inlining actually increases bandwidth usage (thus increasing your mobile data charges), slows down this web site, and often makes it unusable, because it breaks the HTML encoding and quoting rules for characters like < >. Steve's iPhone usually refuses to render the pages from aprs.fi due to this.

The inlining also removes comments, which might contain things like copyright clauses and software licenses. I suppose it's illegal to remove those.

For more information, please see Stuart's fine blog posts regarding the matter. I suppose the best options right now are (1) complaining to O2 about this, and (2) switching to another carrier, such as Three.

Translating fixed

The aprs.fi translation tool was broken when the Google Maps API v3 integration was installed on July 5th. I've fixed it now to not use some API functions which were used from the maps API, and translation work can continue. There are some new strings which have been added lately for Street View integration, tooltips, data exporting and other new features, so most languages need some updating.

Again, I wish to thank everyone who has submitted translations – they are really very useful for a lot of the users around the world!

Unfortunately I did a small mistake during the installation of this bug fix, and the real-time map would not load for several minutes right after the initial installation tonight. Sorry about that.

Google fixed the Opera issues

I wrote about the Opera issues recently.

It turns out that Google has fixed polylines with opera yesterday, and track lines are drawn just fine now. Heard maps, phg circles, rulers and locator lookups seem to work, too. Opera is still not officially supported, so further issues may appear, but at least a bunch of very visible bugs were fixed.

Problem and Solution, part 2

The Solution to the Problem has finally been installed in production. It took a while since I wanted to benchmark different configurations well before doing the actual installations. Enough space for backups for some time! I'm now able to store database dumps and transaction logs for much longer than a week, and there's also plenty of room for database growth.


The new disks are faster then the old ones, and they're a bit cooler, too:


4 1TB SATA disks set up as a RAID10 array, giving 1862.62 true gigabytes of space.

I've also ordered more of the same disks for the live aprs.fi servers.

Heard and Gated maps with multiple stations

The 'heard' and 'gated' maps got an upgrade yesterday. They can now plot the combined coverage area of multiple stations. For example:

• http://aprs.fi/heard/OH2TI,OH2NJR
• http://aprs.fi/gated/OH2RCH,OH3RBR

Zoom out to see the whole coverage. The user guide has been updated to reflect the changes.

Video: Using aprs.fi to trace packet errors

radionerd1 has uploaded a video on Youtube, instructing how to trace down a faulty digipeater.

Opera and Google Maps API v3

As you have probably noticed, the Street View feature has made it to the main aprs.fi site, and the beta site has been shut down (as it didn't have anything special any more). aprs.fi is now running with Google Maps API version 3 (up from version 2).

Besides an all-HTML Street View (which works on mobile browsers without Flash, like the iPhone), the version 3 API has other improvements, and all of the improvements made by Google in the future will go to version 3, not version 2. Stay tuned for more! With the new version the map loads faster on many platforms (especially mobile browsers). There are still some bugs in v3, and some compatibility problems with specific browsers, but the bigger ones should be fixed already.

One currently visible bug is that polygons are not rendering in the Opera browser. What this means for aprs.fi is that things like the track lines, APRS packet path lines and PHG circles do not show up. Symbol graphics are shown, and I suppose that everything else is working with Opera.

This problem could be fixed by either the guys at Opera (since it works in the other browsers), or the guys at Google (since they have managed to make a workaround for Opera in API v2). Now, it seems like Google isn't going to do it, so the Opera fans should hope that Opera will do the fixes instead. Or maybe they can use some other browser in the mean time. Here's a quote from a Google employee in the bug ticket for the polygons on opera:

Opera is not currently a supported browser for the Maps API. Supporting a browser is not just a policy decision. To support a browser we must add it to our automated test suite, and then ensure it passes all tests now and ongoing. So there is an overhead associated with supporting additional browsers. We have to balance that overhead against the volume of requests we see from that browser and decide if the adoption amongst users merits the cost.

We can not support Opera Mini, because it does not have a sufficient level of JavaScript support. This leaves Opera for Desktop and Opera Mobile. Together these two browsers account for less than 1% of the requests we receive for the Maps API v3. Perhaps the strongest argument for supporting Opera is that it would open up the API to a number of new platforms (eg. Symbian, WinMo). However when we exclude requests from platforms for which we already have a supported browser, that number drops to 0.05%. So right now supporting Opera is simply not a good investment of our engineering time compared to working on features that will benefit 100% of the developer and user base.

Consequently I am going to collapse all bugs relating to Opera into this one, and reclassify this as a Feature Request to support Opera. We will continue to keep an eye on this issue and on the adoption numbers, and if a new strong argument arises, or adoption increases, we will revisit it.

The statistics for aprs.fi show quite a bit more Opera users than 1%, but it's still not a lot. I could either throw out Street View and go back to v2 for some time, or stay with gmaps API v3 and ask the Opera users to use some other browser for now. I think I'll go for the latter option. I sure hope that one of the players involved does the required fixes soon.

Street view & iPad/iPhone beta test

I've been doing a rather big upgrade on the real-time map code. I have it using version 3 of the Google Maps Javascript API, which better supports the Apple iPad, and there are fixes for the iPhone, too.

Another big thing is that I've added Street View support. The Track in Street View link in the info balloon of a moving vehicle will give you a first-person view of how things look from the driver's point. The camera is pointed to the direction where the vehicle is moving, if it's course is available.

If the station is not transmitting a course, the camera will point from the panorama picture's center coordinates (where Google's camera was when the panorama was taken) to the exact coordinates transmitted by the stations. This implies that clicking on a house symbol of someone's home station will often open up a photo of that house (with antennas on top).

These features are now being tested on the beta.aprs.fi site. There are probably some bugs left – please let me know if you find any! The intention is to fix them before the new (substantially different) code is installed on the production aprs.fi servers.

More details can be found in the user guide.

aprs.fi user guide

To follow up on my previous posting, I've started working on an user guide for aprs.fi. It's a Wiki page, so if you feel you're able to write somewhat good English (or even better, you can correct my grammar), you're welcome to contribute directly.