It all came together Saturday morning! Just as balloon teams around the continent were preparing for their flights, I was deploying code, updating code, and making final adjustments to track a flight with Flight Track On Line.

I followed a total of three call signs evaluating all components of Flight Track On Line – three on the same map!  This is something I always wanted for the Flight Track add-in but I found the MapPoint API made it challenging to support.  I started with VE5AA-11 from SABRE-22.  After monitoring it a few minutes, I added VE5AA-12 from the same flight (possibly the same payload).

The screen shot below shows both paths.  It also shows that I have to investigate why the path color is black instead of my design choice of green.  I was fortunate to follow the flight long enough that a third launched in Illinois (KD9AUK-11).  I had to zoom in and out to review the presentation of both flights but was happy to follow three call signs.

Behind the Scenes
The testing came to an end when the parse of packet data failed.  I prefer to find errors like this when testing.  It uncovered a deeper issue with some of the information transfer between the program capturing the APRS-IS feed and the web service.

Other interesting errors included primary key duplication, a need to centralize my database management code, and some unneeded parsing.

Next Steps
I started correcting these errors and improving the code.  You might notice the lack of any flight information in the screen shot.  I miss it also – I want to display packet data and rates just as the Flight Track Add-in does.  But I want to be sure the core functionality is solid first.

I’ll be doing more testing on my local machine (a .NET web site interacting with a Java web service processing data to MySQL driven by a flight simulator all on one machine – I love this project) over the next week.