AIS from Pietarsaari, and tracking links fixed on MSIE

OH6AG kindly started to provide AIS reception from Pietarsaari. Their receiver hears traffic from the harbors of Pietarsaari and Kokkola, and most of ships from Kvarken (Merenkurkku).

I also did a small but important fix on the map javascript code - the "start tracking" and "stop tracking" links now also work on Internet Explorer 6. For some reason the quite correct way of assigning an onclick event to a span did not work on that single browser - it did work on every other browser (including IE7). And it only failed to work in the innerHTML dynamically generated by the javascript for the target info pop-up balloons - it works just fine in, for example, the Options link on the right side of the map (which is dynamically generated on the server). So I put in a <a href="javascript:function()"> tag, which seems to work on at least Firefox, IE6/7 and Safari. Please let me know if this change broke some other browser.

New AIS sites, and lack of other news

New AIS receiving sites have been added in Thunder Bay, Lake Superior, Ontario, Canada (thanks to Robert, VA3ROM) and Felixstow, Suffolk coast, UK (thanks go to Ian, G4ZJH).

There's not much else to report on. I've written a lot of code for the new localisation tool, and it should be ready for prime time pretty soon.

APRS parsing logic changes

Today I did two changes which were recently requested by aprs.fi users.

The first one was actually done last weekend, but it needed some more testing and cleaning up, so I only deployed it on the production server today. The MIC-E parser now accepts some forms of corrupted packets. There are a number of broken igates and digipeaters out there, which corrupt MIC-E packets which often contain non-printable, non-ASCII characters in the 0x1C-0x1F range. At least aprsd has this bug (there is a patch in it's bug tracking system which fixes it) - it replaces the characters with spaces (0x20), and it seems that some igates or APRS-IS servers then replace the spaces with a single space, so that the MIC-E data is really broken.

I've added a kludge which manages to parse the location from some of these corrupted packets. It's ugly, but it usually works. Replacing corrupted or missing data with something I've guessed is not a good idea, but this will have to do for a while.

The second one was pointed out only last night by Chris, K6DBG. The speed of a target is now calculated from the positions of the current packet and the previously transmitted packet, instead of the previously accepted and stored packet. This is significant, because packets indicating that the target is moving faster than 500 km/h are discarded. These are usually caused by corrupted packets, or bad GPS data. Some APRS trackers transmit their position even if the GPS clearly indicates that it has no valid fix. Sometimes the GPS suddenly gives out a single invalid point which is hundreds or thousands of kilometers away.

If the invalid position was the first one transmitted by the station, it was accepted and stored to the database, and it could take days (to move to the true position at 500 km/h) before a new correct position packet was accepted. Now, the second correct position packet is already accepted and stored.

Weather graphs are back

I managed to extract all data from the corrupted database, except for the weather history data from a single weather station (MMUN in Mexico), so I didn't need to use old backups. The weather history is currently being loaded in the running database. I started the load just after midnight (after getting home from the Kent concert), it's now 2 PM and 74970000 of 106248685 rows have been loaded already, so the load should be completed this evening. That's right, there are currently 106 million weather reports stored from 8728 weather stations.

Then database load is a bit slow, since I made the loading script sleep most of the time - it loads the reports of a single weather station, and then sleeps three times the time it took to perform the previous load. This prevents it from slowing down the database too much, and interfering the normal operation of the aprs.fi site. Once it's finished, the restore process is completed.

aprs.fi is running again

I've now finished loading the backup database dumps, recovering all data before the crash last night, except for the weather history. It seems I'll be able to restore almost all of the weather data too (all of 6 months, except for a small minority of weather stations), but it'll have to wait until tomorrow. The recovery took all of today, since there simply is a lot of data, and I didn't have a hot replica of the database - the recovery had to be done using text dumps of the database. The operations took hours each, so I had good time to go out for a walk, watch a movie, and take part in a local HF contest while waiting for each step to finish. :)

I'll give replication a higher priority, this wasn't much fun as such.

aprs.fi down due to storage problems

Last night the EMC storage system (a half-rack full of hard disks, connected to the database server with Fibre Channel) where the aprs.fi database is stored, has returned some corrupted data, and the ZFS filesystem has detected checksum errors. As a result, the database is now down, and I'm restoring a backup copy. This takes some time, as the database is rather large. The service should be back up later today.

This sucks. Seems I really need to set up online data replication to another database machine. As long as the database is down, no APRS-IS data is stored.

Sorry for the trouble!