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.

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!

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 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.

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!

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).

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.