APRS-IS packet loss on 2011-11-21

As seen in the statistic graphs, aprs.fi was only receiving about 60% of the APRS packets from the APRS-IS between 2011-11-20 23:40:40 UTC and 2011-11-21 08:25:57 UTC. During this time it was connected to a core server which apparently is not getting a full APRS-IS packet feed for some reason. As  a visible result the packets of about 40% of APRS stations did not get to aprs.fi.

The core server operator has been notified and aprs.fi is connected to another server again. Sorry for the trouble.

Using aprs.fi for SAR, ARES or other public service work? Let me know!

I know some of you use aprs.fi while doing volunteer search-and-rescue operations, ARES or other public service work.

If you wish to keep doing so as before, with the convenience of Google Maps, I need you to tell me and everyone else about your use. In writing. Please.

Put up a blog post or write about it on your volunteer organisation's web page. Send me an email pointing to the document. Write about what you are doing, where, when, and how aprs.fi is useful in what you do. Practical examples of real events are probably most useful.

This is important, since Google is going to start charging for the usage of their Maps API, which until now has been free for sites which are open and free to use (like aprs.fi). 

The charging is based on the amount of map loads. aprs.fi currently opens up the real-time map almost 42,000 times per day (when nothing special  happens). According to the new Google Maps terms, up to 25,000 map loads  per day is free, the rest will cost $4 per 1000 map loads. That amounts up to $68 per day, $2040 per month for me. No, I don't make that much from the advertisements. And there are some other costs involved in running such a site too (computer hardware, hosting, domain names, programming beer, to name a few).

"We will then start billing excess usage to your credit card when we begin enforcing the usage limits in early 2012." (the blog post)

The only real options seem to switching away from Google Maps to something else, or getting aprs.fi to qualify as being "in the public interest":

"Non-profits and applications deemed in the public interest (as determined by Google at its discretion) are not subject to these usage limits. For example, a disaster relief map is not subject to the usage limits even if it has been developed and/or is hosted by a commercial entity." (FAQ)

A lot of you will probably suggest switching to OSM. This is one option, but it has a few drawbacks:

• Address/place search isn't as good
• No  Street View, worse Satellite view, no Terrain view
• Less coverage in the countryside
• Takes a lot of work from me to switch from Google's API to OSM's API (aprs.fi uses the Google Maps API for a lot of things, like drawing lines & circles and placing car symbols on the map and presenting menus and pop-up balloons)
• OSM's map tile servers can't take the load - Lynn just got a note from OSM folks that APRSISCE/32 should make "other arrangements" and not download the maps directly from OSM. I would expect aprs.fi to generate even more load, and I'd probably have to run my own map server (which would take a significant amount of work and money, and it'd be much slower than Google's map servers).

This, and other options, are discussed on the aprs.fi discussion group.

So, I'll have to try to get in the "public interest" category. It might help if you could document your real usage in "disaster relief" and other public service work in writing. You can find my email address from the blogger profile (on the right side, scroll down to "about me", view my complete profile, contact, email).

Thank you!

Embedded map backlinks, API upgrades, speedups and new bat-toys

The embedded map displays a link back to aprs.fi in the low right corner again, as it used to do until July 2010, when aprs.fi switched to Google Maps API v3 and got Street View support. It should be much less annoying than the old ugly box, though. The new link is smaller and slightly transparent (on modern browsers).

I also upgraded to Google Maps API from version 3.4 to version 3.6, which brought in several enhancements and bug fixes. The API has it's own change log. Noticeable changes include fade transitions for map tiles when loading and changing the map type, Street View pegman previews, some speedups, and several bug fixes for iOS and Android.

I have also recently made some database access optimisations making many map displays and some raw packet searches load much faster.

Since 28th of August most, if not all, APRS symbols now have hover-on tooltips. Keep the mouse cursor on top of a station symbol and a description text should magically appear!

And, as you can see from the attached photo, I have some new toys for 70 cm. Built in GPS, text messaging, trunking support, rugged construction, submersible, digital and analog voice, and a few other nice features. And surprisingly inexpensive on ebay, when compared to new amateur HTs with APRS.

Video: Using aprs.fi history lookups

This 1-minute instructional video shows how to do track history lookups on aprs.fi. I made it quickly one morning as an answer to a question from an user on APRSSIG.

Small fixes on Monday morning

On Saturday and Sunday I did a little coding, and installed the new version before leaving for work this morning.

When an user tries to save a filter list twice with the same name, and error message is now displayed. It turns out that a lot of users press the "Save as new list" button after making any changes to the existing list, and end up with 20 lists (or more!). That button is only for creating a new list. Any changes to existing lists are saved immediately without pressing any additional buttons.

The Preferences view got a new hint text pointing users towards the new Filter tool button. A lot of users are complaining about the "missing filters".

When an user account is deleted, data related to that account is now more thoroughly deleted. That includes web stations, alerts, favourites, and so on.

Alert configuration changes should now actually do all the necessary database changes to enable new alarms and disable old ones.

The real-time map should now more reliably draw a symbol on the last point of a track. An old bug sometimes left the last point without a symbol.

When a client computer wakes up in the morning from a good night's sleep mode, the data reload should now be a quick one, instead of a very slow one.

Session cookie processing was also improved, and memcached was upgraded.

Again, it doesn't make sense to take a photo of software, and a blog needs to have some photos, so kittens it is again. This is FIN*Kukkatarhan Bellium, a chocolate-spotted Ocicat, posing in Mikkeli a few weeks back.

Ham::APRS::FAP version 1.18

A new version of our APRS packet parser has recently been released on CPAN. It contains new features and bugfixes made by both myself and Tapio, OH2KKU. Here's a list of changes:

• Added Ham::APRS::IS module - an APRS-IS client library
• Fixed position resolution calculation for whole degree cases, and added tests
• Implemented a 'raw_timestamp' option to return undecoded timestamps in all but status packets
• Added tests for timestamp and status message parsing
• Added support for new base91 comment telemetry

User preferences saved with user account

I did a quick upgrade last night. A few bugs were found immediately after the upgrade and needed to be fixed but no serious harm was done.

The upgrade includes revamped session and preferences storage. The user-visible change is that user preferences are now stored in the server backend and attached to your user account if you're logging in when saving the preferences. They will be used on other computers, browsers and mobile devices as long as you're logged in with the same account.

The preferences can still be saved if you're not logged in, in which case they're attached to a browser cookie.

A less visible change is that the settings and session cookies set in the browser are now much shorter - just random keys, instead of containing the whole settings or session data. This makes the HTTP requests smaller, which improves network performance marginally. On a slow mobile connection it might actually make a difference.

I don't have a related photo to attach, so kittens it is again! Buxus and Brassia, aged 6 weeks.