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 aprs.fi 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 http://arduiniana.org/libraries/tinygps/).  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!


Flight Computer Development Update

Flight Computer Prototype Component List

  • SparkFun Arduino Mega Pro
  • Falcom GPS
  • RF Monolithics DNT900 Radio
  • SparkFun Power Shield
  • SparkFun 2000mAh LiPo Battery
  • DS18B20 Temperature Sensor

I started using a battery to power the flight computer and radio.  The SparkFun Power Shield and LiPo battery work very well to provide power for both.  I chose the 2000 mAh battery because the radio may transmit up to 1 watt requiring 1.2 amps for a brief instant.  Additionally, I use some of their sample code to read the battery voltage, and transmit it along with the GPS data.

To improve the data throughput performance, I increased the baud rate of the GPS to 19200 from 9600, and similarly for the radio to 19200 from 9600.  I modify the GPS in the flight computer program because it requires a battery to persist a baud rate different from the default.  Also, if the flight computer detects errors from the GPS, I can reset the GPS and baud rate.  Lastly, the GPS presents multiple NMEA sentences by default.  I reduced them to just two that provide relevant information similar to what an APRS packet contains.  This also improved performance a little.

While I was looking forward to planning battery life tests and communication distance tests, I thought I would add temperature sensors.  I added two Maxim DS18B20 sensors.  With the microlan and single pull up, I thought these were easy to install.  Also, there is sample code available in many places which helped me evaluate them quickly.  After some optimizations to the code, I’ll be ready to begin some tests.

User Suggestions in Development for Release 1.3

During the Spring and Summer of last year, I chatted with a few Flight Track users.  We explored how Flight Track operates, how to set up and track flights, and we also traded stories of past flights.  These conversations were a great inspiration and I received many cool suggestions.  I have implemented some of these, and wanted to both thank you for the suggestions and provide a preview of what I plan for Release 1.3.

Drop me a note with your thoughts at chiefsurfer@surfingsatellites.org!

Automatic Packet Format Detection
I reviewed the APRS Protocol (version 1.0.1) and crafted a few regular expressions to recognized commonly used packet formats.  I have used the automatic detection in reviewing past flights successfully.  I expect to follow some flights over the next few months to validate this feature.


This should eliminate the requirement to define a packet format before tracking a flight.

Delete Wind Predictions
In practice, I capture many wind predictions ahead of a launch to get a sense for flight distance and wind changes.  It helps me select a launch site and plan for recovery.  During the flight, Flight Track uses wind data (usually the most recent) to provide real time prediction for flight path and landing site. In reviewing the flight, it will use the same wind data (the most recent).  It makes sense to keep that wind data and to delete the others (I’ve never used them again).


Release 1.3 provides a method for deleting older wind data, and improves the method of selecting wind data for predictions.

Flight Track Hot Key
Occasionally, I adjust the map in MapPoint and switch back to Flight Track by clicking on it or using Alt-Tab.
I had a suggestion to bring back Flight Track using a hot key.  MapPoint is not all that friendly when I attempt to use hot keys but in this case it worked out well.  After MapPoint loads, you will be able to hold down Alt and press T (for Tools), and T (for Flight Track) – that is, Alt T T.  I have been using this exclusively since I implemented it and I really like it.  I have also used it to bring focus back to Flight Track from MapPoint.


Review All Packets
One user suggested a feature to review all the packets Flight Track receives.  This would help verify that packets are being received, AND that their packets get processed.  While this ability has been a part of Flight Track for a few releases, it was hidden (right-click the Bearing and Distance label to switch between all packets and just flight packets).
Release 1.3 features a View menu to select Flight Packets or All Packets.  The same menu also provides for toggling between charts.


Indicate Altitude and Direction
Flight Track displays the position of the payload on MapPoint with its flight designation.  Release 1.3 features both the altitude and direction (A for Ascending, D for Descending) in addition to the flight designation.


The Landing Zone
I am experimenting with an indication of the landing zone on the map.  To create the landing zone, I run a prediction in multiple prediction mode.  I collect the four extremes of the prediction and draw the landing zone (roughly a rectangle).  The Landing Zone displays during tracking or review.


With Respect and Appreciation, Thank You Flight Track Users!

Flight Computer Development Update 9/2013

I successfully transmitted live GPS data between DNT900 radios!

The remote radio is under Arduino control where I built a DNT900 library to interact with the radio.  This allows the main program to capture GPS data, format it for transmission, and transmit it to the base.
The base radio has a similar DNT900 library in C#.  The program, a prototype for a larger data management program, captures and displays the GPS data sent from the remote.  The transmission distance was about two meters.

The transmission of live GPS data has been a goal since last December.  With this milestone, I am planning next steps.  Certainly the end result is a PC board, however I want to evaluate longer distances, and provide for peripheral devices (limit switches, temperature probes, pressure sensors, and the like).

New Flight Computer Development

The development of my new flight computer continues although slower than I prefer.  I have complete the following experiments successfully (I am using a Falcom FSA03 GPS, a RFM DNT900 900 MHz spread spectrum radio, and an Arduino Mega Pro).

  • Captured, parsed, and displayed GPS data using the TinyGPS library in the Arduino
  • Use the Arduino to send data from one radio to another

While the goal is to integrate the transmission of GPS data from one radio to another,  I am spending some time learning to create efficient coding structures to facilitate the goals of this platform.