Tag Archives: flight track

Flight Track On Line Introduction

I invite you to explore Flight Track On Line for your next balloon flight!  Or, explore it with any of the active flights (click on the hamburger menu menuBar and select Active Flights) that are plentiful at six hour intervals starting at 00:00 UTC.

FTOL Features

  • Payload Tracking
  • Payload Search
    • Active Flights
    • 10 Day Flight Archive
  • Active Flights List (updated every 30 seconds)
  • Flight Information at Each Location
  • Follow Up to Three Flights
  • Predicted Descent Path
    • Displayed After Burst
    • Updated Every 3 Minutes
  • Graphical Activity Metrics
  • Distance Measurement Tool

 

FTOL Introduction Details
I have been using FTOL to follow flights for many months.  While I believe it’s ready for everyone to use, I think there are opportunities for improvements and possibly an occasional odd behavior.  For the features listed above, I ask for your indulgence and your feedback when you think of something that could benefit you and others, or if you find something odd.

FTOL replaces the desktop version.  I released the Flight Track add-in for Microsoft MapPoint in 2010 and appreciated everyone who experimented with it.  When my laptop gave out, it was time to step back and determine a direction for Flight Track.  I considered tool stacks for development, and Microsoft was ending support for MapPoint (I understand it is not supported on Windows 10).  I eventually settled on a web-based design and started implementation at the end of 2014.

The product is available for your use, entertainment (yes, I’ve spent some Saturday mornings entertaining myself with FTOL), and tracking!

 

Flight Track On Line – Autumn 2015 Update

FTOLUIFlight Track On Line (FTOL) has matured since my last update.  I include a screen shot of the interface with this post.  Clearly, it is a functional interface (that means I haven’t styled it yet).

FTOL is an application to support high altitude balloon hobbyists in tracking their payload.  In that sense, I log only those packets containing the balloon symbol (/O) in the APRS packet.  In my testing (one of the funnest parts of this port), I have found that FTOL logs up to 9000 packets per day.  I thought that was interesting so I include it and other metadata on the Flight Track Metrics page.

FTOL supports a search of the database.  If the call sign or object is located, FTOL loads the flight information and presents the path on Google Maps.  Alternatively, the Active and Inactive Flights page lists all of the active flights as links (I’ve seen up to 25 active flights on this page).  Click on a link and FTOL starts tracking the flight in real time (I’ve tracked five flights at a time just by clicking on links from this page).  While the link includes “Inactive Flights”, the final implementation is not complete.

FTOL would not be complete without real time flight path prediction.  That idea has not been lost in the multiple database schema and stored procedures changes, performance considerations, and data surprises that have found their way into this journey.  I have ported the algorithm and placed the path on Google maps once just to verify the concept.  There is still a bit of work on that.

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!

The Change Experience

I recently purchased a new laptop and with that is a set up effort.  I installed Firefox, BeyondCompare, and other applications and utilities I collected over the five years since my last new laptop.  These were the easy ones.  One of the more challenging and educational was setting up Visual Studio so I could continue to work on Flight Track.

The Legacy of Old Tools
I have been using Visual Studio 2008 Standard for a long time.  I still had the disk but the box indicated it was an upgrade.  I recall at the time that you could download Visual Studio Express for nothing.  I had done that but found it would not support add-in development (Flight Track is a MapPoint add-in).  If I wanted to install Visual Studio 2008 Standard, I’d have to find Visual Studio Express.

I found it in a Downloads folder on the hard drive I used two laptops ago.  What a lucky find I thought!  I installed it, upgraded it, and even installed SP1.  I transferred all of my projects and was working within a week’s time.  As I told the story of my fortune to others, I thought I should upgrade.  What are the chances of finding all the things I need?  What if the tools are no longer compatible?  A quick look for Visual Studio 2010 on eBay told me I would not be upgrading soon.  What if I never upgraded?

That question, and possibly the bright colors of autumn, had me asking what I should do with Flight Track.  I enjoy working on it and using it.  There are a few other users for it.  But, the thought of my tools growing old or unusable helped me to realize a change should be considered.

I think the ability to forecast a flight path and landing site in real time is valuable.  I understood MapPoint was a barrier to use Flight Track and experimented with Google Maps during the summer.  When I investigated methods of hosting an on-line version of Flight Track, the fact that I made calls to the APRS-IS servers would force the use of a dedicated server.  Together, these events had me considering alternative development solutions.

The Eclipse Experiment
One of my first considerations was an ability to work across multiple platforms.  This led me to Java.  I briefly explored both NetBeans and Eclipse.  I found Eclipse was a little closer to my experience in IDEs and started experimenting with it.

My primary requirements are:

  • Ability to embed a browser for hosting Google maps
  • Ability to communicate with radios or a GPS through a serial port
  • Ability to communicate with APRS-IS through the internet

I have others but these were the most important.  I started earlier today with this list.  By mid-afternoon, I had proven all of these were possible.

The Winter Project
I am looking forward to the challenge of porting the Flight Track functionality from .Net to Java.  I’ll also take the opportunity to re-factor, re-consider, and re-design.  Watch here for updates!

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.

FlightSimulatorScreenShot2014

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.