I have been using Flight Track Release 1.3 for a couple of months evaluating the features described in my last post on this topic, one addition feature, and smaller changes to improve code management.
Automatic Packet Detection and Other Updates
In addition to many APRS data types, I added detection and parsing for Mic-E. Soon after adding this feature, I found a few parsing errors. Most recently, I discovered another. When I saw 921 MPH for the balloon speed, I investigated and found that an IF statement was checking for a value “greater than” rather than “greater than or equal”. This small adjustment corrected the error. I also wondered why the packet validation code ignored such a high speed. I discovered Flight Track never validated the first packet it receives. Now it does.
I’ve never been real happy with the performance of MapPoint when it renders the predicted flight path in real time. I started investigating the use of multi-threaded code to isolate drawing the path from monitoring packets. This had some bizarre results probably due to re-entrant issues. I’ve crafted a design to address this but it requires a bit more time and testing. I expect to pursue it over the winter.
With the diversity of APRS data types, evaluations of the automated packet detection are challenging. While the code is exercised every time I follow a flight, I wanted some basic confidence of the feature while reviewing some diversity in the data. I added NUnit to my project and created many tests to review both the data type detection and parsing. This has been very beneficial especially as I discovered errors. I was able to create a test quickly to check it, and verify that all others were still operating as designed.
I have seen a few flights where the balloon ascends and suddenly I receive an out-of-sequence packet (sometimes a duplicate and ignored), or a packet where the altitude is in error. I’m investigating methods of both detecting and correcting for this. I’m open to ideas.
An Additional Feature
I recently added a feature to display the predicted flight path based on wind data. I’ve always wanted to visually compare the predicted flight path to the actual flight path – this provides that comparison. As shown below for a recent flight, the pre-flight predicted path (black), actual path (green), landing zone (cyan), and real-time predicted path (yellow/blue) appear together. Your thoughts?
Flight Track On-Line
I’ve started investigating the use of Google Maps to bring some of the functionality of Flight Track to an on-line application. Look for more details (and possibly a prototype) during the winter!