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