I was able to finally start a hardware development. It is an ambitious project to replace my existing flight computer. The plans include an Arduino at the core to manage telemetry, data collection and storage, and possibly experiments.
I started with an investigation into the DNT900 Transceiver built by RFM. This 900 MHz transceiver features high data rates and a 40 mile line-of-site range. I successfully prototyped one transceiver just to request configuration information from it. Next, I will set up the second transceiver and drive it from the Arduino.
I am completing the integration of a web transaction with the Air Resources Laboratory (ARL) hosted at the NOAA website. The ARL provides wind data forecasts, known as a GFS Sounding, for up to two weeks in the future.
With their permission, I submit the launch site coordinates and other launch data, present and collect the Security Code (it is required), and finally retrieve the predicted wind data. Flight Track uses the wind data to make a flight path prediction. With this integration, the prediction workflow is easier and faster. In testing, Flight Track retrieves the data in seconds where a manual method may take up to a minute.
Some of the interesting bugs along the way were entering the wrong Security Code, misunderstanding when the wind data model time starts, and selecting the correct Forecast Cycle. Looking forward to completing this testing and making this available to Flight Track users!
I have successfully integrated elevation data with Flight Track if only on the dialog where you define a launch site. I entered the latitude and longitude, and the elevation appeared in the Altitude text box (which will be renamed to Elevation). It was the easiest method of evaluating this integration. However, the units of elevation are Metric only and Flight Track supports both Metric and Imperial units.
In the organization of Flight Track, the Launch Site Definition dialog is some distance from anything that could perform a conversion from/to meters to/from feet. As I looked through the code, I discovered my first attempt to centralize this conversion however it seemed to require too much baggage to pass around to methods and to classes. It also seemed to require some management to insure everything in the add-in knew which system is in use.
Initially, I thought I could implement a static class available to the add-in. The measurement units would be available to every class the add-in. A little more thought and I recalled the Singleton Design Pattern. The Singleton class is static and exists as a single instance for the entire application. In my first experiments with my new Units Conversion Singleton, it behaved as expected. My next tasks are to evaluate the elevation in the Launch Site Definition dialog with the use of a units conversion. Additionally, I will comb through the add-in to remove the existing method of units conversion in favor of this Singleton.
Flight Track 1.1 was released at the end of May and with that I could start on the development of new features. The features I have in mind are an ability to determine elevation of the launch site and landing site, and charts.
Presently, Flight Track uses all of the data available from READY to create a predicted path. However, it is rare that a landing site exists at the last elevation in that READY data set. Rather, I want to end the predicted path near the elevation of the landing site to improve the accuracy of the prediction. Having found data available from the United States Geological Survey, Flight Track can use the data to determine landing site elevation.
Lastly, I recently found a charting tool Microsoft made available for .Net developments. I am experimenting with a graph of altitude and altitude change rates, and a graph of speed and direction.
I followed NearSys-12F and HAR120428 this weekend using the APRS-IS feed. I found interesting bugs (interesting to a tester anyway) in the parsing and in the Where Am I Now? feature.
I set up a new packet format for the NearSys flight and found that while the definition had no errors, parsing actual packets threw string indexing errors. This was easily corrected. I also set up a predicted flight path for NearSys-12F. The flight followed the predicted path very well.
The Where Am I Now? feature accepts NMEA data from a GPS connected to the computer. The add-in uses this information to display a small car pushpin to indicate the position of the chase team. In the pushpin’s information, the add-in displays the distance to the balloon, the elevation (in degrees) of the balloon from the chase position, and the direction of the balloon (in degrees East of North) to the balloon. Instead East of North, it displayed West of North – that’s a bug.
To evaluate flight tracking when a predicted path is not available, I set up HAR120428 without a predicted flight path. The add-in followed the flight without errors.
Thanks to those teams – those were great flights to follow!
I maintain a list of features and bugs for the add-in. I find both while using it during balloon flights and while developing features. For the upcoming release, 37 features/bugs were implemented. This includes a new algorithm for predicting flight paths using two wind data sets, better data management, consolidation of code, Tweeting from Flight Track, using a APRS-IS data feed to follow flights, and a new interface.
More bugs found and corrected this week in Flight file management (Flight New, Flight Open), and in flight path prediction.
I am targeting a mid-May release.
I started updating the Flight Track documentation and made a habit of starting the add-in so I could both get screen shots and match the documentation to functions. The work flow page has warranted most of my attention recently. When I started reviewing and updating information for creating predicted flight paths, I noticed small errors in the add-in’s user interface. As I investigated more, I found one instance where I left numbers in the code rather than supply the numbers from a configuration file. It would probably have never affected the prediction algorithms but it provides flexibility in the product when the numbers are in a configuration file. I think flexibility is important.
Updating the documentation has uncovered many minor and one or two larger bugs. It wasn’t something I expected but I’m happy to comb through the add-in in this manner and remove these errors. I want an add-in that assists users with their balloon flights (and my balloon flights) rather than annoying them with small errors. I look forward to following upcoming balloon flights to both demonstrate the add-in’s stability and, maybe, to find a bug or two.
I was focused on an
on-line course during most of February but managed to follow a few
flights for testing. I followed the flights of Stratus Maximus II.
2012A, and LEO-1 in the past month. During each flight I found small
bugs and started correcting them this week. Additionally, I completed
the coding and testing for upgrading configuration files, and evaluated the installation.
sampling of the bugs I found: pushpin titles appearing on more than one
pushpin during real time prediction, corrupted flight files when
changing the call sign for a flight after saving the flight, and a
periodic error in capturing packets through APRS-IS.
title was corrected but I discovered one MapPoint function is not
entirely reliable to locate uniquely names object when they contain
special characters. The corrupted files after a Save was very
bothersome so I analyzed it and designed a better algorithm (I prefer to
keep the details of flight file management to a minimum so all the user
has to do is open and manage their flight). The last error, the
periodic error during packet capture, has been difficult to reproduce. A
few more flights will be required to understand that one.
updating the Help files. This tells me that the features I wanted in
Flight Track are there and stable enough to document
I used Flight Track to follow the flight of BLT-28. Since the flight was designed to float, I did not create a prediction for the flight.
I found a bug after Flight Track started tracking using the APRS-IS server. While the packet from APRS-IS contained a valid call sign for BLT-28, the packet was not from the balloon (it was a confirmation message from APRS-IS for the filter) and the program failed during an evaluation of the packet. This was corrected.
I stopped the tracking and attempted to review the flight. This failed because there was no prediction for the flight. I reviewed the code, found the error, and corrected it. Additionally, this had the potential to be an error during tracking so I corrected this as well.
The last bug is a configuration file error. While this does not affect the operation of Flight Track, it will be corrected.
With a big list of changes and over a year in development, the next
release of Flight Track enters integration testing. Many of the new
features have been evaluated during development to verify intended
For example, the use of the APRS-IS feed was developed in stages to
clarify how to use it. It was seamlessly integrated with Flight
Tracking last Summer and Flight Track was able to follow balloon flights
from all parts of the country. Not only was the APRS-IS feed verified
but many of subtle changes to Tracking could also be evaluated with real
balloon flight data and conditions.
Integration Testing will provide a focused look at new features, a
regression test of existing features, and, of course, using Flight Track
to predict flight paths and track balloon flights. If you have an
upcoming flight that uses the APRS frequency, let me know!