iPad location sharing, bugfixes and Android support

I've installed a couple of fixes in the web locations updating code now. It failed to work for about 6 unlucky users due to a little bug which didn't take database replication delays into account. But that's sorted now.

I've also put the 'share location' button on the non-mobile site, so that it can be used on the iPad and other larger devices with GPS. We'll see what effect that has!

The good news is that it seems to work on several Android phones:

• Google Nexus One
• HTC Dream
• HTC Espresso
• Samsung Galaxy S
• Motorola Droid
• LG Ally

It'll probably work on the rest of the new ones with GPS, too.
The new tool buttons are now documented in the manual.

Web location uploads, better iPhone support, and favourite stations

I've just installed a rather large upgrade on the production aprs.fi servers. As usual, some things might break, in which case you'll get to keep both pieces, but it should be worth it.

The system now supports uploading positions directly to aprs.fi using a web browser which supports the W3C Geolocation API. In practice this means that you can update your location using a mobile phone which has a GPS and a modern web browser. No native application or purchase is required. I have only tested this with the iPhone (OS 3.0 and newer), but there is a good chance that Android phones will work, too. To try this out, create an user account on aprs.fi, log in from the phone, and click on the transmitting tower button to upload your position.

You can also click on the crosshair button to center the map on your current GPS coordinates. Naturally, your web browser will ask you whether your position can be revealed to aprs.fi before either of these functions are enabled.

The positions are not transmitted to or via the APRS-IS, so it is OK for users without amateur radio licenses to upload their positions, too. The stations are identified as web stations on aprs.fi, for example: oh7lzb föni (my iPhone). Web stations names are not restricted by AX.25 / APRS limitations, and can contain spaces and international characters.

The names of the web stations live in a separate namespace from APRS and AIS stations. There can be a 'N0CALL' phone as well as a 'N0CALL' APRS station, and a 'N0CALL' AIS ship. When names overlap, the web site will let you pick the right station from a list. Multiple web stations may also share the same name, which should help avoid collisions.

The mobile version of the map has been improved to better support the iPhone. With some luck, these improvements should also help on Android and other new powerful mobile devices, but I haven't tested it on one yet. I really haven't used anything iPhone-specific which would intentionally break on other devices (I have tested the mobile version of the site on Firefox to validate this), but only testing will tell. Feedback is welcome.

I've also added a favourite stations list. The 'star' button to show the bookmark list is visible, but the editing functionality has not been published yet. Stay tuned for more!

aprs.fi in Chinese

BA5AG has done a lot of work to translate aprs.fi in simplified Chinese (简体字). The simplified characters are currently used in Mainland China, Singapore and Malaysia, and this translation makes aprs.fi and APRS in general accessible to a huge new audience (besides adding one more way to confuse myself while using my own software). A big thank you to Weng Kai for his volunteer effort!

Device Identification, and a rate advisor fix

I've just installed support for APRS device identification. The info page now makes an attempt to show the type of tracker or software being used by the station. The identification data collection started just a few minutes ago, so most stations are still not identified, but they're getting identified as packets are transmitted. The identification happens when position packets are received, so you'll need to send some packets to update the identification. For example, here's an VX-8G:

http://aprs.fi/info/a/KE6SLS-7

As a nice side effect the comment fields of mic-e stations are getting cleaned up from the device identification characters.

I've also updated the packet rate advisor to use an arithmetic mean of the packet transmit interval instead of a median. Some stations which sent two packets in a row (with 2 seconds between the 2 packets) every 30 minutes (giving an average interval of 15 minutes) sometimes quite correctly got a 2-second median interval, and got a "very high rate" warning.

The APRS packet parser was upgraded to Ham::APRS::FAP version 1.16 (to support the device identification).

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.