Version History Report

Balloon Track is "Finished"

Balloon Track is now out of development. No further bug fixes or modifications will be made and no future versions will be forthcoming. It is still a useful program and so I'll leave this website up for reference and the availability of the final version of the program.

Notes about Version Availability at bottom:

Older Version History - to speed page loading, older version history has been moved to a separate page.

Want to be informed about new releases? Join the Balloon_Track mailing list at This list generates very little traffic. It is probably the best place to watch for announcements of new versions. I usually also announce on the EOSS mailing list.

Looking for a Bug Fix? Check out the Known Bugs Page first.

Beside each version is the date it was posted. For the most current version it may say "beta posted". That means that at the bottom of the download page you will find a beta download. This file often contains fixes listed in the description of the changes to the version indicated. However, not all of the features listed in the Version info may actually be working. I often start working on a feature, get a bug report in the middle of development, fix the bug, post the beta and return to working on the new feature. So, betas may be just fine or they might include very iffy code of a new procedure that causes problems. In other words, download betas and be prepared to revert to a previous version if you encounter problems. Betas will usually only include the executable program not the full installation. However in the case of 1.9.0, there is a full install to resolve a DLL issue.

  • Version 1.9.5 (beta 9L posted 25-Aug-08)

Howard Brooks of DePauw University discovered a bug in the "blender" (mixing of two winds aloft files)function. Fixed

  • Version 1.9.5 (beta 9K posted 30-Oct-07)

After running a prediction, the touchdown location could not be plotted on online mapping services using the main menu's Inet Mapping option. Fixed.

  • Version 1.9.5 (beta 9j posted 25-Oct-07)

Bug in the dual ascent rate routine fixed. Previously the higher altitude ascent rate set in the Advanced Ascent Rate form was used to determine position during descent down to the altitude set to institude the rate change. This resulted in an exceptionally long and slow descent resulting (in these winter months at least) in a longer prediction than should have been generated. This has been fixed and the program once again is using the correct values. Be aware that even thought the previous version of the program was actually using the wrong descent rates, it was erroneously reporting the correct descent rates on the print out. This may/will cause some confusion. To check, see how long it takes to descend from your burst altitude to the next lower altitude. If it takes a long time, you can be sure the program is using the wrong value. Sorry about this. I missed it completely for a couple of days of predictions running up to a flight and only became aware of it when a second prediction source informed me something was way out of the norm and I should take a peek at the code. The fixed version is posted as a new beta.

  • Version 1.9.5 (beta 9i posted 14-Sept-07)

EOSS has observed a distinct reduced ascent rate occurring when the balloon has ascended to high altitude. This observation has repeated over the course of many balloon flights. Some analysis has been performed and Nick Hanks have come up with a possible explanation having to do with atmospheric density and the development of drag below the ascending balloon as related to the Reynolds Numbers that are generated in a lower pressure zone. I removed an old feature (multiple descent rates) and changed it to "Advanced Ascent Rate". This button is on the first page of the Setup Screen below the entries for Ascent and Descent Rates. Click on it and a new window will open (Advanced Ascent Profile) where you can enter an altitude you wish to have this new ascent rate engage, and you can enter either new ascent rate manually (be sure to select the appropriate radio button) or have the program calculate one as a percentage of the lower atmosphere ascent rate.

I ran out of room (255 max items on a VB form) on the Setup Page. Therefore, I've split Mapping Variables Setup options off the main setup page and given them their own window. See the Setup Page description for details.

Another bug discovered by Andy Gonzales - KG6RWO  that I missed in the previous update. GE waypoints had Imperial units contained within them even if the program was in Metric mode. Fixed.

  • Version 1.9.5 (beta 9h posted 24-Aug-07)

Bug fixes only.

Andy Gonzales - KG6RWO - discovered a veritable plethora of bugs when using the program in Metric Mode. I think I have everything fixed. But we're still discussing things. I'll remove this waffling verbiage once we are satisfied I've covered all the bases he found.

  • Version 1.9.5 (beta 9g posted 04-Aug-07)

It's really time to pack this thing up and release 1.9.5 and be done with it. But ...

Mike Manes, W5VSI asked for a new export. One identical to the standard Flight Prediction but with the addition of two new fields, the track and speed of the balloon at each altitude in the printout. I did that and soon after Mike discovered that the winds were different for ascending records and descending records at the same altitude. That's fixed. So, this may prove helpful to some of you who generate reports for others to use in considering go/no go decisions.

  • Version 1.9.5 (beta 9f posted 18-May-07)

Hector Cintron, N1TKK, from Puerto Rico ran into a parsing problem. I'd hard-coded in the position of the altitude field in packets. We're talking about the ascii data strings that have altitude entered within the string somewhere as /A=xxxxxx. He has an encoder that is adding telemetry in the comment field and appending the altitude after the comments. I checked the spec and this is totally acceptable. The altitude field may appear anywhere within the comment field. It does not need to appear immediately at the start. So I've rewritten the parser to pick out altitude regardless of its location within a qualified APRS string. This slight correction is posted in beta 9f as there is a flight tomorrow depending on this fix.

  • Version 1.9.5 (beta 9e posted 5-May-07)

Josh Alwood needed to be able to set higher comm port baud rates. I've expanded the list of available rates to include 1200, 2400, 4800, 9600, (and new) 19200, 38400, 57600 and 115200. In the process I also added the ability to select additional comm ports. You can now select ports 1 through 8. I've noticed that serial to USB connectors often place the comm ports above the common 1 through 4.

  • Version 1.9.5 (beta 9d posted 29-Apr-07)

More tweaks to check the import file's validity for an APRS-IS server update. This also reveals that there is really no way to ensure absolutely that the source file used to update is actually an APRS-IS server list. So, I added a revert to previous version. It only will go back to the previous update though, so if you update twice from a bad source you're stuck with a bad file.

  • Version 1.9.5 (beta 9c posted 29-Apr-07)

If no "aprs-is_server.ini" file existed, the program crashed when trying to update the APRS-IS server list from a bad site. Fixed

The "~tmpNewServers.tmp" file is now deleted after a successful server file update.

  • Version 1.9.5 (beta 9b posted 28-Apr-07)

Two things.

Eric Winseman discovered a mis-labeled column on the CSV prediction export data file. It was indicating speed was given in knots when it should be MPH or KPH. That's fixed.

Hector Cintron N1TKK revealed a problem with the way the TCP/IP form handles a change in URL for the APRS-IS servers. That was weak. In this update I've got the program now updating the URL in the program and the initialization file as soon as you exit the form or run the UPDATE SERVERS function. Additionally, if an update fails, the old server list is reinstated so you don't end up with a blank list of servers.

  • Version 1.9.5 (beta 9a posted 17-Apr-07)

When updating the list of APRS-IS servers, the program failed to correctly recognize the file format used in France (new central server list holder). Fixed. by the way, that URL is now:

Jim Kilian, KC0TJN, couldn't get his Kenwood D7 to work with Balloon Track so, I added the ability to specify either hardware (CTS/RTS) or software (XON/XOFF) flow control to the Packet setup screen. This enables use of the Kenwood D7 as it requires software flow control.

Fixed a language localization issue for non-US areas trying to export Google KML files. Thanks to Ralph Bruckschen of Germany for reporting this bug.

Added the ability to plot multiple sequential prediction tracks on a MapPoint map. Thanks to Victor Aprea for this suggestion. This is NOT the same multiple prediction feature as described below. This capability plots the entire track for each prediction, but all mapped predictions have to be run in a single session. The feature described below uses the prediction history file which contains only the lat/long (and some other stuff) to plot the various touchdown locations for a series of predictions not run in a single session but rather, over a period of time (days or weeks).

Added minimal command line functions to allow some automation. See the Command Line Page for details.

In the process of incorporating the above capability I made a bunch of changes to clean up some of the code I wrote many years ago that really needed to be fixed. Anytime a massive rewrite occurs problems may crop up. If you are testing the with this new capability and discover a bug, let me know. I would appreciate it.

Added an export capability to create Google Earth data files (KML). See the Google Earth Export Page for details.

Slight addition to Scanned Maps thanks to Harry Mueller KC5TRB. You can now select whether or not to show labels on the track line of a prediction. Additionally, you can turn on the dot markers for the launch, burst and landing locations. Also, a help screen can be selected to guide you through the scanned map registration process. Open the Scan Map screen, select File/Map Registration and there are now two sub options, 2 point registration and help. You can open the help dialog and move it to the side for reference during your registration process.

A new mapping feature. Balloon track can keep track of predictions made for a particular flight. When you name a flight on the setup screen and then check the box on the Files/Folders tab to append predictions to the history file, BT will generate an ASCII delimited file with information about each prediction. This has been somewhat updated and expanded in version 1.9.5. BT can now map all of these predictions to a MapPoint map and generate a hotspot circle where the predictions are generally indicating as the most likely touchdown area. See the Map All Predictions page about how this works.

Harry Mueller KC5TRB discovered a new error message that infrequently appears in READY data files (possibly when model data is being updated). BT could not properly detect the error message and move past it to import the data, which is still present below the error messages. I've "fixed" this. Not sure if it is a good idea because of all the error messages in the first place but ... If you think that the data is definitely erroneous and can prove it, I'll remove this work around and place a notice to that effect when BT fails to import the data. I have included a pop-up to warn the user that there was an error message encountered in the downloaded data file during import so at least everyone should be reminded of what they are dealing with.

Balloon Track has an option to save predictions you make to a CSV file so you can see how predictions compare one to another. This is activated by selecting the checkbox on the Setup Screen's Files and Folders tab. If you have that option active then you can click on a new menu item on the View menu, "Map All Predictions" and an external instance of MapPoint will open with all the predictions plotted on it. This mapping option will NOT WORK on previously saved prediction files. Sorry about that but I was busy expanding the data set saved for each prediction and only after that change did I decided to tackle this mapping option.

Minor changes to the Multi-Site Prediction form. You can now sort the output by station (location) name. A second display is now available, the first being the incarnation of the display with the lat/long/alt information for the observing station and now a second display without that data. Regardless of which display selected, you can hover your mouse over a station location name and the lat/long/alt data will appear in a tooltip. However, if you export the data to a TEXT file, the output will reflect the form, ie: no lat/long/alt on the form then no lat/long/alt in the text printout.

You can now use the import filename you save forecast data into as a way to indicate the station name and forecast model being used in a prediction. This data will be used in various places where data is output by the program. See the Folders and Files tab of the Setup Page for more information.

A bug in the AGWPE setup screen fixed. Thanks to Hector Cintron, N1TKK for finding that one.

A while ago I got frustrated with everyone passing along latitude longitude information in different formats. So, I created a calculator for this program that would take just about any format I'm likely to hear and convert it to a form I'm likely to need. This is pretty nifty and much more advanced than the dumb gizmo I was using to enter in degrees, minutes and seconds into various places in the program. So, I've substituted the new converter in all (I think) locations. For instance, you're on the Forced Site Selector screen and want to manually enter a lat/long for the landing site. Pressing "Set" now brings up this converter to enter in the location if you only have it in degrees and decimal minutes or in degrees, minutes and decimal seconds.

  • Version 1.9.4 (09-May-2006)

A fault in the installer for 193 fixed.

  • Version 1.9.3 (17-April-2006)

A header change at READY forced a re-write of the import routine. It was a very minor but very welcome change whereby the new header offers more date and time information about the prediction data. Now, date and time data for READY data should be slightly more reliable than previously and now totally accurate all the time.

Dru Ellsberry from the Maryland Space Grant Consortium needed a way for a class of folks to be able to view data coming in over a local TCP/IP connection. I added that capability to the COMM-TCP/IP setup screen.

Hector Cintron, N1TKK, from Puerto Rico discovered a bug. If you attempt to process a log file that contains packets from a preceding day that were captured at a later time in the day BT would fail to parse the flight day records. Example: You fire up the payload the evening of prior to the flight. It locks up and transmits a packet at 11pm UTC. Some nearby iGate picks it up and relays it onto the net and The next day you fly at 11am UTC. A bunch of packets are forwarded on to between 11 and 14 UTC. You come home, ask findu for a log of all packet activity for your payload. The first packet occurs at a time later in the day than all of your balloon flight. The bug was that BT did not update the last packet timestamp unless a fully qualified packet was received. So, all the packets in the findu log were deemed incorrect because they all arrived prior to the first packet. Keep in mind that there is no date associated with most packets so there is no way to identify if a packet occurred later in the day on the preceding day. Anyway, this is fixed. The timestamp comparison is done for each packet with the packet that immediately precedes it regardless of whether or not that preceding packet is deemed acceptable for processing.

Harry Mueller, KC5TRB, was having problems importing data from an upper air Aviation site. The header at the site he was using was ever so slightly different from the one I designed the parser for. I've fixed the recognition routine to accommodate substantial variety in the header as long as it generally looks like an FD header BT will recognize it and allow an import of that data.

Possible Fix for users of MapPoint 2004.

Nick Hanks, a friend of mine and fellow VB programmer, was using MapPoint in one of his programs. I heard some of his "customers" complain of the occasional bug, but they never had a problem with MapPoint. I peeked at his setup and noted that he is actually running MapPoint externally from his own VB program. He just starts MapPoint and his program. Then his program sends messages to MapPoint to plot various icons. I decided to check it out.

Nick graciously tutored me to get me up and running. Thanks for that. I probably would have needed several days to get where Nick had me in several minutes. Then, once I sort of understood what was happening it was pretty easy to generate the code to run MapPoint in this fashion.

This version of Balloon Track incorporates the ability to use MapPoint either internally or externally. See the MapPoint Page for more details. And, check out the Setup Page for information on how to set up Balloon Track to use one method or the other.

This "Fix" will only work with MapPoint 2004. A reference to MapPoint is necessary in the program and you must be specific and only choose one version of MapPoint. So, I'm going with MapPoint 2004 to support the most current version using this method.

This is pretty early in this version's existence and is labeled a beta because I keep discovering new ways to generate errors. You can help by downloading the beta, and keeping track of just what was happening MapPoint and BT wise when the program crashes or acts in a manner unexpected by you, the user. In a few weeks I'll probably get enough feedback to take the beta tag off of it and post a full install and a "lite" upgrade.

GPS Visualizer Website Export added - I noted that ANSR was always depicting their flights on the maps generated at GPS Visualizer. I've added the ability to export a file in their preferred input format. This export routine is under File/Export/GPS Visualizer from the main menu.

Bug Fix - A bug in the Mic-E decoder was discovered by Ray Perkins. Should be ok now. Specifically, any Mic-E packet with a custom message would yield an incorrect latitude.


Note: Occasionally, new and unavailable version information is posted here. Any time a publish any correction to any page on the Balloon Track site, all pages are updated. So, on this page, new version information may appear prior to the posting of that version. Don't be rattled by seeing notes on a version that isn't yet available for download on the main Balloon Track page.