Tag Archives: balloon flight

A Lesson in Every Flight

A friend of mine helped plan and launch a payload about a month back.  I was saddened to learn they had not recovered the payload yet.  They are hopeful that as the soybean and corn fields of Ohio enter the harvest season, or as the leaves follow their autumnal cycle, the payload will reveal itself.  I wanted to help so I offered to review their data.

As with my flights and perhaps some of your flights, I think there are humbling moments that guide us towards better experiences.  Upon one of my successful recoveries, I noted the antenna cable nearly twisted itself off.  On another, a lift calculation error made for a slow ascent and a long, long day.  Like I said, humbling moments that helped me design better payloads and fly better flights.

For their flight, they decided to use the Spot Tracker as the primary means of following the payload.  I’m a fan of Spot and have seen it reliably used as a back-up, and used to locate a payload after APRS packets stop arriving.  However, in this case, the Spot separated from the payload mid-flight and was recovered from a corn field a few days later.  The payload was not found.

Their Spot logged 21 data points and the first six or seven were pre-flight (that is, on the ground).  They also had the KML from the flight path prediction.  I was able to piece together a likely flight path using the Spot data and prediction data.  However, the resulting landing area was still tens of square miles.  I could game the flight path by changing ascent rate, descent rate, or maximum altitude but gaming would not make up for a lack of key data.

Ascent Rate
The ascent rate would have helped to determine the altitude of the last Spot data point (the Spot does not provide altitude so I had to guess).  I’ve followed many flights (I enjoy following flights and they are great tests for my MapPoint Add-In and Flight Track On Line) and guessed a rate between 750 and 1150 ft/min.  I could employ the gas laws to make a better guess but did not have the volume of helium they used.  In addition to altitude, ascent rate has some impact on the final landing site.  In this case, a higher ascent rate moves the landing site north.

Descent Rate
The descent rate would have helped create a better flight path during payload descent.  In this case, a longer descent placed the landing site farther south.  However, it works better when the maximum altitude is known.

Maximum Altitude
The predicted flight path had a westward course above 65,000 ft.  The payload would travel west until burst.  The amount of travel impacts the landing site bringing it westward almost proportionally.

I was drawn into this hobby because of the engineering challenge.  It also allows me to explore software development and testing in ways usually not possible in a large IT department.  In turn, I believe it has helped improve how I develop and certainly how I test software.  Every flight becomes a story, and stories help make GPSL enjoyable as well as educational.

If they find the payload, I’ll return to this post.  Using just 14 data points during ascent with key pieces of information to predict a landing site may qualify for some sort of record.  Amusing but I didn’t do it for a record.  I’m happy to add an opinion that may assist in locating a lost payload.  I’m most interested in the story from the payload itself.  What will it provide that will make the next flight better?

Lastly, there are lessons above (no pun intended).  It is not for me to point out right or wrong since I continue to be a student in the adventure of flying self-built or team-built payloads on the end of a balloon to the edge of space.

What was your best lesson?

New Flight Track Update – Mid-Winter Status

Soon after I published my plans to upgrade Flight Track through a port to Java, I received one or two suggestions from our community.  One exchange inspired a Skype session where we discussed the possibilities of various platforms – desktop and web application.

One of my primary reasons for the port was the cost of maintaining Visual Studio.  Within weeks of my post, Microsoft released Visual Studio Community 2013.  After downloading and evaluating it, I decided I could use it to upgrade Flight Track and confidently support it through future upgrades of the IDE and my laptop.  This was an advantage for since I can use existing Flight Track code in the upgrade.  When I couple this decision with my platform conversation, I started the development of Flight Track On Line.

When I started the original Flight Track, I experimented with parsing APRS packets and displaying a location in MapPoint.  Having already proved this to myself with the combination of HTML and Google Maps, I thought a better goal was to process the near real-time data from APRS-IS.  In these experiments, a connection to the APRS-IS server was required – similar to how Flight Track operates today (Flight Track can monitor a radio or an APRS-IS server feed).  However, when I deployed this to my website, my host was “cautious” about having an open socket connection on their server.  It seems shared hosting is risk averse.
I thought I might be able to use a different source of APRS-IS data so I contacted administrators at aprs.fi and findu.com.  While I came away without a solution, I have greater respect and appreciation for what they do and how they do it.  I also received a suggestion to host my own solution.

Hosting a website on my personal computer was both intriguing and concerning.  Dedicating the same computer for Flight Track On Line and high school homework would probably have an impact on both, and I had security concerns.  About this time, my son had received his Raspberry Pi and, in addition to commandeering our television for his personal monitor, was talking about downloading a Linux distro.
After a couple of hours of setting up his Pi, we saw a GUI and some applications.  He spent much of that evening building a Mindcraft world.  Something in the set up caught my attention.  In the midst of downloads, setting passwords, and learning Linux commands, there was an installation of Apache.  There was also a picture of the default web page declaring “It works!”

I was familiar enough with Apache to investigate the Pi as a web server.  Multiple code examples and methods of accessing it from the internet prompted an experiment.  After a few days, my son and I found we could access the Pi in our living room from my website.  At this point, you may be ahead of my story.
Yes indeed, I purchased my own Pi and started developing prototypes in Eclipse.  The prototypes ported easily to the Pi and they even executed successfully.  During a very geek-filled holiday break, I combined REST libraries, Tomcat, and MySQL to receive and store data from an APRS-IS server feed.  In short, I believe I had the ability to monitor balloon flights in near real-time.

I have not put together enough code to follow a flight.  All the parts are there waiting for a snowy weekend to be integrated and tested.  Stay tuned!

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.