Ruler and reverse geocoding

While I'm up to speed, here are a few more late Christmas presents!

There's a new ruler tool, which is enabled using the compass icon, which can now be found just below the PHG circle icon. The ruler calculates great circle distance and direction between two points. Multiple rulers can be added by clicking on the compass icon again. Clicking on a ruler endpoint marker will reveal the coordinates and address of the marker position.

Furthermore, after clicking on any target on the map, an address will be shown, if possible. The address is obtained using Google's reverse geocoding service. The service may or may not be available in your area, and the data is received with a small delay after the info balloon is first opened.

Improved panning speed

I've just added javascript code to delete path points which are out of the current view. This reduces browser memory leakage and speeds things up considerably when browsing around the real-time APRS map. You'll notice this when panning away from and area, and then back - it'll take a couple of seconds to reload the map points from the server.

PHG antenna direction plotting

Last night I figured out the math to plot nice cardioid patterns, and this morning I finally got the rotation right, so now the PHG plotting shows the directivity parameter, too. It's been requested by quite a few users since I got the circles going.

The first image shows a PHG plot with an omni pattern (no directivity), and the second image shows a PHG plot with a directional antenna pointing at 135° (southeast). Please bear in mind that these plots describe very rough approximations and best guesses about the station's service range.



You can generate a PHGR comment extension for your digipeater or igate using the PHG calculator. Please monitor your station's receiver performance and adjust the PHG settings to match the observed range.

iPhone and iPod Touch fixes

Google has recently fixed a couple of bugs in the Google Maps API code, and both map controls and events have suddenly started working using the iPhone web browser. I've put them back in now, and the real-time APRS map is suddenly much more functional. Thanks for the little Christmas present, Google!

Look for me on HF digital modes during the Christmas holidays, I'm trying to be active from a few countryside locations.

gnuais 0.1.0 released

gnuais 0.1.0 can now be downloaded from SourceForge. It's an AIS decoding program for Linux, licensed under the GPL. Attach it to the 9600-bit/s data capable discriminator output of a VHF FM receiver, tune the rx on the marine VHF channel 87B (161.975 MHz) or 88B (162.025 MHz), and you'll be able to receive position data from nearby vessels.

Version 0.1.0 has an improved DSP decoder (thanks to Tomi Manninen, OH2BNS) and it can also upload AIS data to aprs.fi using the new JSON AIS protocol. If you wish to share your AIS data with aprs.fi, please drop me an email - the address is on the Profile page of this blog.

This is still an alpha quality release, so there are some caveats - the local GUI isn't working, and SoundChannels should be set to both (other settings will probably not work). The installation instructions are not very good either. If you've compiled software on Linux before, set up an igate, and played with soundmodem or gmfsk, installing should be pretty easy. It's an open-source project, so contributions are welcome!

AIS data exchange with MarineTraffic

We've recently started mutually exchanging AIS data with MarineTraffic.com. aprs.fi gets AIS data from MarineTraffic, and MarineTraffic gets what we have. This improves the coverage of both services significantly, as there wasn't much overlap before.

The peering is still being tested and the protocol improved, so it might be a bit flaky for a while, but generally it seems to work.

We're not converting AIS data to APRS format, and it is not my intention to do so - too much valuable information would be lost in the conversion process, and the APRS-IS network simply is not there for this purpose.

We've specified a new JSON based protocol which is also useful for feeding AIS data from receiving stations to these services. There is already a working Perl implementation for converting an NMEA AIS stream to the JSON AIS protocol for uplinking to aprs.fi, it's currently being tested on a couple of receiving sites. I'm hoping the author of the client will release it in the near future.

gnuais - AIS decoding on Linux

Lately I've been working on the gnuais source code, improving it so that it could be used to decode AIS and feed aprs.fi using Linux. My changes are in the SVN trunk (not in any released version yet). It's generally working, I just haven't done the actual "feed aprs.fi" part yet. But it's getting closer. The decoder isn't as good as in aismon/shipplotter - if you have DSP coding experience, your help is welcome on this project!

I've also modified some Televa 703-LYVV VHF FM receivers from the cold war era to be used as AIS receivers. "Brand new" (but a bit over 30 years old - like myself) commercial NBFM receivers in their original factory boxes, built to be installed at bomb shelters and such, but (luckily) never needed. Going to install a couple of them here in Helsinki, with directional antennas pointing southeast and southwest on the Gulf of Finland. We installed the antennas and cables during the last couple weeks, they're just waiting for the gnuais feeding code.

aprs.fi presentation video

In June I gave a presentation on aprs.fi at the 30th Nordic VHF/UHF/SHF-meeting in Sappee, Finland. You can now view the presentation video on the Internet. The slides are also available in PDF format. I'm not very proud of it, with a little practice and slightly less stuttering the same amount of information could be condensed to maybe 30% of the time. Well, something to improve for the next presentation...

If you'd like me to give a presentation somewhere next summer, let me know (at least 3 months in advance, please). I'll be happy to come, if you can cover the travel expenses, and find me a bunk bed to sleep in.

iPhone & iPod Touch support greatly enhanced

I went ahead and bought an iPod Touch (Apple's opinion) for debugging my little aprs web project. The Touch is basically an iPhone (Apple propaganda) - without the phone and the camera. It's much cheaper, but it has the same operating system, web browser, and can run the same applications, so it's fine for the purpose. I got the new second generation 16GB model (with external volume controls, speaker, etc), around 300 EUR ($400 USD). It's very pretty, and the user interface is very cool indeed.

I did a little debugging yesterday evening and tonight, and fixed a few rough corners which broke things for iPhone users. The fixes should help other mobile browsers, too. All of the pages should now render properly on the iPhone & Touch. The real-time map now loads new items nicely, and handles panning of the map. The map controls (zoom, satellite/terrain/map buttons) do not work, but that's a bug in Google's code, and they know about it already.

The changes I did in the real-time map code had an interesting side effect which benefits all users. When you pan the map on a normal web browser, targets coming in the view load a bit quicker, and the overall experience is slightly smoother than before. What a nice surprise.

The bad news is that it seems quite hard to make the real-time map work on the S60 browser, at least on my E61i (the static map works fine, of course). It simply blows up, probably runs out of memory. Maybe it could work on Nokia's new Linux-based products. Too bad I don't have one to debug with.

I'll get back to this some another day. A lot of stuff needs to be done (a nicer front page with address search, etc).

Preferences localisation

I just moved all the strings in the options window in the string database, making it possible to translate that part of the user interface. I also changed the name of that window from Options to Preferences, to match common user interface terminology.

This weekend I've been playing with a lift we rented. Yesterday I installed snow guards on the roof - 2*6m of tube secured near the edge, designed to keep snow and ice from falling down. Makes spring-time access to our front door a bit safer.

The feed of my 40m/20m butterfly dipole is also visible in this photo.

Sound and colour!

To celebrate my birthday (tomorrow!) I took the liberty to implement a couple of new features. For a long while I've been planning to add tabs to the configuration options window, so that it could be cleanly extended with new options. After I got that out of the way, it was quite straightforward to go on and add a couple of additional options which have been requested several times before:

It is now possible, from Options => Colours, to select the 5 colours used for track lines. You can also tune the track line width to increase (or decrease!) the visibility of each line.

Each station always gets the same track colour (colour 1, 2, 3, 4 or 5) out of the 5 selectable colours. If you find that your car always gets a blue line, and you would want to switch that to red, you'll see that colour 3 is blue by default, so you can switch colour 3 to red. And maybe switch colour 1 to blue to reduce the amount of red track lines. You could also set all 5 colours to red, if that's your favorite.

You can also enable sound effects from Options => Sound. Currently the only supported effect is a "tock" when a tracked station moves to a new position. I'm going to add different sound samples later. If you have other ideas for events which could trigger a sound, please let me know!

OH7RDA digipeater installation

Last weekend we went and installed the OH7RDA APRS digipeater on top of a hospital in Siilinjärvi together with the local hams from my old hometown, Kuopio. The Tarina hospital is located on a hilltop 16 km north of Kuopio, with a pretty good open view in all directions. We used to have a packet radio node at the very same location with 1200 bit/s access on 144 MHz and two 9600 bit/s links on 434 MHz, but the site had been abandoned for quite a while, due to lack of interest by everyone involved.

The old 2-meter radio, a modified Finnish mobile VHF radio with an embedded TNC2 clone (OH-TNC v2), was still in working condition, the power supply turned out to be just fine once one lead which should be attached to the rectifier was reconnected, so we just needed to install a vertical antenna, a new cable, and set up the APRS digipeater software.

(On the left: OH7TB attaching an N connector to the cable)

I obtained a 3*5/8λ vertical (dual-band, 8*5/8λ for 70cm), the guys in Kuopio had the coax and fixed the power supply. I set up an UIDIGI EPROM for the TNC, and replaced the backup batteries (sealed lead-acid) inside the radio-tnc combination.

I couldn't configure the UIDIGI to properly do WIDEn-N digipeating with callsign prepending (only when digipeating the packet for the first time), so I found a surplus miniature PC to run Linux and digi_ned. Now that the digipeater is already installed, it turns out UIDIGI could, perhaps, be configured to do the Right Thing, OH2NJR has been making some progress on that.

Anyway, I put a 2G CompactFlash card in the PC to make it more reliable - spinning hard disks at sites like this tend to break way too often. I installed Debian Linux on it, removed mostly all extra packages to make the installation small and quick to update, and then made sure it doesn't write on the flash card on a regular basis, since that tends to wear out the flash memory over time. That required 4 things:

1. Moving all temporary directories from disk to memory (/etc/fstab: "tmpfs /tmp tmpfs defaults,noatime 0 0", repeat for /var/tmp and /var/lock too)
2. Mounting all flash partitions with the noatime option (defaults,noatime in fstab). As an alternative, they could be mounted read-only, but that requires additional tricks.
3. Disabling stuff from crontab: see /etc/cron.(hourly|daily|weekly|monthly)/, /etc/cron.d/ - it's no use doing much else than log rotation on a box like this. Updating manual and locate databases is a waste of flash write cycles on an unattended mountaintop PC.
4. Moving all log files to /var/tmp and making sure they are rotated quickly enough so that the partition will not fill up. I edited /etc/syslog.conf to make all system logs to go to a single /var/tmp/messages, and disabled all logging on the digipeater software.

Then I installed and configured digi_ned so that it will digipeat RELAY, WIDE, WIDEn-N and TRACEn-N packets, but only up to WIDE3/TRACE3 - it'll ignore WIDE4-7 packets. No logging after the initial testing.

I also added a small script, run hourly from crontab, which restarts digi_ned if it would happen to die for reason or another. I haven't been running it anywhere before, so I don't know how stable it is, and on an embedded box with 128 megs of non-ECC memory, anything can happen in a few years.

A couple of hardware pieces needed to be purchased for the PC:

• A CompactFlash - IDE adapter: about 3 USD from DealExtreme - including shipping. Make sure you get the right type for your IDE cable (male/female, correct size - laptop IDE 44 or desktop-style IDE 40 cable)
• An USB serial dongle to connect to the TNC: less than 5 USD from DealExtreme. The Prolific driver in Linux has been written using reverse engineering techniques, and it doesn't support all of the low speeds below 9600 bit/s, but that doesn't matter here.
• The CompactFlash card. DealExtreme sells these too, but they aren't much cheaper there. There are "industrial" versions of the cards which should handle more write cycles, but if you can eliminate all of the periodic write cycles (watch your iostat) which happen after the reboot, it doesn't really matter.

Here, OH7FDN and OH7RJ are attaching guy ropes to the 5-meter-long Diamond vertical. Let's hope it lasts for a few years, and replace it with a proper commercial antenna when it breaks.

Some of the DealExtreme stuff doesn't have much quality packed in, but the price is fine. You can't get any better CF adapters anywhere, they're just going to cost more, and they'll still be from the same Chinese factory. Beware, that shop is very addictive. The stuff is just too cheap. I'm suspecting child labor and way-too-low wages for those who do the packing and mailing.

OH7VM and OH7RJ with the installed antenna.

Photos by yours truely. There's some more if you're interested.

The digipeater seems to be working fine. There's not much activity on the north side of Kuopio (yet), but you can take a look at the APRS position packets heard by OH7RDA. It seems to work just fine for a mobile in Nilsiä.

I'm also building a PIC-based logic card for the OH7RAA repeater (145.600 MHz, -1.6 MHz, in Kuopio). The board can already send a CW id, but I haven't yet wired the 1750 Hz and DTMF decoder chips. Yes, the voice on the mobile phone video is mine.

How do guessed time zones really work?

This question pops up every now and then, especially when the timezone guessing goes wrong for someone. So, here are some dirty details, which I just posted on the APRSSIG mailing list.

The aprs.fi service tries to guess where each site visitor is located. It's based on the IP address of the visitor, nothing else. Yes, it could be based on your default map start location, thank you, that's a good idea. Then, it looks up the timezone for the guessed city, which is pretty straightforward and works just fine. The guessing results are stored in a cookie, and you can force a retry by deleting the cookies set by aprs.fi.

For some areas, the visitor location guessing code simply guesses wrong. It works just fine for most people, and for some, it always gets it wrong. For example, it thinks everyone working for Nokia (Corporation) are actually located in the city of Nokia, Finland.

Currently the only real option is to select UTC in the Options window of aprs.fi, which, of course, does not really fix the problem. I should do a proper "pick any timezone" selection, like openaprs has. It's actually been "half done" for about a year now - I have the timezones database loaded in already.

The complication here is that the some of the time formatting happens on the client computer's side (in the Javascript code which runs on your web browser). Over there I can practically only select between UTC and the local time as decided by your web browser / operating system. There are no javascript localtime conversion functions which would take an arbitrary timezone definition (at least I couldn't find them :), and it'd be a pain to reimplement them with the DST stuff and everything. The "guessed" local time will be whatever you have selected in your operating system.

So, to do arbitrary timezone selection properly, I'll have to move all of the localtime conversions from the client-side code to the server side, and that'll make things marginally slower for everyone. Now the server is just giving Unix-style timestamp integers (seconds since 1.1.1970 00:00:00 UTC) to everyone who is looking at the real-time map, and the web browser gets to do the localtime conversion when it's needed. If your operating system knows your proper timezone, you'll notice that the real-time map view (the target info balloons etc.) gets it just right.

Yes, I'm going to do this eventually. The performance hit is marginal, it'll just eat a bit more memory on the web browser's side (to store the text strings for the timestamps in addition to the small integers), and a bit more CPU on the server side (to do the conversions for everyone). I'm trying to keep track of all of these and gain a little bit of extra performance everywhere I can, to keep things running quickly.

PS. I've been in Kuopio this weekend, installing the OH7RDA digipeater together with the local guys from my old home town. Thanks OH7RJ, OH7TB, OH7VM, OH7FDN. It's at a pretty high location, on the roof of a big hospital building, which is on a top of a hill. 3*5/8λ vertical, 20W, TNC2 with JKISS, digi_ned on a Linux PC, with a CompactFlash card instead of a hard drive. I'll try to document the setup with some photos later. It's nice to do some hardware hacking for a change! It'll be interesting to see how the digipeater's heard stations map develops for this new digi. Tomorrow morning, on the way home, I'll offer it some traffic on the south side of the city.

Slovene / slovenščina translation

S56G has started a translation to Slovenian, which I had missed. I have now enabled the partial translation. If you know Slovenian, or any other language with a missing or partial translation, please help with the translation project. Thank you!

Digi/igate coverage maps

Last night I finished implementing APRS igate and digipeater coverage maps. They come in two flavors (examples from the San Francisco area):

- A 'heard directly' map: http://aprs.fi/heard/W6YX-5, showing packets which have been (supposedly) heard first by the given igate or APRS digipeater. This map can occasionally show some extra coverage if there are digipeaters with no callsign prepending in the area, but I'm trying my best to catch those. If there is good direct receive coverage by one more igates, those will "eat away" the displayed coverage of the digipeaters in the same area, since the digipeated packets will be filtered as duplicates on the APRS-IS.

- A 'passed packets to the Internet' map: http://aprs.fi/gated/W6DTW. This display shows packets which have been gated to the APRS-IS by the selected igate. This gives a rough idea of the service area of the igate, together with the surrounding digipeaters.

The statistics are currently calculated over the last 48 hours. Links to these are only on the info pages (if applicable), but I'll try to add them in the info balloons on the map. The data was already in the database, I just had to add a single index and implement the user interface. As usual, there are a few new strings to be translated.

The 'heard' map could be useful for fine-tuning the PHG information transmitted by a digipeater.

Google Chrome supported

Google has just released Chrome, their new open source web browser. It seems to work just fine with aprs.fi, and it's blazingly fast too. Windows only, for now. They have a nice cartoon describing the internals of the browser. I'll add it to the list of supported browsers. Their EULA has some issues, though.

By the way, I'm shopping for an used iPhone or ipod touch. I need it for debugging and maintaining compatibility with aprs.fi. If you have one to sell or give away, let me know.

iPhone working (slightly)

iPhone support seems to be working slightly better now, but there are still some issues. They can be partially in Google's Maps API code, and partially in Apple's Safari code, and the fixes need to be done there.

There are bug reports in Google's bug tracker for the issues (I filed a couple, and there are a couple more submitted by others). I'm hoping that the good people at Google will fix them, or persuade Apple to fix their bugs.

• After panning the map, new points for the area are not correctly loaded, because the maps API doesn't give the correct corner coordinates for the currently visible area.
• You can't tap on an item, because click events do not fire on markers.
• You can't zoom or switch map type, since the standard Map controls (GSmallMapControl, GHierarchicalMapTypeControl) cannot be clicked on an iPhone.

Thanks go to Rasmus (a colleague at the $office) for borrowing his iPod Touch for a couple hours. If one of you happens to have a spare unit, you can find my address at qrz.com. :)

Update: I have obtained an iPod Touch for debugging, and enhanced iPhone support for APRS!

OH7LZB interviewed in the Japanese CQ ham radio magazine

Oba, JA7UDE interviewed me for the Japanese CQ ham radio magazine. The interview was published in the 2008/9 edition, which came out last week (list of contents, PDF). They've previously interviewed other software authors and APRS people, including Byon Garrabrant, N6BG (Byonics/TinyTrak) and Simon Brown, HB9DRV (Ham Radio Deluxe).

He mailed me a couple of the older magazines, and they seem really nice - there is so much technical content in there, and so few ads in comparison. Lots of long "how-does-this-stuff-work" articles with friendly and funny illustrations, and plenty of "how-do-I-build-this" articles. They're thick (around 150 pages), and unlike some other ham magazines, they're not half full of advertisements. Too bad I can't read Japanese. The schematics and pictures are almost enough to complete some of the projects, though.

Kenwood using aprs.fi @ Ham Fair 2008, Tokyo

The JARL Ham Fair 2008 was held in Tokyo last weekend. Oba, JA7UDE took these nice photos of Kenwood showing off aprs.fi on their big screen, together with their new APRS-capable TM-D710A mobile rig.

Oba reports that they displayed aprs.fi in both Japanese and English modes, and they seem to have run Google Earth with the aprs.fi overlay, too. Very cool indeed, thank you Kenwood for the nice little extra publicity!

Thanks to SQ6NTI for the link.

APRS PHG circles

I've just installed an initial implementation of PHG (power-height-gain) circles on the live APRS map. They can be enabled by clicking on the new PHG icon in the top right corner. PHG circles are shown for APRS stations which are transmitting the PHG extension in their comment text. The first click enables half-sized circles, which are supposed to resemble the reach of an APRS digipeater from a mobile user's point of view (small antenna at low height, lots of fading and multi-path propagation). The second click enables full-sized PHG circles which are calculated according to the APRS 1.0 specification, and might be quite optimistic for mobile users, but more realistic for connectivity between digipeaters and other installations with better antennas. Not surprisingly, the third click disables PHG circles again. If you'd like to add the PHG extension to your digipeater configuration, please try the Online PHGR calculcator! aprs.fi doesn't display the rate yet, though.

Firefox 3 bug workaround, try 2

I've just installed an updated version of my AJAX JavaScript code on aprs.fi. It seems to work better for me on Firefox 3 - the live map no longer gets stuck in the 'updating' state once there are too many targets visible, or a very long track line.

Please let me know if this change fixes this bug for you by posting a comment after this post. I hope it didn't break any other browsers - I tried the usual FF2/FF3, MSIE6/7, Opera, Safari, Konqueror.

7-day track views

I've just added code to show up to 7 days of track data on the map when looking at a single tracking target. Thanks to Steve, K9DCI on the APRSSIG for reminding me about this. :) This only works for single target views, since longer time range searches for global data would place a heavy load on both the database, as well as the web browser.

Showing the track wasn't hard. As usual, getting the user interface to work on MSIE was. Found out the hard way that the disabled attribute isn't working on the select list used for time range selection, so I had to resort to completely removing entries which are not usable.

Update on Friday, 8th of August: I just realized it doesn't work with the date selection menu - I will fix that one later.

Performance issues during the past few days

I'm currently in Mexico, performing at the Zacatecas International Folklore Festival. I have been in Mexico for just about two weeks now, first having a holiday in Mexico City and Oaxaca, and now playing guitar with the Finnish folk dance group Petkele at the festival. So, I haven't been paying much attention to the aprs.fi service.

But today I got an automatic alarm about the service being pretty slow, so I checked the systems and found out that my recent status message view changes had introduced a memory leak in the backend system, and the master server was swapping pretty much. This has caused some slowness and data loss over the past 4 or 5 days, as you can see in the statistic graphs. I restarted the data collector processes to regain the leaked memory, and will look into this in more detail once I'm back home. It leaks so slowly that it should work just fine for a week.

I'll have to tune the alarm system to be a bit more sensitive for this kind of slowness. I think I've forgotten to set up the "too much swap IO" alarm, too.

Static maps

I just did a quick and simple implementation of static APRS maps for mobile browsers and other javascript-challenged or memory-constrained clients. You can now click on static maps in the info view to show a simple map, which does not try to update automatically, or do any other fancy stuff. It should work on just about any mobile phone with XHTML browsing support, or any old browser. The view doesn't support APRS icons, but the icon is shown in the title above the map. It does have zooming, but no panning, and no "view all" mode.

For example, take a look at the position of my motorcycle with APRS.

More face lifting

I did a little more CSS and graphics tuning to make the pages look a bit more colorful and modern. Not much, but a little. As usual, it took plenty of time to figure out how to make it look the same on IE6 as the other browsers. How do you like it, feedback is welcome?

New status packet views

I have added proper support for APRS status packets, and started storing them separately from beacons. You can now browse APRS status packets based on the callsign, and browse the status history of each station sending status messages.

Naturally this called for new strings to be translated. Please visit the Translation tool page to update your translations for the status/ category. I also changed the strings in the generic browselist category so that complete sentences are used - this should help translation work for many languages, allowing you to reach the proper ordering of words. Please note that you can copy and edit your old translation to match the new English string, just click on Toggle history and then copy to move the old translation to the empty editing field.

Again, a big thank you to everyone involved in the translation work. I know the translations help a lot of people to understand what's going on here.

Balloon flight right now: OH6SIX, Pula-Ilmari IV

It's the last day of the summer camp of the Finnish Amateur Radio League (SRAL), and the guys there just launched a balloon with an Opentracker 2 and a cross-band FM repeater (145.4 MHz in, 433.4 MHz out). It's now at 5087 meters, going up. There's also a CW/HELL beacon at 28.322 MHz. Track OH6SIX!

Kawasaki ZZR1200 with an OpenTracker

Here's my Kawasaki ZZR1200 motorcycle, equipped with an OpenTracker 1+ and a Puxing PX-777 handheld radio. I installed the APRS tracker in May 2008. It's callsign is OH7LZB-10. Click on the photos to get a larger view.

The radio and the tracker fit nicely inside the box under the seat. It's generally a dry place, but might be slightly humid. Maybe some additional weather sealing would be in place. Maybe I'll put the whole lot in a sealed plastic bag, or fill the tracker with hot melt glue.

The APRS tracking setup gets it's power through a Powerpole connector and a 1A fuse from the tail lights wiring, which is powered whenever the lights are on (they're turned on automatically when the engine is running). There is an accessory power connector under the seat, but it goes directly to the battery, so it's always powered.

The PX-777 wants roughly 8 volts of DC, so I glued a 7808 regulator with a small heat sink to the back of the radio. I feed the same 8V to the OT1+ tracker, which has an internal 5V regulator, which also powers the GPS unit.

I built a custom antenna mounting bracket out of aluminum profile, a female BNC chassis connector, a bit of RG58 and a crimped SMA connector for the Puxing. The bracket is attached to the metal tubing of the Kappa/Giwi 3-bag mounting structure. All RF connections are sealed with heat-shrinking tube. The antenna is a Nagoya NA-771 BNC 2m/70cm whip. The antenna position is not an optimal one - but it's practical, and didn't require any modifications to the bike itself. And it doesn't affect the looks too much. I'm planning to try out a regular 1/4th wave vertical, which will require proper grounding of the bag mount.

The answers to the FAQs are: 1164cc, top speed around 270 km/h (167 mph). No, I haven't tried it. This is my third bike, the previous ones were Kawasaki ER-5 and Suzuki GSX750F.

Database statistics break

Some of you might have noticed that the aprs.fi statistics graphs were broken for a few days. I added some new statistics collection in the configuration on Friday, which worked just fine, but I also accidentally broke some old configuration (changed database password) on the way, and didn't notice it until yesterday.

The problem only affected the aprs.fi operation statistics collection, not APRS-IS data collection. The service itself worked just fine, it's performance data just wasn't collected too well.

Facelift and new buttons

Before leaving for the midsummer night's long weekend in the countryside (we had friday off from work in Finland) I did a little facelift for the main map view. After a little testing and bug fixing during sunday I'm installing this upgrade on the production servers.

I added a full screen mode (well, almost...) - click on the new "collapse" button in the top right corner to hide the menu bar. Thanks to Kauto (OH2LFM) and others for requesting this one. The new button is sometimes slightly misplaced when running MSIE6 - please upgrade to Internet Explorer 7 to get rid of that IE6 rendering bug.

I also added 'search' buttons for the callsign and address lookup input fields. They should enable Tony (VE3TK) and others to use aprs.fi on the Nintendo Wii (lacking an 'enter' key on the virtual keyboard), it'll probably help other embedded devices too. They also fix the problem of quick typists - pressing the (real) 'enter' key while the last key used in the callsign entry was still depressed failed to trigger the form submission, and you needed to press enter again. I'll add submit buttons on the rest of the forms later! Usability before coolness!

The facelift part consisted of removing the unnecessary "fieldset" box around the menu bar and adding a background image with a nice blue colour blend. Thanks to Gimp for help with the icon and background graphics!

I also added a workaround for a bug in the latest Google Maps API code, which partially broke address search. A javascript error broke the map view after about half of the address searches.

Firefox 3 was released last week, and it still seems to contain the bug which makes it break with aprs.fi every now and then. Less often, but still. Not recommended.

aprs.fi presentation webcast tomorrow at 0700 UTC

I'm giving a presentation on aprs.fi tomorrow morning at the 30th Nordic VHF/UHF/SHF-meeting in Sappee, Finland. The presentations are broadcasted live on the Internet and on the 1.2 GHz ATV repeaters in Helsinki and Tampere.

My presentation will be on tomorrow morning, 14th of June, at 0700 UTC (10 AM local time).

Sorry for the late notice!

Greek aprs.fi

Costas (SW2HUI) has contributed a complete translation of aprs.fi in Greek. ελληνική γλώσσα looks beautiful and reminds me of a few very nice holiday trips, too. Thank you, Costas!

How to authenticate licensed hams?

It would be interesting to provide some methods for two-way communication in the aprs.fi web user interface. Say, APRS messaging from a sort of a web chat, as a simple and obvious example. Or marking their position on the web map and having it seen on APRS-IS. Having tracker devices with an open-source firmware (like OpenTracker and the Finnish HaMDR) opens up more interesting solutions, like remote control, or actively requesting information from a vehicle.

But how on earth could I figure out if an user of the web site is a licensed amateur radio operator, so that he can be allowed to transmit? Automatically, with somewhat strong authentication against an existing database or set of databases, without a need for validating each user by hand? To be useful, it would need to work for more than a few countries (Finland, USA to start with).

It's quite unlikely that the issuers of the licenses (like the FCC in the USA, Ficora in Finland) would bother to create Internet authentication services for their license databases. But the amateur leagues (at least ARRL in the USA, and SRAL in Finland) are already giving out accounts to their web sites ("for members only" features), and I suppose they also know whether each member is licensed or not.

What if the leagues would provide an authentication service using the OpenID protocol? An user would first type in their ARRL or SRAL email address (oh7foo@sral.fi, or n1example@arrl.org), then provide their sral.fi or arrl.org password to SRAL's or ARRL's site, and the authentication result, together with licensing status, would be passed back to aprs.fi (or another "licensed hams only" site).

This would require for the users to be members of one of the organizations providing OpenID authentication. But maybe some individual or organization could set up a trusted OpenID-enabled amateur database, charging each user $2 for the work of validating their license status.

Please, post a comment if you have any ideas for automatically validating the license status of a web site user.

Ham::APRS::FAP 1.12 released

On monday evening I uploaded the new version of our APRS parser on the Comprehensive Perl Archive Network.

Version 1.12 includes a parser for the !DAO! extension, which can be used in uncompressed and mic-e APRS packets to report the datum and an additional digit of position resolution. It also reports the position resolution (in meters) for parsed position packets, depending on the type of the packet (compressed, mic-e, uncompressed), the presence of DAO and the amount of position ambiguity. These improvements were implemented by Tapio, OH2KKU.

I felt an urge to do some slight improvements on it myself before releasing it, and couldn't come with anything that would be both quick to implement and actually useful, so I just added some tests, cleaned up the API and packaging slightly, fixed POD documentation style, upgraded MakeMaker, and added a little example script, just to make CPANTS happier and increase the Kwalitee rating a bit. :)

!DAO! support for greater precision

Tapio Sokura, OH2KKU, implemented the APRS precision and datum option (DAO) in the Ham::APRS::FAP parser last night. Looking at the IRC channel log, he started working on it at around 01:40 AM local time, and finished at 04:33 AM.

A few minutes ago I installed the new parser code on aprs.fi, so those of you transmitting uncompressed or mic-e packets with the DAO extension should now see the improved precision.

Compressed format packets have enough precision (around 1 foot) already, so DAO is not useful with it. aprs.fi properly decodes compressed packets (including speed and course), and compressed packets are the smallest ones (they help conserve valuable channel time on 144.39 and 144.800 MHz), so I would recommend using the compressed format instead of uncompressed or mic-e with DAO.

The only supported datum is still WGS84, no conversion from other datums specified by DAO is done.

Imperial and nautical units for Google Earth KML APRS view

The unit configuration selected in Options now applies to the Google Earth Network Link, which is produced when you click on the Google Earth KML link on aprs.fi. Fahrenheit temperatures are supported, too. US users should get Imperial units and Fahrenheit temperatures by default, UK users should get Imperial units and Celsius temperatures.

If you have installed the aprs.fi Google Earth APRS link before, and wish to change your units configuration, please do the following:

1. Delete your existing link from Google Earth by right-clicking the top-level "APRS:" link and selecting Delete (not Delete Contents)
2. Select your units configuration in the aprs.fi Options window
3. Open a new KML link using the Google Earth KML link on aprs.fi

This way the new units configuration will be copied over to the Google Earth KML link. When you change your configuration again in the Options, you'll need to delete the existing link in Google Earth and open up a new one from aprs.fi.

Some UTF-8 character encoding issues were also fixed in the KML interface.

Little enhancements

Joe, K7JD has been pointing out (for quite a while now) that there's more accuracy in the speed and altitude formats used on aprs.fi than would be appropriate. I've removed the decimal digit from the speed and altitude formatting functions now, since there isn't that much accuracy in the source data anyway.

Max, KG4PID pointed out that the info balloons on the map show really old weather data for stations which have sent even just a couple of WX packets sometime in the last summer. I made a small change to make it only show WX data updated within the past hour.

I've also compressed the big javascript files, so that they will download faster, especially on mobile devices. This process can also be called optimizing, since they will run slightly faster on many browsers, and obfuscating, since they're now much harder to read. Sorry about that.

Firefox 3 beta not working with aprs.fi

Zach Sadecki was the first to let me know that the Firefox 3 beta has some trouble with aprs.fi. I did some testing, and sure enough, it fails sooner or later with some JavaScript errors being printed in the Error Console. It has something to do with the decoding of the XML in the AJAX XMLHttpRequest responses.

I verified the site still works with Firefox 1, Firefox 2, MSIE 6 and 7, Konqueror and Safari, and went to report a bug in the bug tracking system of the Mozilla project, only to find that Zach had already issued Bug 425586 – javascript doesn't run that works fine on firefox 2.0. So, after a bit more testing, I added a comment there. This seems like a FF3 bug to me, one that is a bit hard to work around in aprs.fi code.

Zack also pointed out that the Gecko-based Epiphany browser suffers from the same problem.

It might be useful if you'd happen to find another ajax-based site which suffers from exactly the same problem. Please, drop a comment if you do.

Update: I've installed a workaround for this problem, and it seems to work. I'm re-parsing the AJAX XML using the GXml API.

APRS bulletin group browsing

Tonight I added a small feature to the APRS bulletin board. It can now show bulletins belonging to a specific group, for example MAREA, EI or EVENT.

Directing bulletins to specific interest groups could make the bulletin board scale up a little bit, currently it is filled by just the same old web site and BBS/DX cluster advertisements.

A few days ago I did some programming on the hamdr APRS tracker firmware. It was fun to program C on a 16-bit embedded platform for a change. Tuned it's telemetry transmission a little bit, and added TLL NMEA waypoint sentence support.

Trackers in airplanes

Only a moment's consideration will reveal the amazing possibilities for our aviation community.

Sam (KJ4CKK) has installed a Byonics MicroTrak-300 in his self-built RV6 kit aircraft (which took him 995.25 hours to build) and prepared a very nice guide for non-ham aviators about getting a license and installing an APRS tracker in a plane. Tracking airplanes is becoming more and more popular.

His plane's tactical callsign (as assigned by the FAA) is N399SB. Currently the last received position seems to have a lat/lng of (nearly but not exactly) 0/0 , probably a bad GPS fix, but just pick another day from the date menu on the right to see some of his flight tracks. They look even better on Google Earth.

Some more planes: N789PH (RV-9A) OH-XKR (Kitfox 4) OH-XST (experimental) N821RP (Long-EZ)

vansairforce.com has a discussion forum dedicated to APRS tracking of airplanes.

On duplicate and delayed packets

I've had a few questions about how my APRS site detects duplicate packets and position packets which arrive in the wrong order. I've responded to the questions over email, but maybe it'd be useful to write something down here for a wider audience.

I will present some background first, most of which is not news to anyone who has followed aprssig or APRS-IS traffic for a while.

Packets sent by APRS stations are usually received by multiple igates. A packet might be heard directly by one igate, and it might be heard much later again after a few digipeater hops. As a result, the APRS-IS network servers will receive multiple copies of each packet. To reduce load on the network, they try to catch the duplicates and discard them. javAPRSSrvr stores packets for 30 seconds and discards any duplicates received during that time.

But some duplicates still get through, because sometimes it takes more than 30 seconds for the packets to get to APRS-IS. Here's a couple scenarios causing this:

1. There are some broken digipeaters out there, which can buffer packets for quite some time before retransmitting them, due to a busy channel or a broken squelch/DCD circuit. A digipeater should not buffer a packet for more than a few seconds before transmitting it. If it can't spit the packet out rather quickly, it should discard the packet.

2. There are some igates which seem to buffer the packets before getting them on the APRS-IS. This is generally not a bug in the igate software or a problem in it's configuration. Instead, the delay can be caused by congestion or packet loss on the Internet link between the igate and the APRS-IS server it is connecting to.

If there is even little packet loss (due to congestion or a bad ADSL line, for example), the TCP connection between the igate and the APRS-IS server will do retransmissions to make sure everything gets through. When packets are retransmitted, the operating system's TCP stack will assume that the link is congested, and to reduce the congestion, it will slow down it's transmission rate (back off). Exponential retransmit timer backoff is used - if multiple transmissions are lost, the retransmit timer will be doubled, up to a fixed limit (which is usually around 60 seconds). As a result, it can take a minutes for an APRS packet to get to the APRS-IS from an igate. (I simplified the retransmission timer stuff on purpose, congestion control is actually more complicated than that nowadays, but the basic issue remans.)

This is how TCP works - it is doing exactly what it was designed to do. Maybe we should be using UDP on the igate uplinks, or SCTP (on platforms which support it). I personally think we can live with losing some packets on the Internet, since we're losing much more packets on the radio path anyway. When TCP is used, maybe there could be a ping-pong method to measure the latency between the server and the igate, and to drop the link if the round-trip time goes anywhere near 20 seconds. This would, of course, eat some more bandwidth.

The visible effect of delayed packets is that a packet transmitted from a moving car 64 seconds ago might arrive at aprs.fi later than a packet that was transmitted 4 seconds ago. If the car was moving at 100 km/h (27.8 m/s, 62 MPH), and that packet would go unnoticed and would be stored to the database as the latest good position, the car would suddenly jump back 1.6 km on it's track. When the next packet would be received, it'd quickly jump forward to it's current position.

Without additional filtering the above scenario is met very often, and it looks very ugly on the map. The hard part filtering the old packets and duplicates without losing too much valid data.

APRS position packets don't usually have timestamps. Some packets do have timestamps, but even then, the timestamps are not very usable - they are sometimes lacking a date, they are often sent in some other timezone than UTC (and there's no way to know which), and even though a GPS unit would provide very accurate time for free, the clocks of many APRS stations are still off (many are transmitting a fixed location without a GPS unit). It's a bit hard to tell whether a timestamp is usable or not, so aprs.fi is not currently using them for anything. It's simply using the time the APRS packet was received from the APRS-IS.

Since the timestamps are not very usable, it is hard to tell the original order they were transmitted in. If the packets would have good timestamps or sequence numbers, sorting them afterwards (in the database) might still have a significant performance impact. So, for now, I'm using them in the order they were received.

Here's what aprs.fi is currently doing:

1. Packets having a latitude or longitude of 0 are dropped (usually a bad GPS fix).
2. The distance between the previously accepted position and the new position is calculated. If it's less than one meter, the "last seen" timestamp of the previous position is updated and no new point is inserted in the database.
3. If the previous packet was received within 5 seconds, the new packet is discarded.
4. The speed required to move from the position indicated by the previously received packet to the position indicated by the new packet is calculated. Arrival times of the packets are used for the calculation, so this calculation does not accurately reflect the true ground speed of the target. If the calculated speed is over 500 km/h (311 MPH), the new packet is discarded. This gets rid of a lot of jumps caused by bad GPS fixes and out-of-order packets.
5. The latitude,longitude,course,altitude set of the new packet is compared to the sender's previously accepted packets over the last 30 minutes. If an exact match is found, the new position is dropped as a duplicate. This step catches duplicates, while the previous step gets packets which are delayed or just far off.

These tricks (especially the speed limit) have some drawbacks. If you have a tracker on a jet aircraft or a satellite, you're out of luck. But I don't think any of the APRS satellites announce their position anyway - since they're moving very fast, they'd have to transmit the position very often for it to be useful, and it's probably better to use the channel bandwidth for relaying packets from ground stations and calculate the position of the satellite using tracking software.

If you fly overseas on a commercial jet and restart your tracker soon after a flight, it'll take some time before your new position is accepted. Typical passenger aircraft has a cruising speed of 800-900 km/h, so after a 3-hour flight it can take another 3 hours before you'll be on aprs.fi again.

The above algorithm is a compromise. It looses some good data, but for most of the time it seems to get rid of a lot of old data and clean up the map display a lot. It can be tuned in either direction, but with the current protocols it cannot be made perfect.

There are a couple things you can do to reduce the risk of duplicate and out-of-order packets from your tracker:

• Do not use a very long digipeater path. A couple hops (WIDE1-1,WIDE2-1 or WIDE2-2, or whatever is recommended in your country) should usually be enough. Using a longer path will increase the possibility of out-of-order packets due to a longer, variable time spent during the digipeating.
• Don't send packets very often. It's usually enough to send packets once per minute or two when you're moving, and once per 20-40 minutes when you're not. Smart Beaconing and proportional pathing are good things.

If you run an igate, please use the ping command to determine that your Internet uplink does not have any significant packet loss.

If you managed to read this far - thank you for your attention!

AIS from Lake Erie, USA

Thanks to Jeffrey, KC8NNO, we now have AIS ship tracking data from Toledo, Maumee Bay, Lake Erie, USA. Thank you!

Ham::APRS::FAP 1.11 released

I uploaded version 1.11 of the APRS parser module on CPAN today. It includes a telemetry parser and a small fix in the automatic tests (a timestamp check started failing after a certain date, since the APRS timestamp in the tested packet doesn't specify a full date+time). This is the version currently used by aprs.fi.

aprs.fi in Czech & Custom search engine

Thanks to OK1MX and OK1MGJ, aprs.fi is now available in čeština! Other translations have received updates, too. We're now up to 15 languages!

Lately I've been busy with another little programming project, but a few days ago I found time to implement another little Google gadget: A custom Google search engine for APRS and Amateur Radio. It's offered by the /info/ view if a given callsign was not found in the aprs.fi database, and will hopefully lead you to the station's home page or callbook info. If you like it, you can also add it on your personalized Google home page.

Small fixes in the translation tool

This morning I did some small improvements in the aprs.fi translation tool. It now gives some feedback when buttons are pressed (like "Saved changes!"). It works better with strings containing " and ' characters (there was a little escaping bug in the HTML generation). It shows string-specific descriptions and translation hints (which have existed for quite a while for some strings). It also cleans up some extra whitespace from the translated strings, and uses a multi-line editing text box for strings longer than 90 characters.

Danish and Spanish APRS!

EA4EKS and EA2BVF have worked on a translation of aprs.fi to Español, while OZ2LPA and OZ5ACU have been translating the site to Dansk. This brings the total amount of languages to 14!

A lot of other people have been contributing updates to the existing languages, too. On behalf of the non-English-speaking 55% of aprs.fi users, a big THANK YOU to everyone involved in the translation work!

Between 14th of January and 13th of February 2008, 45% of aprs.fi visitors preferred the English language.

Second server in use! Hooray.

The new server has been taken into use just a few minutes ago. This should maintain the high speed and performance of the aprs.fi service while the amount of users keeps increasing. Please drop a comment if I broke something on the way!

The servers are currently sharing load using database replication and DNS round-robin. The setup isn't really highly available or fail-proof. If one server breaks, the service will not function properly until I do corrective actions (remove the broken server from the DNS and possibly start the master APRS data collecting processes on the secondary server, if the primary dies). But at least that'll only take a few minutes to do, instead of a lengthy hardware repairing and backup restoring process.

There's also a third online replica of the database for the purpose of taking database backup snapshots on a third server (thanks ZFS on Solaris 10). So even if erroneous data is propagated over the replication and data is corrupted on all of the running database servers, I'll be able to roll back to an older snapshot and avoid losing all of the history data.

I'll continue working on automatic fail-over - it'd be nice if a hardware problem wouldn't cause much of an outage. I've done this sort of things before at work, so the plan is quite clear, it just takes some time to do it properly.

Telemetry, wildcards and new strings

This morning I installed APRS telemetry support on the production server. Some APRS stations use the telemetry protocol to transmit things like temperature (inside, or measured from the heat sink of a transmitter), battery voltage, or number of transmissions by a digipeater. Some also send states of switches or relays. For example, take a look at the telemetry data transmitted by the digipeater VK5RAC-1, or the DIGI_NED digipeater PI1APA.

I've also implemented wildcard searching in the weather and telemetry views. Should help you in finding weather and telemetry-enabled stations in your area.

These features added some strings which need to be translated. I also did some changes in the weather and info page strings, making it possible to translate some more of them, and to make more proper translations for some languages (more complete sentences translated). I'll continue this task later.

I also installed the new server in a co-location site a couple days ago, and I've been testing it under high load and benchmarking different disk and database configurations. Going to take it into use this weekend, I hope!

Terrain maps and fixed rain graphs

I just added the new Terrain map feature of Google Maps, and changed to the hierarchical map type control (thanks VK2HIM). The Hybrid selection has become a "Show labels" selection under the Satellite map type. The terrain map looks very pretty in the mountains, and offers a less cluttered option elsewhere.

The Ham::APRS::FAP APRS parser module had a bug in weather packet parsing - the "last 24 hours" and "since midnight" rain values were mixed. The bug has been fixed in FAP version 1.02, which has now been installed on aprs.fi.

Outage: Building redundant setup

I'm taking the database down today for some time. I need to take a new consistent copy of it to enable transaction logging and replication to the new web server and a backup server. Sorry for the trouble.

The new server should be delivered today, by the way.

Running SBS-1 BaseStation on Linux

This is slightly off-topic, but you can probably guess why I'm interested in this stuff. There's been discussion on the forums whether you can run BaseStation on Linux, but I couldn't find the answer on the web, so I'm posting it here after finding out myself.

I bought myself an SBS-1 (by Kinetic Avionic Products) for a Christmas present. I've been running the BaseStation software on Windows so far, but that's not fun if you want to run it remotely.

So, tonight I tried to run it in Linux on top of Wine. It worked. Here's how:

1. Install a recent version of wine, and practically any versions of the old but incredibly useful tools nc and cu. On my Debian system this can be done using the command apt-get update && apt-get install wine nc cu. I'm runnig debian testing (lenny, in January 2008). This probably applies to Ubuntu, too.

2. Run some other Windows software with wine first, get it configured on your account and see that it actually runs something successfully.

3. Download the BaseStation CD which contains the driver DLLs. The driver DLLs are not really used, but they have to be present on the system so that BaseStation.exe will run.

4. Extract the DLLs from the CD in a temporary directory, and copy them to the system32 directory of your wine installation:

mkdir tmp && cd tmp
unzip ../BaseStation-1-1-1-119-CD.ZIP '*.dll'
mv *.dll ~/.wine/drive_c/windows/system32/
cd .. && rm -rf tmp

5. Download the latest version of BaseStation (I tried 1.1.1.125).

When wine is properly configured on your system, Firefox will run the wine-safe installer for the EXE file automatically, and basestation will be installed. If this doesn't happen, you might have to run the installer by hand (wine-safe setup.exe). After the installation, the installer will quit. Don't run BaseStation yet.

6. The application apparently cannot talk to the USB bus under wine, so we'll have to do a trick here. Connect the SBS-1 to the USB port of your Linux system, and observe the output of the dmesg command - it should notify you that an USB serial port has been found. On my system it looks like this:

usb 2-2: new full speed USB device using uhci_hcd and address 5
usb 2-2: configuration #1 chosen from 1 choice
ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
drivers/usb/serial/ftdi_sio.c: Detected FT232RL
usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0

Now, the SBS-1 hardware can be reached behind /dev/ttyUSB0 at 921600 bits per second. We could connect to it using the very simple Unix "call up" program cu --nostop -s 921600 -l /dev/ttyUSB0, but we cannot talk the proprietary binary protocol used by the SBS-1 and the BaseStation software. Yet.

7. So, we run cu under another very simple and extremely useful Unix tool, nc, which is the swiss army knife of TCP/IP. We tell nc tolisten on TCP port 19251 using the localhost IP address of 127.0.0.1 (so that it cannot be connected by anyone from the Internet), and to start up the cu program when a connection arrives:

nc -l -s 127.0.0.1 -p 19251 -c "cu --nostop -s 921600 -l
/dev/ttyUSB0"

8. Now, while we have nc waiting for the connection, we can start up BaseStation in another window:

wine .wine/drive_c/Program\ Files/Kinetic/BaseStation/BaseStation.exe

Tell it to connect over the network, the address is 127.0.0.1, and the port is 19251.

There's no reason why you couldn't do this over the Internet, either. You might want to run cu under inetd instead of nc, though, since nc will quit when the connection closes. Remember to set up your firewall / tcp wrappers properly!

The 2-hour outage last night

After adding 4G of memory on the server (which went well, as usual) I had to do some disk arrangements, which took some time to complete. After booting up the Apache web server didn't return web pages correctly any more - web browsers would show the HTML source code instead of nicely formatted pages. After playing with a network analyzer (thanks Wireshark) and getting a little help from an ex-colleague I finally got it fixed.

I had upgraded a good bunch of libraries on the system earlier, but hadn't really restarted the web server processes afterwards (I'm only running a graceful restart after log rotation and config changes), so the web server was still using the old libraries. Now, after the reboot, new libraries were linked in, and it broke. There was an extra line break (\r\n) after the Server: Apache... HTTP header, and web browsers promptly stopped parsing the headers, and assumed a text/plain content type, and showed the HTML.

The strange thing was that enabling content-encoding compression (SetOutputFilter DEFLATE) fixed the problem. While it did work, the header was:

Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8g

While it didn't work, the header was:

Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6
(+ the extra CRLF, then Connection: close and the following headers)

The workaround was to set ServerTokens Prod, so that the header only says Apache, and doesn't give any hints of version numbers or modules. My best guess is that disabling DEFLATE changed library linking order so that the openssl version query returned "\r\n". gnutls maybe?

The sysadmin lesson to learn here is probably that you should restart services depending on libraries which you have upgraded, so that incompatibility is revealed right away. It's nice to know which upgrade broke what. It's not fun to see applications break after "just a reboot".

On the positive side, the system isn't swapping any more.

Maintenance outage: adding memory

The aprs.fi server is going to be down for some time tonight or tomorrow, while I'm adding 4G of memory in it. Sorry for the inconvenience.

Lost: Find 815: Christiane I on APRS

ABC studios, an Australian company called Hoodlum and the creators of the TV series Lost have created an alternative reality game called Find 815, which produces content for fans of Lost during January. The first episode of Season 4 will be aired on January 31st. Lost is pretty popular, and so is the Find 815 game. The game is described in more detail on Lostpedia, a wiki site dedicated to Lost.

The story briefly mentions amateur radio, and involves a ship called Christiane I. The fun part is that Christiane I has an APRS tracker onboard and is now sailing somewhere near the Christmas Island! There has been some speculation whether ABC has actually hired a real ship, which could be tracked using APRS, and a few popular blogs and forums have linked to findu and aprs.fi.

I cannot comment on whether the ship tracker is authentic, although the TCPXX path does mean something to APRS experts.

Rotating APRS symbols

I've just installed the rotating APRS symbol code on the production server. I hope it won't slow your browsers down too much. It will cause some slowness, and eat a bit more memory, but it might be worth it.

The symbols have been rotated in 10° steps (0° to 350°) using Gimp's scripting language (Scheme / Script-Fu) and a little Perl. This was my first piece of Scheme, and my favorite quote from the Script-Fu tutorials was "Debugging Script-Fu scripts is only slightly less painful than stabbing yourself in the eye with a dull spoon". It's so true. I would have used imagemagick, but it broke the transparency. So I learned a new programming language. :)

Turkish APRS

TA2T spent 5½ hours last night translating aprs.fi in Turkish! Thank you.

Over the weekend I tried to make the map icons rotate and point to the course of a moving station. Got it basically working, but it still looks too ugly to be published. Need to do some graphics conversion work first. It might have a performance impact, I hope it won't be too bad.

Ordered a new server.

Today I ordered a new server for aprs.fi. Intel Core 2 Quad (Q6600 2.4 GHz, single CPU with 4 CPU cores), 4GB of ram initially (will probably upgrade to 8GB later this year), 2*320G SATA disks (16 MB cache, NCQ, 5-year warranty). 1155 EUR, about 1700 USD. 1U rack case, two gigabit Ethernet interfaces (Intel). This should help performance a little bit, but I'll probably have to get another one later this year. This one should arrive in about a week.

I've also ordered a 4GB memory upgrade for the current server, which is 183 EUR (270 USD) - fully buffered ECC memory is a bit pricey, and that's what the server requires. The new one eats unbuffered, which is only around 100 EUR for 4GB now.


In case you're wondering, my paypal account is hessu@hes.iki.fi. Using aprs.fi is free, and will remain so.

Portuguese translation and a little more colour on the map

CT1AKV spent hours last night and today translating all of the strings to Portuguese! Obrigado!

I spent a couple hours and made the callsign labels on the map change colour depending on the type of the tracking target. APRS items get blue labels, APRS objects get red labels, weather stations get yellow labels and AIS ships now have green labels. Normal APRS stations still have a white label.

The bulletin page now shows empty categories (the "local" category is empty for most of you, since it only shows bulletins and announcements sent by stations within 500 kilometers of your location).

APRS bulletins and announcements

Bulletins and announcements can now be viewed on the new APRS bulletin board page.

The APRS bulletin format doesn't really scale up on the Internet, but the page tries to show local announcements (within 500 km of your location) first. If your location is not guessed correctly, use the Save current map view as default view Option to tell the site where you're located.

Saving default view + beacon lookup speedup

You can now save the current map view as the default view by selecting the Save current map view as default view option. The map's center point (or tracked target callsign), zoom level and map type will be saved in the settings cookie, and recalled when you next visit the site (unless another specific location or callsign is requested).

The beacon list view gained a lot of speed after an optimization. Looking up beacons sent by a callsign now takes milliseconds instead of seconds. I had to recreate a database table to do this, though, and some history was lost, but hey, they were only beacon packets. We'll get new ones for free!

Français and language subdomains

The French translation is now nearly complete, thanks to F4EIR, HB9HFD and HB3YKO. Thanks!

Last night I added per-language subdomains, so that the translations can be easily sampled and indexed by web spiders like Google. So, to try out APRS maps in any of the 9 different languages, you can simply add the two-letter ISO 639-1 country code to the URL:

• Deutsch - German
• English
• Suomi - Finnish
• Français - French
• 日本語 - Japanese
• Norsk - Norwegian
• Nederlands - Dutch
• Polszczyzna - Polish
• Svenska - Swedish

To permanently change the language in aprs.fi, you need to change the preferred language settings in your web browser (Firefox 2.0: Edit -> Preferences -> Advanced -> General -> Languages -> Choose, Firefox 1.5: Tools -> Options -> Advanced -> General -> Languages -> Choose, IE: Tools -> Internet Options -> General -> Languages). Move your preferred language first in the priority list. This will also affect other well-behaving web sites like Google.

The translations have been made by volunteers.

APRS digipeater path adviser

The station info page now gives some feedback and advice on APRS digipeater path settings. It approves paths which request less than 4 digipeaters and suggests paths which have 2 digipeaters (WIDE2-2 or WIDE1-1,WIDE2-1 or TRACE2-2). It also gives advice on invalid usage of RELAY and WIDE1-1 when they're not the first component of the path, and suggests replacing RELAY with WIDE.

There are different opinions on "good" settings, and there are regional differences too. I believe the settings offered are good for most environments. It doesn't really matter so much if one uses TRACE or WIDE, as long as the total amount of digipeaters isn't very large. 2 is good in areas with good coverage digipeaters and igates, 3 is usually good elsewhere. 5, 6 or 7 is, well, not good.

Holidays, Norwegian, and relaxed callsign rules

I'm back from the Christmas holidays, and looking forward to fixing some bugs and doing a little new development. I spent Christmas in the Åland islands and worked some HF digital modes as OH0/OH7LZB. It was a lot of fun, I've never really felt like being a DX before. Had a sort of a pile-up on 14 MHz RTTY for quite a while!

New year was spent a bit further away... can you recognize the place from these photos? :) It was a lot of fun, a very nice town with very nice people. The hostel was awful, though, and not very cheap either.

Now, let's get back to business:

I installed the new Ham::APRS::FAP version 1.01 on the production server. It relaxes APRS-IS source callsign validation rules so that any alphanumeric 'callsign' (including a variable amount of '-' characters) with a maximum of 9 characters is accepted. Things like OH7AA-A (D-STAR DPRS) and aprsdOEZ will now get in the database, too. Welcome!

There is a new complete translation in Norwegian, thanks to LA4RT, LA9UI, and LA4DNA. The site is now available in 8 languages (counting complete or almost complete translations)!

There have also been significant new contributions to the French, Japanese, Polish, German and Dutch translations. Thanks go to HB3YKO, HB9HFD, JA7UDE, JO2VTM, SQ6NTI, SQ3EYC, HB9TQJ, Dl7JP, DO1GVT, DK7IN, PG1G and PA3BWE.

I'd like to remind everyone doing translations about two little things:

- Remember consistency. Please try to use a single word for a certain feature everywhere. For example, always use your preferred translation of Options when referring to the Options pop-up window. Please avoid using a mix of Options, Preferences and Selections. It's OK if your preferred translation actually is closer to Preferences, just use the same word everywhere. :)

- If you're uncertain about a translation for a term, please double-check (use Wikipedia or something). For example, Course, Heading and Bearing are all different things and have different translations, which are easy to mix.

After saying that, I'd like to repeat my thanks to everyone involved in the translation project. The translations seem to be of good quality, and they do make the site more accessible. I'll improve the translation tool in the future, and add more strings (the Options window and help texts should appear soon).

Happy new year, everyone!