Those of you that know me very well might remember that one of my hobbies is amateur radio. There are many facets to the ham radio hobby and one of them that I’ve been involved with over the last few years combines radios and GPS data into a real-time position reporting system called Automatic Position Reporting System (APRS). To make a long story short, people equipped to use this system have specialized radios in their vehicles that read positional data from GPS units and transmit it out over certain frequencies periodically. Usually, these information packets eventually find their way to a series of servers that forward the data to connected clients for display on whatever mapping system the client has available locally.

This weekend, I spent some time creating an Adobe AIR application written in HTML and Javascript that connects to one of these servers and plots the position reports on a Google map. I haven’t had a chance to do much development with AIR up to now so I thought this would be a good exercise to see if I could create a usable solution.

The first hurdle was to create some method of translating the raw packet of information (which is a variable length string of text) into its component parts that I could then use. Below is an example of an APRS position report packet.

KI4TDG-9>APT407,WIDE1-1,WIDE2-2,qAR,N5AAA-1:!3546.23N/08654.00W>069/000/A=000800

This looks like a bunch of gibberish I know, but the data formats (there are multiple different types of packets that can be transmitted over the APRS system) are well documented. I wound up creating a Javascript object called APRSPacketParser.js (original name I know, but it works) that had a method called parse() that accepted a raw APRS packet like the one above. This method then used other methods such as extractCall(), extractTimeStamp(), extractPosition() and so on to reduce the raw string into a series of values that I stored in another Javascript object called APRSPositionReport.js. That took about 3 hours or so to write up. Because of the many different types of packet formats, the parser object still needs a lot of work, but for now it works on the 3 most common forms of position reports.

Once that was complete and tested, I created a regular HTML page to get my head around integrating with the Google maps javascript API. Within no time, I was able to have a Google map in my HTML page, centered on my location with a custom zoom level set. Once the map was there, I began experimenting with parsing sample packets I had hard-coded into the page and using the location data stored in the resulting APRSPositionReport object to insert markers on the Google map. So far so good and my total time so far was less than 4 hours worth of work. At this point I decided to quit for the night and try to tackle the AIR bits the next day.

Up to this point, all I’d really accomplished was proving that I could follow the instructions for using the Google maps API and that I could parse some sample packets into position reports. I still had to make all that work inside AIR. Upon creating a new AIR project, I put the HTML and javascript code that I’d been working on into the project and ran it, expecting to see a Google map pop up. Nope! All I got was a blank screen and a message saying that the variable “google” was undefined.

After a couple hours of head scratching and research, I found out about AIR security sandboxes and found some example code on how to successfully use assets in your AIR application that are not part of the project itself. The examples showed how to use the ParentSandboxBridge and ChildSandboxBridge objects to essentially create an “API” between pages to allow data to be shared between two sandboxes with different security levels. At this point, I had my empty Google map displaying inside my AIR application. With a little bit of bug fixing, the javascript code that I had used to create the markers on the map was working and I had 4 sample APRS packets parsed and plotted on the Google map. Total time to this point was somewhere around 7 hours.

Obviously, to be useful, the hard-coded position reports had to go and be replaced with a real-time stream of data from one of the APRS servers. This part was probably the easiest thing I did all weekend. The socket class in AIR makes it absolutely simple to create a TCP socket connection to a server. To create a socket object, I used the following code. The first line creates the object and the remaining lines assign methods to listen to various events that happen with the socket connection.

//Set up socket object that we'll use later when the connect/disconnect 
//buttons are clicked
socket = new air.Socket();
socket.addEventListener(air.Event.CLOSE, closeHandler);
socket.addEventListener(air.Event.CONNECT, connectHandler);
socket.addEventListener(air.IOErrorEvent.IO_ERROR, ioErrorHandler);
socket.addEventListener(air.SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
socket.addEventListener(air.ProgressEvent.SOCKET_DATA, socketDataHandler);

I then created a button labeled “Connect” and set the onClick action to run the javascript method named connect(). The code for that method looked like this:

function connect(){
  if (socket.connected == false) {
    socket.connect("second.aprs.net", 20157);
    writeln("user NOCALL pass -1 vers AirPRS 0.01 filter r/35.625/-86.9847/150");
  }			
}

In my case I needed to connect to the server named “second.aprs.net” on port 20157. The last line of that method uses the writeln() method to send a string of configuration data to the server over the socket connection telling it about the kind of data I want it to send me. The server sends a new line of data across the socket connection each time it receives a position report from an amateur station. At this point, all I had to do was fill in the body of the socketDataHandler() listener method to forward each packet to another method I created that uses the parser to parse the incoming string and dispatch a message to the map to create a marker with the information contained in the APRSPositionReport javascript object created from the raw packet. Total time to this point was about 9 hours.

I spent another 3 or 4 hours adding error trapping and a “console” area to the application that got updated each time a new packet came in from the server so that I could see data flowing into the application.

All in all, I had around 12 hours or so of actual development time in creating a functional, though not very feature rich, application based on the Adobe AIR platform. If you care to take a look at what I’ve done or run the application, I’ve made the application and the source code available for download.

Here’s a screenshot of what the application looks like after it’s been running for a bit to pull in some position reports (click on the image for the full-sized view).

I already have a list of things that I want to add to this such as a preferences pane so that you can set your own center map point, control the radius around the center that you want reports for and so on. I want to use the built-in SQLite functions to store those values which will provide me with another learning opportunity with a different feature of AIR.

In the past, the ARRL has provided us with a Windows-based program to generate exams from the question pool. The program worked well, but each time there were any changes to the question pools (which happens on the 1st of July in 3 out of 5 years), they had to create a new Windows installer package to disseminate to all the VE team leaders. That in of itself was a pain enough, but for those of us who are Mac and/or Linux folks it became a real hassle.

In today’s newsletter to VEs, I noticed that the ARRL had announced a new version of the exam generations software. When I went to download it, I was pleasantly surprised to find an AIR badge to install the program. It’s an HTML-based AIR application but a lot of thought was put into how it functions. It takes advantage of AIR’s built-in database to synchronize its question pools and answer templates with the latest approved versions as well as periodically checks to see if there are any updates to the program itself–all the things that we love about AIR. Oh, and since it’s an AIR app, it obviously runs natively on my Mac!

I’ve been kind of critical of the ARRL in the past in regard to the applications that they offer for use (some are pretty bad). This one however, really fits the bill for what those of us responsible for printing exams need to do on a regular basis. Hopefully, this will be the first of many applications that they develop on the AIR platform.

There’s something pretty special about building a radio from a pile of parts and stringing a couple hundred feet of wire out through some trees and being able to carry on a conversation with people half way across the country or half way around the world. Even though today the vast majority of radios are commercially built and there are as many antenna designs as stars in the sky it seems, the magic of being able to fire up that radio, tune through the frequencies and have the possibility of talking to another ham in a country you’ve never heard before is pretty special.

There are many “sub-hobbies” to ham radio these days–morse code, computer generated digital modes, satellite operation, GPS-enabled radios and more. One of my favorites is referred to as “contesting”. On several weekends throughout the year, hams from all over the world set aside anywhere from 1 to sometimes 48 full hours to devote their energies to trying to see just how many people in different states, countries, continents etc they can talk to and exchange some small bit of information within the allotted time frame.

Today there is a contest called the North American QSO Party (QSO is short for a contact or conversation). Today’s version is a voice contest only. Two weeks ago a friend and I made a combined effort in the morse code version of this particular contest and absolutely had a blast. We didn’t work the entire 12 hours that this contest covers, but only put in about 6.5 hours. In that time, we made 178 contacts in 34 different states and 3 Canadian provinces. By comparison, most of the top echelon morse code contesters can make 100 contacts per hour.

So, if you’re reading this, I’ll be offline from the “inter-tubes” and online riding the airwaves from about 1:00pm CT for maybe as much as 12 hours (depends on how my derriere holds up sitting in that chair that long).

73 (that’s short for talk to you again soon)
Dan – Amateur radio station N4EA