New version of aprs.fi's APRS packet parser released: Ham::APRS::FAP v1.21

Yesterday I uploaded a new version of the APRS packet parser used by aprs.fi, Ham::APRS::FAP, to the CPAN. It's open source, so if you're a little bit weird like me and enjoy programming in Perl, this might be useful. Here's a full list of changes:

• Improve make_position() to support HMS UTC timestamp. make_position() now returns the packet type character so that it can signal the presence of a timestamp.
• Improve make_position() to support comment string, !DAO! extension, altitude encoding. Fix rounding errors in lat/lon/speed. Support generating packets with no speed or course. Take optional parameters in a hash parameter. Implement unit tests for make_position().
• Set up Travis automatic running of the (existing) unit test runs.
• Additional character escaping in regular expressions to deal with deprecated functionality in Perl 5.22.

The packet parser is one of the more complete APRS decoders, although I'm not sure if any of the parsers deal with all of the APRS features and packet variants yet.

New symbol graphics and better support for mobile devices

Old symbols, scaled up, pixels obvious

[updated 2015-11-03: the set is now available on github.]

I've just upgraded aprs.fi to use my new APRS symbol graphics set. The new symbols are drawn in vector format (as opposed to a raster format at a fixed resolution), allowing them to be rendered at larger and smaller sizes without distortion or blurriness. The new symbols are slightly larger than the old ones, making them easier to recognise on modern displays having smaller pixels than the old ones. They're also available in double resolution so that they're properly sharp on the 4K/retina displays found on many modern tablets, phones and computers!

New symbols, scaled up - no pixelation!

One downside is that they are just a little bit bigger than the old ones, taking up more space on the screen. On the other hand, the old ones were a bit too small on modern displays, and the very small resolution did make it hard to understand what the symbol tried to mimic.

The new aprs.fi symbol set is available as open source on GitHub, in both vector (Adobe Illustrator/PDF) and raster (PNG) formats. Other APRS applications may then use them, too, at no cost. Raster renderings are available in 24x24, 48x48, 64x64 and 128x128 pixel resolutions - drawing from raster sprites in apps is usually quicker and easier than working with the vector source material. Having the vector sources makes it possible to improve them and and replace individual symbols easily. If you need to render other resolutions or make some other fine tuning, you can run Illustrator for free for 30 days. The symbol set release even comes with a little piece of javascript which crunches out the 3 PNG files (primary, secondary, overlay characters) at the 4 resolutions in a few seconds.

Naturally I did not draw all of the symbols myself. Many are loosely or strongly based on the original symbol graphics, primarily to keep the familiar and consistent look. Some symbols I obtained from other sources, such as Wikipedia. In those cases I picked SVG versions which allow commercial reuse (source known, and the work is placed on public domain, or with a CC license which allows adaptation and commercial reuse). In any case, the source and copyright information is documented separately for each symbol.

The aprs.fi symbol graphics set does not contain additional symbols for overlays yet, mostly because it takes lots and lots of time to draw them, and the effort it took to create this set was pretty high already. Maybe later!

There is one obvious difference in the new symbol set: the "ham store" symbol has been replaced with a more generic "store" shopping cart, reflecting the current \h symbol definition in the master index. Please use the 'H' overlay character to specify an amateur radio shop.

To complement the symbol graphics, I've previously published a machine-readable (CSV/JSON/XML/YAML) APRS symbol description index, which is easier to integrate in applications than Bob's master list.

Improved mobile device support

aprs.fi will now work better than before on mobile devices. I fixed the signup/login flow and most of the text and data table views to scale more nicely on small devices, allowing  horizontal scrolling of tables. It'll need some more work to make it very nice, but this is a good start.

Device identification database updated, available for other apps

Most APRS devices and applications transmit an unique AX.25 destination callsign in all their packets, so that receiving stations can figure out which application or device is transmitting each packet. Bob Bruninga maintains a tocalls.txt index file, which lists all the assigned destination callsigns.

Those devices which use the Mic-E encoding to transmit position packets encode the latitude and a little bit of the longitude within the destination callsign, in which case something else has to be done for device identification. Mic-E device IDs are encoded around the comment text, with one character in the beginning of the comment text and zero to two characters in the end of the comment. The Mic-E type codes are indexed in mic-e-types.txt.

Now, when an application such as aprs.fi wishes to automatically decode the destination callsigns and type codes to readable application names, as seen on the aprs.fi station information page, the author of that application needs to collect all the device identifiers from those two files, and somehow convert them to application source code, or a configuration file that can be read by the application. The master files are written with human interpretation in mind, and it's rather hard to make an application automatically parse out the identifiers from them. It needs to be done manually, and whenever new devices or applications are published, all the applications wishing to detect the new ones need to get an update. All softwares authors need to get notified that there are some new devices, and then somehow add the devices in their respective configs. That's quite a lot of extra work that would be better spent writing some fancy new features instead.

OH7LZB-7, correctly identified as a Kenwood TH-D72,
at Mikkeli International yesterday afternoon.
Aircraft and training provided by MIK at Helsinki-Malmi.

For aprs.fi, I initially made a Perl module, Ham::APRS::DeviceID, and published it as open source, so that other software authors could use the index too, and skip the manual labour-intensive part of parsing the master text files. For some obscure reasons a number of programmers have chosen to use other programming languages than Perl, and the module was of limited usefulness for them.

To improve the situation, I converted the device index in YAML (Yet Another Markup Language), which is easy to read and edit by humans, and also easy to read and edit by computer programs. I also wrote a little converter program which parses the tocalls.yaml file and outputs the same data in JSON and XML formats, which are popular file formats for passing data between computer systems.

I then updated the original Perl module to read the YAML file, and removed the old database that was embedded in the code. DeviceID.pm 2.00 and later use tocalls.yaml. I also updated aprs.fi to use the new version of the Perl module, and tocalls.yaml. The update brought a number of new devices to aprs.fi, including the newer Yaesu radios.

Other programmers who wish to do device identification are welcome to download the YAML, JSON or XML files and use those. It should be straightforward to automatically update the device index during an application build, or even automatically update the index directly in the application.

New devices should still be first added to Bob's files, and only then to tocalls.yaml. If you have a new device which has already been added to Bob's index, please make a pull request or an issue ticket to update tocalls.yaml accordingly.

Mic-E mangled packet parsing improvements

One of my APRS transmitters
using the Mic-E packet format.
Fresh photo for the blog.

Mic-E encoded packets, as commonly transmitted by Kenwood & Yaesu radios, Byonics trackers and others, are often corrupted by broken APRS igates. The speed/course bytes in these packets,  which often have binary values in the 0x1C - 0x1F range (unprintable control codes in the ASCII table), or the 0x7F DEL "character", are commonly removed or replaced with spaces (0x20, space bar) by certain iGate setups.

Mangling packets in transit is wrong, and by default it would make these position packets, which are completely valid according the protocol specification, fail to decode, and fail to plot on aprs.fi. To get around this aprs.fi and many other decoders try to detect these broken packets and extract whatever information is left in them after the broken igate.

Yesterday evening I fixed a few bugs in the Mic-E packet decoder used by aprs.fi. This improves the handling of mangled packets a bit further.

• The correct symbol table identifier (primary or secondary) is now successfully decoded from mangled Mic-E packets. The table identifier byte was incorrectly extracted before the demangling trick - from the wrong offset due to the mangling. Thanks to KD0KZE for the bug report.
• Speed and course information is no longer decoded from Mic-E packet if demangling was applied. That information has been lost in transit when the packet got mangled by the igate.
• Mangled Mic-E packets are now indicated with a mice_mangled flag in the decoded raw packets. Switch from Normal to Decoded mode in the raw packets list to see it in action. Expect to see broken igates highlighted on aprs.fi later on.

Today I released version 1.20 of the open source APRS packet parser, which contains the above improvements. There are a few other fixes in there, which were already installed on aprs.fi earlier last year.

Parser updates and new delayed packet filtering feature

I've updated the APRS device identification module Ham::APRS::DeviceID to include detections for new APRS devices (KissOZ, anyfrog, unknown mic-e, SARTrack, Altus Metrum, SM2APRS, aprsc, NW Digital Radio UDR56K). The new version, 1.06, has been published on CPAN for your open source pleasure, and installed on aprs.fi.

I also published version 1.19 of the Ham::APRS::FAP packet parser used by aprs.fi. It only includes a small fix to the binary value telemetry bit order in Base91 comment telemetry. But at least that keeps me in the regular 1 release per year schedule! Just in time!

The larger feature in the aprs.fi upgrade is that it now utilizes the sequence number present in Base91 comment telemetry for detecting delayed packets.

APRS packets notably lack any sort of sequence number that could be used to detect old duplicate packets arriving late, or to place them in the correct order. Newer Byonics trackers can transmit telemetry (battery voltage, temperature, etc) within position packets using the new Base91 comment telemetry format, which is quite tightly packed, and also includes a sequence number in a range of 0...8280. This makes it really easy to detect a packet having an older sequence number than the previously received packet. There are already a lot of those devices in use.

aprs.fi has now been updated to make use of the sequence number when available. It's more reliable and faster than the old methods of detecting too high speed or duplicate packet content. Due to the amount of broken igates and digipeaters delaying packets for minutes or tens of minutes (often due to a buggy Kantronics KPC3+ in KISS mode) it can make sense for a tracker to transmit the sequence number alone without any actual telemetry! Packets dropped due to this will be shown with this error message:

Delayed or out-of-order packet (sequence number)

In practice it will usually be shown together with the error message about dropped telemetry, since the telemetry content is also ignored due to the duplicate sequence number: 

2012-12-31 00:24:51 EET: N0CALL-9>SY0UWY,WIDE1-1,WIDE2*,qAR,N00CALL:
`pOnqgd>/'"KQ}MT-RTG|!D&='a|!w;a!|3
[Duplicate telemetry sequence, Delayed or out-of-order packet (sequence number)]

You can use the Decoded mode of the raw packets view to see sequence numbers and telemetry values decoded from each packet.

Power meter monitoring using Munin & an Arduino

It's been a bit quiet on the blog lately, but that's just because I've been a bit busy with both aprs.fi and other related projects. I've been writing the new aprsc APRS-IS server software together with OH2MQK, went to DCC 2012 in Atlanta to do presentations about both aprsc and aprs.fi, aprsc has been deployed to about 30% of APRS-IS servers and I've had to fix some bugs too. I'll tell you more about those things later – this blog post is about one of the "other projects", a one-nighter to monitor the electric power consumption of your home using an Arduino, a phototransistor, and Munin. I have to admit it took another day to package and document it for you, and write this blog post, and that it can take another night to adjust the physical installation of the sensors.

The Arduino C code, the two Perl scripts used on the Linux box to get the numbers to Munin, and a README text file with more instructions is available on Github. Click on the ZIP button to download it all.

Here's an example diagram drawn by Munin, with annotations for some events we triggered. Munin might not be the best way to collect and report measurements like this, but it's certainly one of the easiest methods to get data graphed on the web using a Linux box. apt-get install munin munin-node and you're ready to go!

The local power company remotely measures power usage in 1-hour steps (using a GSM/3G connection), lets me view that data on their web site (after logging in, of course), and advertises that as being "very accurate" and "high resolution". I don't think it's much to brag about! Munin polls every 5 minutes which makes it really easy to see how much each device or action consumed energy.

Most modern power meters installed by the utility companies have a red LED which blinks according to the power consumption. The meters installed in our small apartment building blink 1000 times per kWh (kilowatthour) – it reads "1000 imp/kWh" next to the led.

To count the blinks you'll need a photodiode or phototransistor. I used an Osram SFH 300 sold by the local electronics store (Partco). It's sensitive to visible light (not just infrared, like some models).

I'm measuring consumption of 4 apartments (with the consent and for the benefit of my neighbors) and the building's consumption (heating system, outdoor & basement lights, etc), so I attached 5 phototransistors.

I used an Arduino Duemilanove, but it's current replacement model Arduino Uno or just about any other model will work just fine.

The Atmel microcontroller has internal pull-up resistors, so the phototransistors can be connected directly to the board without any other components. The Uno board costs about 20€ or $25 USD, has USB and a good set of analog and digital I/O pins. It's powered by USB – no wall wart required.

It's very easy to program in C using the Arduino IDE, which comes with plenty of simple example code. If you're a programmer with no electronics experience, or an electronics guy with no programming experience, or something in between, you'll love the Arduino.

Here's the box attached to the wall using 3M Dual Lock tape.

Since we measure the blinks using optical coupling – there is no electrical connection between the meter and the photodiodes – installing the instrumentation is completely safe and legal. It's about as safe as taking photos of the meter, which is very safe indeed.

With the small bias voltage given by Arduino's internal pull-ups, the photodiodes are a bit insensitive, so they need to be aligned very closely and sharply at the blinking red led of the meter.

Remember that it might not be wise to publish real-time measurement data on the Internet, since everyone could see when you're home. But that applies to APRS on your car, too.

My meter actually has two blinking leds. The one on the left is for kiloVoltAmpsReactivehours (kvarh), which indicates phase-lagged power consumed by an inductive load. My power company isn't yet charging me for that separately, so I'm not measuring it.

Upgrade: New server, Dead Reckoning, and some smaller stuff

One of aprs.fi's servers getting new disks

First I'd like to thank everyone who showed up in Ham Radio 2012, Friedrichshafen! It was really nice to meet you all.

aprs.fi's second server migration reached completion today. It's now running on two blade servers, each having two quad-core Xeon processors with 12MB cache each, for a total of 8 CPU cores at 3 GHz and 32G of RAM per server. That's a total of 16 CPU cores and 64G of RAM for aprs.fi alone! The memory really helps, as I can now fit more and more stuff in memory and avoid slow hard disk seeks. We found the blade server in a dumpster, so it's not the latest and greatest in the market, but certainly useful for a few more years.

I also upgraded the aprs.fi server software with a few visible changes and several important features which are not directly visible to the end users.

The most visible change is that Dead Reckoning was enabled for all stations which have moved recently. If the station has moved within the past 30 minutes, a blue line will be displayed, indicating where the station would be right now, assuming it has continued on the same course and speed.

For stations which transmit quite often in relation to their speed, or do not turn quickly (ships, airplanes and high-altitude balloons, for example), the DR'ed position will be surprisingly accurate. For cars driving a very curved road (in the city) it will be less accurate, but the DR line still provides an indication on the relative age, speed and usefulness of the displayed position. Your internal non-artificial algorithm can easily figure that the car probably turned along the road, even if the blue line ends in a forest.

The blue line becomes gradually more translucent during the first 10 minutes after the reception of the position report. If it's almost completely translucent, the position is more than 10 minutes old and both the DR'ed position and the displayed old position are pretty outdated. This information can be very useful, too.

It can take a small while until everyone gets used to the DR lines. After having them for a couple months on my development server I can assure you that they really improve the usefulness of the real-time map view!

Ham::APRS::DeviceID module was upgraded to version 1.05, adding detection for a number of new APRS devices: TrackPoint, BPQ32, ircDDB Gateway, DIXPRS, dsDIGI, dsTracker, DireWolf, MiniGate, YAAC, and MotoTRBO. New version of the module will appear on the CPAN soon.


Fixed calendar date selection in the data export tool.


Implemented a nice user and team management web UI (for administrator use only). Especially useful when running the software in a closed "intranet" mode.


Gave a face lift for the service management command line tools.


Web server software was upgraded (as usual).


I've also implemented TETRA LIP position packet decoding and support for Google Maps Enterprise licensing. More on that later!

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

Ham::APRS::DeviceID published

The Ham::APRS::DeviceID module, written by myself and used by aprs.fi, has been uploaded to the CPAN. The perl module makes a fierce attempt to detect the make and model of the APRS device which has transmitted an APRS packet.

The detection is based on the APRS destination callsigns listed at http://aprs.org/aprs11/tocalls.txt and mic-e type codes documented at http://www.aprs.org/aprs12/mic-e-types.txt. If you wish to have your APRS software or tracker device detected by this module (and aprs.fi), please get in touch with Bob Bruninga to have it added in the relevant lists, and after that, please notify me that they've been updated. Thanks.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

IPv6 support in APRS packet parser - FAP version 1.17

Version 1.17 of the Ham::APRS::FAP APRS packet parser has been released and uploaded to the CPAN. It should appear at the mirrors during the next 24 hours or so. The main feature is IPv6 support in APRS packet path parsing.

What?!? IPv6 support in APRS?

aprsd, and sometimes other software too, sends position packets to the APRS-IS using the qAI Q construct. qAI triggers packet path tracing in the APRS-IS. Each APRS-IS server inserts the hexadecimal source IP address of the previous server to the packet. Now that quite a few Tier2 APRS-IS servers have IPv6 connectivity, even some T2 hubs, IPv6 hex addresses can appear, and they are a bit longer than regular callsigns, and were getting rejected by the parser.

SRCCALL>DSTCALL,qAI,IQ3VQ,THIRD,92E5A2B6,T2HUB1,200106F8020204020000000000000002,T2FINLAND

In this case 92E5A2B6 is the IP address of THIRD, and 200106F8020204020000000000000002 (2001:6f8:202:402::2 in normal IPv6 printed representation) is the IP address of T2HUB1 (T2FINLAND happened to be connected to T2HUB1 at the time).

Here's the complete list of changes:

• Remove / or ' ' from beginning of comment after parsing away PHG, altitude and other optional data
• Allow hexadecimal IPv6 addresses in APRS-IS paths after Q construct
• Added tests for uncompressed packet altitude (negative, too)
• Fixed destination callsign based symbol selection for 'BC'
• Updated URLs to aprs.org, etc

aprs.fi is also available using IPv6 at ipv6.aprs.fi.

Ham::APRS::FAP 1.16 released

Version 1.16 of the APRS packet parser was uploaded to CPAN last night, and according to the first few CPAN tester reports it seems to be working as expected. Here's a list of changes:

• Added a couple of test cases
• Added an example script to parse a whole file of timestamped APRS-IS packets
• Fixed peet WX packet parsing for Perl 5.8 and older, which don't support n! packing
• Minor speedups by reducing amount of regular expressions, extra variables, reordering things to catch the most common case first, and tightening a loop
• Put '' around hash key strings (style issue)

The main change was the Perl 5.8 wx parsing fix. I couldn't have noticed it without the CPAN testers and the unit tests included with the module, since I don't run on 5.8 myself any more.

Ham::APRS::FAP 1.15 released

Version 1.15 of Ham::APRS::FAP, the APRS packet parser module used by aprs.fi, was uploaded to CPAN yesterday evening. It should appear on mirrors today. This update contains all the changes implemented since November 2009.

Like most of you know by now, the parser is released in Open Source terms (GPL or Artistic license, like most of Perl) so that others can freely use it to implement APRS systems. I believe it is the most complete APRS decoder available as open source.

Here's the change log:

1.14 Tue May 4 20:31:33 EEST 2010 - Hessu, OH7LZB

• Fixed humidity parsing, h0 means 100%
• Fixed peet bros $ULTW packet parsing, integers are signed (not unsigned), negative fahrenheit temperatures are now correctly parsed (and converted to Celsius)
• Parse comment from end of weather reports - if it's short enough treat it as the wx station/software type string
• Parse weather data sent after a compressed position
• Parse snowfall from normal wx packet
• Added test for positionless wx packets
• Added position packet format in hash ('format' => 'compressed')

1.15 Tue May 4 20:44:31 EEST 2010 - Hessu, OH7LZB

• Added a couple of missing tests and 'format' => 'nmea'

Ham::APRS::FAP 1.13 released

Version 1.13 of Ham::APRS::FAP was uploaded to CPAN today. The tests seem to be passing nicely, and the code has been running on aprs.fi for a long while, so the upgrade should be safe.

Ham::APRS::FAP is the APRS packet parser used by aprs.fi. If you wish to decode APRS packets in Perl, this is what you need. It's pretty fast, it's stable, and it can report it's errors in a developer-friendly way. And it's free (as in free speech).

Version 1.13 contains the following small fixes:

• Allow anyone to update telemetry parameters, skip the source callsign check
• Allow a PHG of 0000 for deleting PHG
• Added new error code sym_inv_table for invalid symbol table char
• Added local time zone parsing to object timestamps
• Fixed comments parsing for last resort !-location packets
• Parse APRS message rejects (negative acknowledgments)

Some of the improvements were implemented by Tapio, OH2KKU, while others were done by myself.

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!

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.

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. :)

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 parser module used by aprs.fi released

Here's a little Christmas present for the programmers out there:

Last night the APRS parser library used by aprs.fi was uploaded to CPAN. It's written in pure Perl, and it's reasonably complete, stable and fast. It's licensed under the same open terms as Perl itself (you pick: Artistic or GPL). It is written by Tapio Sokura, OH2KKU, with some additions by myself (weather packet parsing, machine-readable return messages, unit tests). Without this module, and the time Tapio took to write it in the first place, I wouldn't have gotten this far with aprs.fi. Parsing APRS packets is not easy.

It does miss some features (like telemetry parsing, and a few other smaller things), but I believe it to be the best parser currently published as open source. It validates input packets in a rather strict way and actually tells you what is wrong with each rejected packet. It does not crash when it sees something unexpected or corrupted. It returns numeric data in SI units. It's good enough to parse the APRS-IS feed in real time on any modern computer. It might even run on Windows with Perl (cygwin?) installed.

To install it on an Unix-like system (like Linux) with Perl using CPAN (as root):

root@proge:~#> perl -MCPAN -e shell
... if you're running the CPAN client for the first time, answer the questions, and once you're in the CPAN shell: ...
cpan> install Ham::APRS::FAP

You can also download the Ham::APRS::FAP module and browse it's contents on the CPAN web site. Installation instructions can be found in the README file.

Oh yeah. FAP stands for Finnish APRS Parser (or Fabulous APRS Parser). Ham::APRS::Parser was taken.