The Change Experience

I recently purchased a new laptop and with that is a set up effort.  I installed Firefox, BeyondCompare, and other applications and utilities I collected over the five years since my last new laptop.  These were the easy ones.  One of the more challenging and educational was setting up Visual Studio so I could continue to work on Flight Track.

The Legacy of Old Tools
I have been using Visual Studio 2008 Standard for a long time.  I still had the disk but the box indicated it was an upgrade.  I recall at the time that you could download Visual Studio Express for nothing.  I had done that but found it would not support add-in development (Flight Track is a MapPoint add-in).  If I wanted to install Visual Studio 2008 Standard, I’d have to find Visual Studio Express.

I found it in a Downloads folder on the hard drive I used two laptops ago.  What a lucky find I thought!  I installed it, upgraded it, and even installed SP1.  I transferred all of my projects and was working within a week’s time.  As I told the story of my fortune to others, I thought I should upgrade.  What are the chances of finding all the things I need?  What if the tools are no longer compatible?  A quick look for Visual Studio 2010 on eBay told me I would not be upgrading soon.  What if I never upgraded?

That question, and possibly the bright colors of autumn, had me asking what I should do with Flight Track.  I enjoy working on it and using it.  There are a few other users for it.  But, the thought of my tools growing old or unusable helped me to realize a change should be considered.

I think the ability to forecast a flight path and landing site in real time is valuable.  I understood MapPoint was a barrier to use Flight Track and experimented with Google Maps during the summer.  When I investigated methods of hosting an on-line version of Flight Track, the fact that I made calls to the APRS-IS servers would force the use of a dedicated server.  Together, these events had me considering alternative development solutions.

The Eclipse Experiment
One of my first considerations was an ability to work across multiple platforms.  This led me to Java.  I briefly explored both NetBeans and Eclipse.  I found Eclipse was a little closer to my experience in IDEs and started experimenting with it.

My primary requirements are:

  • Ability to embed a browser for hosting Google maps
  • Ability to communicate with radios or a GPS through a serial port
  • Ability to communicate with APRS-IS through the internet

I have others but these were the most important.  I started earlier today with this list.  By mid-afternoon, I had proven all of these were possible.

The Winter Project
I am looking forward to the challenge of porting the Flight Track functionality from .Net to Java.  I’ll also take the opportunity to re-factor, re-consider, and re-design.  Watch here for updates!

Flight Track Tracking Testing

Flight Track provides payload tracking functionality to assist with recovery, to inform the user of recent status, and to make a record of the flight.  Presently, Flight Track accepts packet data from both radios (TNC delivering APRS packets), or the APRS-IS database directly.  The similarity of these two functions made for an easy design choice in polymorphism.  Recently, I added another class specifically designed to evaluate the tracking functionality.

Introduction to the ICommuinicationSource Interface
The ICommunicationSource inteface describes all of the functions required for moving data from a source (a radio or the APRS-IS database) into Flight Track.  These include opening and closing the communication source as well as events to notify subscribers of new data.  Both the SerialPortCommSource and ServerCommSource classes implement the ICommunicationSource interface.  In this manner, the tracking functionality receives packet data but does not know it receives.  The benefit is the tracking functionality and subsequent processing does not have to change based on the source of the data.

The Newest Class
I have wondered how to evaluate the tracking functionality without having to wait for a Saturday morning.  Last week, it occurred to me that I could use the ICommunicationSource to provide packets from a file (much like the Review functionality).  I created the FileCommSource class for this purpose.

This class reads one line of packet data from the file, submits it to the Tracking functionality, and waits a specific amount of time before repeating this process.  I made some specific timing enhancements to accommodate those packet formats that do not contain a time stamp.

With this class, I can review changes to the Tracking functionality at any time.  Additionally, I can experiment in solving data sequence errors that sometimes occur with packet data.  One specific problem is the arrival of a packet with a lower altitude than the previous.  Many times this can indicate the start of the descent.  Occasionally, the packet transmission was delayed and arrived out of sequence during ascent.  Most notably, the aforementioned packet format without a time stamp will have Flight Track enter a “descent phase” prematurely.  With this new class, I look forward to experimenting with resolutions to this error.



New Payload Antenna

The new antennas arrived and I experimented with the payload antenna.  The base antenna, a Yagi antenna, requires a bit more set up so I haven’t tried it.

I discovered with this experimenting that the radio signal from the DNT900 may interfere with GPS signals.  The board was flat and the radio antenna was vertical.  I received no GPS data.  When I hung the prototype from the top of a ladder (as shown below), I started receiving GPS data after five minutes.


Arduino Development and Flight Track 1.3 Update

Arduino Development
With the data transmission made a little more reliable, I want to try some short distance tests (up to 100 ft).  I set up a test in my front yard and powered the base and remote systems.  I started receiving battery and temperature data, and GPS after a bit.  This is normal while the GPS collects satellite data for a fix.

Suddenly, the base was not receiving GPS data.  I went over to the remote and the GPS module indicated a lock (a flashing LED).  The following night, I had the same set up.  I started receiving GPS data and noted an odd difference in the displayed time.  After a few minutes, the base stopped receiving GPS data.  With a clue about the time, I reviewed the Arduino code.

The code is designed to send GPS data when the time stamp is different between two sets of GPS data.  As it happened, I was crossing midnight during my experiment and that may have been an issue.  I also discovered that I had a data type mismatch between the variables used to evaluate the difference in GPS time.  After I made the variables the same data type, the base received data consistently and through a midnight.

Lastly, I was able to receive GPS data from 100 ft and farther.  I have been using short rubber ducks for this experimenting.  I ordered better antennas for the next phase.

Flight Track 1.3
I’ve tracked six or seven flights in the past weeks, and collected information on landing site predictions.  After the burst, Flight Track predicts a landing site within an average of three miles of the actual landing site.  This means recovery teams have about a half hour to travel to a target landing site.

Flight Track requires wind data (usually from NOAA READY) to make real time predictions however I realized (from some of my designs for Flight Track On Line) that after the burst, Flight Track uses only the wind data gathered during ascent.  With this, I altered Flight Track to produce a landing site prediction even when READY data is not available.  Expect to see this in Release 1.3!

Lastly, I have prototyped parts of Flight Track On Line and discovered that the parsing of APRS-IS data may skip some packets in Flight Track.  This will be corrected in Release 1.3.

Flight Track Release 1.3 Testing – My Flight Simulator

I use Flight Track to follow a flight as often as I can – at least once per week.  While real-time tracking provides a good exercise of the code, sometimes I’m not able to follow the flight.  In that case, I set it up in Flight Track for a flight I want to follow, and run some predictions.  Soon after the flight concludes, I retrieve the packets from and simulate the flight.


I place the packets into a file and load the file into the simulator.  To simulate the packets arriving from a radio, I send packets from a COM port on my desktop computer to my laptop where Flight Track runs.  I select a time interval between packets (1, 2, 10, 30, or 60 seconds – I can also select a custom interval).  When I click on play (the button labeled ‘>’ at the upper left), the packets are delivered to Flight Track in Track mode.

I used the simulator over the weekend for a flight using Mic-E.  I recently added Mic-E parsing and want to verify it operates correctly.  The ascent rate during the flight was incorrect (in excess of 4000 ft/min) so I investigated.

When I set up the simulation, I selected a 10 second interval.  Since Mic-E does not contain a time stamp, Flight Track assigns a time stamp internally. When it went to calculate an ascent rate, Flight Track divided the difference in altitude by the difference in time.  The result was around 4000 ft/min because the actual time between two packets was about two minutes and Flight Track used the interval I selected: 10 seconds.  I modified the Flight Simulator to use time stamps that I add to the log file, and deliver the packets based on the difference between the time stamps.  This modification provided the correct ascent rate.

A Minor Omission
When I add new functionality, I start with the Flight Review code and verify its operation before copying it to the Flight Track code.  While the code for both Flight Review and Flight Track are as similar as possible, I occasionally find something I put in one and not the other.  For example, I discovered that the Flight Track code did not place a push pin at the burst coordinates.

The Flight Simulator provides the opportunity to review flights when I can, and verify code changes have been made.  It speeds my work along so when Saturday arrives, I can enjoy the flight and deliver a good product.

Update on Flight Track Release 1.3

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!

Arduino Development Journal/May 2014

My present design for a new flight computer uses an Arduino Pro Mega as a platform to telemeter GPS, power, and temperature data.  The integration is successful but I am seeing some odd things.

While I was successful in transmitting GPS, battery, and temperature data using the platform described in my previous post, I noticed odd behaviors in the transmission.  Sometimes the transmission would stop for a few seconds, or the GPS data would be incorrect.  Recently, when I wanted to evaluate the flight computer, the GPS data simply was not sent.  Being of an agile mindset, I took a retrospective look at what I had done, and thought I would start again.
I pared down the existing Arduino code to just that supporting the GPS.  Once I had it working again, I instrumented the code to help understand where time was spent, and to verify some of the set up.  I also placed some code in the Arduino to write information to an LCD display.

I found that the GPS was sending one extra sentence that is discarded by TinyGPS (a very cool library – check it out at  I corrected that and believe the GPS delivers the optimum number of sentences at 19200 baud to the Arduino.

The Arduino accepts and parses these sentences, and prepares the data for transmission.  While this is running, I am counting the number of times the loop() method executes, and write that number on the LCD display only when the GPS data has decoded (I reset the counter when the GPS data is transmitted).  I see a high number and a low number which leads me to believe the same data may be transmitted twice.  If that is true, the program may be overrunning the radio’s buffer.  This could account for the odd errors.

To test this theory, I change the program to transmit the GPS data only when the current GPS time is different from the GPS time most recently transmitted.  This was successful.  I related this experience to the TinyGPS developer.  He clarified the operation of a method I was using; I was sending the same data twice.

I look forward to moving this improvement into the main program and review the operations again.  Stay tuned!