Older Versions History Report

• Version 1.9.2 (10-July-2005)

If you installed the "Lite" version you might have received a bad or missing file error message with no way to recover. I've attempted to go through the code and find each and every instance of opening a file and incorporating error handlers to overcome problems that are not the user's falut. Specifically, the program was crashing because it could not find a file that it needed to create itself. A kind of chicken and egg thing I should have discovered were it not for the fact that I almost always run the program from within the environment where it is developed. So, sorry about that. This should fix that problem. At least it does for me on a clean install on a laptop.

• Version 1.9.1

Intermediate fixes, no records of what they were (drat).

• Version 1.9.0 (20-March-2005)

First off, nothing new since the beta of December 20th. I just haven't received any bug reports from the beta downloaders in a while so it's time to make the version final.

A bug involving MSVCRT.DLL seems to be causing folks problems. I've rewritten the code so it does not require this DLL. The beta full install and lite versions will not install it or call it when in use.

I've incorporated TCP/IP as a data source for tracking. So, beware of the Setup Screen's "Packet Parameters" tab. I've changed that a little by moving the com port settings and some TCP/IP stuff onto a separate form accessible from a button on that tab. See the Setup Page for a description of how this works.

Our Telescopic observing team was considering moving to a location more optimal for that purpose, somewhere southeast of the burst point. But, they needed tracking information based on their location to help plan their observing session. The Alternate Site Prediction "calculator" was thus born. See its description page for the details.

Once word about this capability circulated within the group a suggestion from Marty Griffin, WA�GEH, for multiple predictions for multiple different sites was made. And so, the Multi-Site Prediction was created.

Harry Mueller KC5TRB and Joe Conner W2OSU discovered some bugs with Scanned Maps.

Bug 1.) If you attempted to stretch or maximize a scanned map with no prediction on it then it would crash.

But 2.) If you loaded a map that had NOT been coordinate registered and went through the registration process, initially the plots start correctly. However, if you closed the map and reopened it, the plot would move. The most obvious movement would appear in the launch location. I've fixed this. However, I await more testing to see if bug 2 is really stomped for good.

A side note, the program used to allow multiple tracks to be painted on a scanned map. I've made that an option now. You can set it from the scanned map display screen and save those settings to the INI file so it sticks when you next start the program.

Will Holmes discovered something I would have though would get caught much earlier but... If you are new to the program and try to add a VOR into the program by clicking Select New VOR from the locations tab on the setup screen the program crashes since there is no VOR database file to load. This is fixed and the other location boxes are immune to this problem.

Gottfried M�ller of Germany exports data to Topo50, a program popular in Europe. He wanted me to change the width of the track line exported. However, I thought that this might be pretty much a personal preference thing rather than something that all wanted. So, I've created a form users can fill out changing various parameters. I don't have this program to test on, so I don't know just what will happen when parameters other than those I was originally requested to include are used so, there is a default button that will return the values to those the program originally used (and I had no particular complaints on :-)

Adam Thoreen ( U of Minnesota) encountered a crash situation. Basically it was a div/0 problem. However, it brought up the problem that I wasn't allowing users to determine how Telemetry data from a KPC3 was to be handled. I just installed a Telemetry handler for EOSS and thus caused problems for others. Now, on the setup screen under Packet Parameters there is the option to turn off Telemetry handling to avoid situations like this. There is also an option to simply strip the telemetry and write it to a spread sheet file.

Treasure Valley Near Space Program (TVNSP) has started deploying payloads that descend with different descent rates (drogue then full chutes). Their prediction guy, Jeff  Melanson, KD7INN, wanted a way to model this descent profile within his predictions. I've added that capability. See the Advanced Descent Profile page.

EOSS has had two incidents recently of payloads separating from the main support line and falling to earth without the benefit of a parachute or RDF/APRS equipment. I wrote a "calculator" that will assist folks in finding payloads in this situation. See the Separated Payload Finder Page for information.

Alicia wanted to be able to see grid coordinates measured in Feet instead of Miles. Ok, on the setup screen on the first tab there are now three choices for coordinates in the Grid Section of that form. Latitude, Longitude and Grid X,Y (Large Scale) and Grid X,Y (Small Scale). All behaviors are the same except if you pick Grid X,Y (Small Scale) the program produces grid results in either feet or meters, depending on the measurement system currently in use within the program.

My Balloon Group, Edge of Space Sciences, can't seem to agree to any single latitude/longitude reporting scheme. So, I GIVE UP! :-) I've created a form that will convert latitude entered in practically any format into practically any other format, for instance enter decimal degrees and output degrees and decimal minutes or degrees, minutes and decimal seconds.
I also looked through the program where the latitude and longitude is reported. On most of these screens there is now a button that will open this form. When it does, it lifts the latitude/longitude you are looking at and converts it. One sneaky place where this can be done but there was just no room for a button is on the Flight Analysis screen. If you double click on either the latitude or longitude it will open up the conversion form. And where ever you open this form from, you can click the button or double click the field and it will toggle it closed again.

• Version 1.8.9 (28-Jul-04)

Thanks to Harry Mueller, KC5TRB for a really rapid bug report, here is an instant fix for a problem introduced in the previous version relating to how Balloon Track passed latitude and longitude information on to internet mapping services.

• Version 1.8.8 (28-Jul-04)

Shermane Austin of the City University of New York (my old home town) was having problems rerunning post burst (real time) predictions. This has always been a bit bothersome. It actually called for manually entering in some data. So, ... I've made it somewhat easier.

Each time you run a post burst prediction from the Packet Terminal Screen (real-time or in simulation mode) the program will collect all the winds aloft data and write it to the file "FLIGHTNAME_inflight_winds.dat" where FLIGHTNAME will be replaced by whatever flight name you gave the prediction on the first tab of the setup screen. If you run multiple predictions, the program will accumulate multiple "FLIGHTNAME_inflight_winds.dat" files and distinguish them by adding a sequential letter, thus:
"FLIGHTNAME_inflight_winds_a.dat"
"FLIGHTNAME_inflight_winds_b.dat"
etc.

In order to properly set the program in the post burst prediction mode it now assists you by saving the burst data to a new program Initialization file (INI file). It names these files "FLIGHTNAME_postburst.ini" and does the same incremental addition of a letter to denote different prediction runs, "FLIGHTNAME_postburst_a.ini", etc.

If you wish to rerun a post burst prediction at any time you simply (well relatively simply compared to the previous routine) go to the setup screen, using the [File/Open] option on the menu select the "FLIGHTNAME_postburst.ini" file you wish to use, then select the matching "FLIGHTNAME_inflight_winds.dat" file. The program will run the post burst prediction exactly as it would have during live acquisition of data during the flight.

I've expanded very slightly on this explanation on the Real-Time Prediction page of this website.

Thanks for suggesting this Shermane, it will come in handy for post burst prediction but it will also enable me to keep a record of the winds aloft encountered during each flight for future reference too.

Marcus Barhofer, from Germany, needed a new export format for his mapping programs. I've added this to the list of export options. However, I doubt it will be of much use to other folks. It is titled "TOPO50" on the export sub menu.

James Ewen, VE6SRV, found a nasty bug. If you went to the setup screen, Folders and Files tab and entered a folder name for the Log Files folder and that folder doesn't exist, the program will crash when using MapPoint. I fixed this to check for the existence of the folder and made allowances for it if it was missing. However, James had a better idea ... if the folder doesn't exist, create it. So, now when you fill out any of the folder names by typing them in and close the setup screen, the program will check to ensure that all folders are valid. If any are not, a prompt will appear indicating the subject folder is not present and ask if you wish to create it.

I've added a "Comparometer". If you monitor your flights with the packet telemetry part of the program you can compare the current flight progress against the prediction for the flight. There is a button on the Packet Terminal Screen that will display this form.

Sometimes I would look at the list of VORs displayed in a prediction and couldn't for the life of me remember just where or what FQF or BVR was. So, if you click on the box on the main screen that lists the Active VORs a message box will pop open showing the abbreviation and the full name of each VOR. Also, if you print the prediction out, or save it to a file, those VOR's plain English names will be added to the bottom of the printout.

On the flight mentioned below, we had a backup telemetry system sending down data in a proprietary EOSS format. I've added a telemetry button to the Packet Terminal that, when pressed, will display this telemetry decoded. This is a totally EOSS proprietary thing so if you the users want, I can make the button invisible to folks other than EOSSians if it becomes confusing, distracting or annoying.

On a recent flight at EOSS we had a GPS failure. The antenna had come lose from the GPS receiver. The receiver was still sending data to the KPC3 but it was no good. We actually discovered this pretty close to the time the bad packets started arriving, but I thought I should add another alarm to the Packet terminal area. Check out the Alarm Screen and you'll note a new GPS Fix Alert. You can pick any wave file to play at this event. I've included one in the sounds.zip file on the download page.

A bug in the Flight analysis screen. When packets with duplicate time stamps arrive, the program became confused. Fixed

• Version 1.8.7 (23-January-2004)

Mark Conner discovered a bug. On extremely rare occasions the NWS upper air report might include records that are out of order with respect to altitude. I had assumed that ALL data would be presented with records in ascending altitude order so, no sorting of that data was made. Since this discovery I've added a sort routine to ensure that all data records appear in ascending order to ensure more accurate predictions and maps.

• Version 1.8.6 (7-January-2004)

Harry Mueller [KC5TRB] discovered that the NOAA Ready data format has changed. Thanks to his alert, I've updated the parsing routines to work with the new format.

• Version 1.8.5 (30-December-2003)

A couple of bugs in the Scanned Map option addressed. Specifically, when run in countries with regional settings substantially different than "English, United States", the map would fail. Thanks to Daniel Piergiacomi from Argentina for finding that.

• Version 1.8.4 (5-August-2003)

A bug crept into the Descent calculator when I fixed it for Harry Meuller, KC5TRB. Thanks to Harry, I've fixed that bug and also perhaps improved the interface using some of his suggestions.

• Version 1.8.3 (3-August-2003)

When doing real-time touchdown predictions from the Packet Terminal Window the program now predicts from the altitude, latitude and longitude of the last packet received instead of from those values at burst. This means you can rerun the prediction whenever you wish as the payload descends.

I also added the ability to beacon out the current real-time prediction. I use a KPC3 Plus. It's in standard terminal mode. When a beacon is transmitted the program first gets the command prompt by sending a CTRL-C to the tnc. If it sees the "cmd:" prompt then it sends a "k" to enter transparent mode. It then sends the prediction APRS string to whatever unproto path you have specified.

Harry Mueller, KC5TRB, discovered a bug in the Descent Calculator's loading and changing of custom parachutes. Fixed.

Changed the behavior of opening the Alarm Window from the Packet Terminal. Previously, all alarms were automatically reset. Now, you need to punch the Reset Alarms button to accomplish the reset.

• Version 1.8.2 (6-May-2003)

In recent flight we had to rely on a Kenwood D7 for APRS on our payload. It was a disaster for Balloon Track (no integral time stamps in packets). But it did turn up some interesting bugs.

1. The Kenwood D7 packets were not being charted at all. That's fixed.
2. Real Time Data was always crashing. This was because occasionally packets were time stamped with the same time. This resulted in a difference from one packet to the next of zero elapsed time. Since many computations rely on this elapsed time, lots of divide by zero errors. I've fixed this by tossing packets with duplicate time stamps in the charting routines.

I discovered that if a post burst real time prediction was run then the range and bearing calculations were being made not from the launch site but from the burst location. That's fixed.

In another recent flight EOSS suffered a fouled parachute resulting in an exceptionally rapid descent. I failed to notice this for several minutes. So, I've added an ALARM feature to the Packet Terminal. You can set this to play wave files when certain parameters have been met or exceeded during real time tracking. See the Alarms Page.

I've added an Internal Browser. It is no where near as sophisticated as a "real" browser, however, it allows you to navigate a bit faster to those limited websites you'll be visiting to acquire data.

Randy Lefevre was having trouble making out the track lines on map displays because of the colors used by Balloon Track in drawing these tracks. I've added the ability for the user to specify which colors they wish to use on the various map screens

I found an embarrassing bug in the program. In the Descent Calculator the program was supposed to convert the weight of a parachute from ounces (or grams) to pounds. It wasn't doing that. Instead, if you entered 32 ounces, the program added 32 pounds. Perhaps you noticed this. The bug was introduced in the last version of the program when I changed the algorithms used to calculate descent rate.

I came to the conclusion that the interface for the descent calculator was a disaster. I've redesigned it and I think it is now much more intuitive to work with as far as adding, editing and removing custom parachutes. You can see the differences on the web page covering the calculator.

Previously, you had to wait for a packet to arrive before the Alternate Tracking and the GPS Diag Screens would fill with data. Now, the program lifts the last received data to fill in these screens.

On the charts screen, fixed a bug that prevented the program from displaying full data in the Ascent Phase only mode. This occurred when an arbitrary burst altitude was selected and it was higher than the highest altitude in the source wind data file. The problem used to be that the chart would only display information up to the last record PRIOR to burst. It now shows the full ascent data right up to burst.

Related to above, I've fixed a problem with the "Working Database" display on the main screen. Previously, it ended with the highest winds available in the source wind data file. Now it includes an additional level for the arbitrary burst level if that option is selected.

Bug in fabricating the station name used in creating filenames fixed. If you loaded multiple files that name might in some circumstances concatenate with previous names acquired in prior file runs.

• Version 1.8.1 (7-April-2003)

The Balloon Track Manual has been updated to reflect changes made since its premier several versions ago.

I've created an internal internet mapping option. Go to the Internal MapBlast page.

I've re-written the descent calculator and added the ability to customize it (to some extent). I've also added a Descent Calculator page describing it.

During our last flight at EOSS we used two different VORs for liaison with the FAA. I thought it would be nice to automate this process in the future. There is now a checkbox beside the VOR setup area on the Locations tab of the Setup screen. Check it and the program will automatically scan through your "vorsites.ini" file and pick the closest VORs for bearing and range for each altitude record computed in the prediction.

This process leaves you at the mercy of the programmer. Your old "vorsites.ini" file is now semi-obsolete. Balloon Track will detect this and "sort of" fix it. Entries in the VOR INI file now require a 3 letter ID for each VOR at the end of each record. Balloon Track will correct the format of the data file by adding a trailing comma to indicate another field. In this way the program will load the VOR file properly and it will even work OK. However, it will not provide the all important VOR ID in the printouts. You will have to actually fill in the VOR ID field with the correct identifier on the Setup Screen. You can do this manually by opening the vorsites.ini file and typing in an open quote, the three letter ID, and a close quote after that trailing comma. Or you can open the Select New Location for the VOR sites,  click Edit for each entry and enter in the ID. Don't forget to click the Save button after you enter each individual ID or the program will not save the data to the file.

David Brock has discovered several bugs relating to Metric vs. Imperial issues and also a few program crashing items. These have been fixed.

Luis Briones discovered a couple of bugs in the importing of files from the University of Wyoming. Essentially the program was using criteria that was too stringent and not importing some valid wind data. That's been fixed. You probably would have noticed this if it happened to you. The data files would have good wind data to some reasonable height, but Balloon Track would stop importing at a very low altitude when the criteria were not met.

He also noted that the stations he looks at have 4 letter IDs and Balloon Track was truncating them to 3 letter IDs. That's fixed too.

Luis sent along an INI file for use in the trouble shooting process. When I tried to load it the program crashed. This was related to a Metric vs. Imperial measurement system issue. I've fixed the problem. If you are a metric user and were getting weird results when you typed in Burst Altitudes on either the Setup screen or the Main screen, this is also fixed.

• Version 1.8.0 (28-March-2003)

A problem with the "fix" of the previous version regarding the MapPoint activeX component. It seems that there is no way around including it in the program setup. Otherwise, the program fails to start.

A user was attempting to use the "Flight Analysis" screen with packets coming from a TNC with "MCOM" turned ON. I've added a parse routine that strips out the " <UI>:" text from such packets so the program will continue to correctly parse out the rest of the APRS string.

• Version 1.7.9 (15-March-2003)

Mark Conner N9XTN wanted a way to view results via internet mapping sites. I've added that capability. See the Setup Page for an overview of how to set it up and what it does.

A.J. Oben has discovered that if some type of serial device is not connected to the computer it is impossible to open the packet screen without getting a program crash.

I have added a "No Comm" option to the setup screen under the Packet Tab, specifically in the drop down menu for the Comm Port number selection. This cures the problem.

I've reworked the means of generating a prediction based on actual data obtained via the packet terminal during a flight. There used to be a button labeled "Extract Data". That has been relabeled to "Realtime Predict". See the Packet Terminal page for preliminary info and go to the Real Time Predict page for an overview of how it works.

Due to some IT managers concerns about the legality of having the ActiveX component of MapPoint installed, I've removed it from the installation routine. If you HAVE MapPoint, you already have this control installed and Balloon Track will use it. If you do not have MapPoint it's never called and thus makes no difference to the program.

If you have the control installed and wish to remove it you MUST uninstall your version of the program and then install version 1.7.8 or later. Do NOT just delete the file as that breaks the installation of Balloon Track and the program will not run.

• Version 1.7.8 (28-December-2002)

Eric Watkins reported having trouble with Balloon Track finding the Map Point program and thus enabling mapping with that program. Balloon Track crashes if it tries to call MapPoint and that program isn't there. That's why I tried to auto-detect it. I'm working on a more elegant solution to this problem, but in the meantime, I've added a checkbox to the "Files and Folders" tab of the Setup Screen where you can indicate you have MapPoint even if the Balloon Track does not automatically detect it.

Added a wind blender. You can now specify two files, one for low level winds another for upper level winds. The program will combine them giving priority to the lower level wind file. See the Wind Blender Page for more info

Added another APRS string type capable of being correctly parsed. See the Importing APRS or GPS data page.

A bug in using "Time of Day" for output. If no Expected Launch Date information was entered on Tab 1 (Location Data) the program would refuse to compute. I've added default date data that should fudge around this.

A bug in one of the Calculators fixed

MapPoint fails if you don't have a recognized latitude/longitude in your Launch Site info (on the setup screen). There's no way I've figured out (so far) how to completely solve this, however, since MapPoint is only available for the US and Europe, I set a limit on the Latitude for a Launch Point (only for invoking MapPoint - Southern Hemisphere folks don't worry). of 15 degrees North Latitude. This will essentially catch a non-existent entry for lat/long since it defaults to near zero.

• Version 1.7.7 (21-May-2002)

WARNING Slight bug in the Scanned Map function in previous version - FIXED HERE

Individuals who downloaded 1.7.6 and registered maps MUST re-register the maps with this version.

The latitude of predicted (and realtime) tracks appears slightly to the south of its actual location. The closer to the bottom of the map the greater the error. This has to do with the way the maps are painted to the screen. It's fixed in this Version (1.7.7).

The larger in physical size (pixels) the less pronounced the error.

The updated routines are working VERY well with computer generated maps (screen shots from mapping programs or mapping websites).

• Version 1.7.6 (14-May-2002)

After incorporating MapPoint into the program I received some grumbles. Who in their ever loving right mind is going to shell out $270.00 for a map program to support Balloon Track. :-)

However, one individual came up with a suggestion.

Hank Riley, N1LTV, was definitely not interested in MapPoint but he thought I should add a way in which folks could use their own maps in the program. "NO WAY HANK", I responded with a deeply reasoned comment that it would probably take as much code to write this type of routine as was already in the entire program. But Hank persisted in his request. I thought about it and started playing around and discovered to my chagrin that it was actually a piece of cake to do this type of thing. So, check out the Scanned Maps Page for the scoop. The tracking on these scanned images in not very accurate yet. I'll be attempting to refine it in future versions. But, there was a bug that needed to be addressed pronto and so this release arrives without the full treatment to scanned maps. But, I'm working on it. Thanks for the motivation Hank.

During EOSS-56 there was a request for data concerning the balloon's position several minutes in the past. I didn't have that data at my fingertips so, I created a new screen that would display historical data concerning the flight so I would always have any relevant information available. See the Flight Records page for details.

In the process of writing the MapPoint stuff, I may have broken the program's ability to parse out the APRS string we use at EOSS. I've fixed that.

While fixing the above, I discovered a bug where by the program gets confused (on the Flight Analysis Screen) if it receives duplicate packets. That's fixed too.

• Version 1.7.5 (6-April-2002)

I've been attempting to update these web pages to reflect the current state of the program.

I recently purchased a copy of a new APRS program, APRSPoint (www.aprspoint.com) . This program integrates with Microsoft's MapPoint program which is similar to DeLorme's Street Atlas. I discovered it is pretty easy to incorporate MapPoint maps within Balloon Track, so I have added that capability. Go to the MapPoint page on this website to see the results. As you will see on that page, I've added mapping to both the prediction and real time tracking capabilities of the program.

MapPoint isn't an inexpensive program so you should definitely download the demo before thinking about purchasing it for use in this program. If you do decide to buy it, I would STRONGLY recommend you get it by purchasing the APRSPoint program with MapPoint included. Even with both programs bundled together, it is much less expensive than purchasing MapPoint alone from a retailer. Of course, you should do price research on your own before you fall for my advise.

During a recent flight (EOSS-55) I was asked what the bearing from a VOR was. I had to manually set it and wait for a packet to arrive before I could produce an answer. So, I've redesigned the Alternate Track screen. You can now open that screen from the Packet Terminal screen and  get range and bearings from up to 4 sites to the balloon's current location. See the Alt Track Page for details.

Forced Cut Down - Suppose you wish to limit the distance your balloon travels from launch to landing. You can go to the setup screen, check "Force Cutdown" and enter a distance from the launch site where the balloon should be released and the payloads start their descent to the ground.

Occasionally I wish I still had the original source raw weather data file I first imported into the program. Now, if you wish, the program will automatically save that file. See the section on Files/Folders on the Setup Page.

When importing a "Profile" wind file from

http://www.arl.noaa.gov/ready-bin/profsrc.pl?metdata=AVN+191+km

Balloon Track has to make up a month for the filename of the imported data. I had this set to add a month when the day of the profile did not match the current day of the month. That was wrong, it should have added a month if the profile day was less than the current day of the month. Fixed.

A bug on the Flight Analysis screen was giving false ascent rate info. Fixed.

• Version 1.7.4 (12-February-2002)

OOps, there is a new tab on the setup page. Ascent Rate Mods. It wasn't enabled or attached to any code so I've removed it to avoid confusion.

While working with Mark Conner on the last update, it became apparent that Balloon Track wouldn't handle the amount of data he wished to process. So, I've upped the limits. Balloon Track will now read in up to 1200 records from a data source.

If you can live without the increased data handling capabilities and don't mind seeing a dysfunctional tab on the setup screen, you might want to wait for the next version to see if anything new touches your fancy.

• Version 1.7.3 (11-February-2002)

A new Utilities section is available with one :-) util program.

Mark Conner is using a Garmin Proprietary format string ($PGRMV) to assist in determining the ascent/descent rates. He wanted it included in the synthesized GPS string export routines. It's there now. Check it out on the Exporting Data page to determine if this is of value to you.

Did you just install Windows XP? Did you notice program windows were being truncated? I've gone through the program and resized all the windows for the new interface. See my notes about this "problem" HERE.

I added a feature to the charting screen and changed the default behavior. Previously, when charting parameters both the ascent and descent phases of the flight were shown. Now you have the choice of seeing only the ascent or both ascent and descent. The change ... the chart opens only showing the ascent phase of the flight.

Dates in "AVN" imports could become confused when formatted for output as filenames or dates in reports. Fixed.

Another flight (EOSS-53) another bug or feature addressed.

I've added a new output file. It's essentially a history file that keeps records of every prediction produced. See the Setup Page for details of the data stored in this file and how to activate or deactivate it.

Found a bug. If you opened the Packet Terminal, then opened the Analysis screen, then prior to receiving any data tried to change the plot or any other option on that display the program crashed. I've fixed this. Now, the program will make sure you have started accumulating data before attempting to redisplay data. This fixes the problem.

Related to the above, I've made clicking on the buttons on the Analysis screen take effect immediately. Previously you had to wait until a new packet arrived for the display to change options and update.

• Version 1.7.2 (22-October-2001)

Normally when you run a prediction the printout (and display) shows a number of elapsed minutes from launch for each data point. I've added the ability to change this elapsed time into "real time" as calculated by using the elapsed time added to the expected launch time (set on the Setup Screen).

While preparing for EOSS-52 I discovered a bug in the routines for displaying VOR range and bearing. If the balloon came within 1/2 mile of the VOR the program would crash while trying to format a "bad" distance (program would only work with whole numbers). I've fixed that. The program how will display "<1" as the distance and not crash.

On the "Process Packet File" screen the program has changed how it generates a new prediction. Instead of calculating a prediction for an entire flight from launch point to touchdown, the program calculates a prediction for the path from the Burst point at Maximum Altitude to the touchdown point using the Drop Mode for the prediction. See the Process Packet File page for more details.

A behind the scenes change ... previously, a really ugly routine was used to monitor the comm port for the Packet Terminal Screen. I have changed that to an interrupt driven method. This greatly reduces the load on the system processor and should afford better performance for other programs running concurrently with Balloon Track.

• Version 1.7.1 (21-June-2001)

More fixes for the parser for the new winds format at U of Wyo.

A beta of this version has passed several tests and it looks good to go at last. But, time will tell. Only fix here is the parser. Both the full and lite versions are available for download.

• Version 1.7.0 (13-June-2001)

Naturally, I didn't quite cover all the bases in the parser for the new winds format. I've cleaned up a problem with the date not being correctly recognized. Bill All has some other issues and these may turn up other required fixes so ... report any problems importing winds from the U of Wyo.

• Version 1.6.9 (12-June-2001)

Added parsing routine for the new University of Wyoming data format. Old format is still supported too.

Discovered the program would crash if you manually entered an incorrect path to one of the folders on the setup screen (outside the program) then tried to fix it inside the setup screen. That's fixed.

• Version 1.6.8 (6-March-2001)

Added Footprint Diameter (not radius) to the Flight Analysis screen.

Made the "FAA Reports Only" button part of the configuration, added it to the setup screen. Now the program remembers this setting from run to run.

Discovered several bugs with the Comm stuff during the Flight of EOSS-47.

I was incorrectly closing ALL files when attempting to extract data for a post burst prediction. This caused the next packet received to find a bug where it's log file had disappeared. ERROR Code 52 I think. Fixed.

I was reusing a variable which caused the program to crash because of incompatible formatting. That's fixed.

There is a major problem dealing with incorrect baud rates. I haven't even started out on that one. But, I am aware. For now, just be sure to set the baud rate on the setup screen correctly before opening the terminal or the program may lock up and you'll have to use the task manager to close the program and restart.

Even with all these problems, the data acquisition during EOSS was not disturbed and a post burst prediction was possible. Did have to restart Balloon Track once during the ascent though.

• Version 1.6.7 (16-February-2001)

Added a Status Bar to the Main Screen. Now, the currently active data file is displayed on that bar (at the bottom of the screen) instead of on the title bar. I also added the Bearing and Range to Touchdown (from the Launch Point) to the status bar. You can see all this in the screen shot on the Main Screen Web Page.

Discovered a bug in the View Files option that was introduced in V1.6.6. The files were not loading. Fixed.

I've made the buttons on the main screen "data aware". Previously, you could click on one of them even if no predictions had been run and the program would pop up a message box telling you the errors of your ways. Now, they are grayed out and inactive until you load a data file and run a prediction.

In the process of the above, I noticed that the groupings of buttons wasn't that logical, so I moved a few around.

While doing the "data aware" stuff above, I decided to apply it to the File/Print and File/Export options too. In the process I discovered a bug where the program would crash if no prediction had been run. Since you can no longer elect to print out or export data prior to running a prediction this bug has been cured.

I used to include an example of a weather data file captured from the net (exampleimport.txt) in the distribution. I've removed it. If you wish to test the program on example files go to the Importing Data Page and download one of the sample files from there.

• Version 1.6.6  (06-February-2001)

This release provides dramatic improvements in the Packet Terminal screen. The terminal has been COMPLETELY re-written. It actually works quite well and is MUCH more reliable. If you HATED this part of the program before, give it a try. You simply will not believe how much better is is. I recommend you get familiar with the capabilities of this part of the program PRIOR to a flight so you can use it without too much confusion. See the Packet Screen Page for details.

Added an APRS network analyzer (sort of). While the packet terminal is operating, the program keeps track of the last 500 stations it has heard noting the types of packets it hears from each station. See the Count Callsigns Page for details.

Added real time Flight Analysis. This is pretty cool. Finally, Balloon Track is actually a tracking program. Took long enough. Go to the Flight Analysis web page for details.

Added/improved the ability to import a text file containing GPS or APRS data to create a wind data file. This capability, while existent in previous versions, was somewhat limited and hard to use. I have completely re-written this part of the program and I think you will find the new interface easier to use and the data generated quite valuable to your search and recovery teams. See the Import APRS/GPS page for details. See a couple of screen shots demonstrating the improved accuracy here.

Changed the APRS export string format slightly by adopting a  standardized APRS string. These new strings include time stamps, and altitude. See the Export File Types Page for details.

Added a GPS export capability. The program will export $GPGGA, $GPRMC, and $GPGSA strings. You can select either $GPGGA or $GPRMC, but you must choose one for the export to complete. See the Export File Types Page for details.

Added X, Y coordinate label printing to the Street Atlas Export dialog box. 

Believe it or not, I'm still working on the metric vs. imperial switch. I made some changes (prompted by the extract routine above) that should make it more reliable.

• Version 1.6.5 (8-October-2000)

As you will note below Luis Briones has been quite busy discovering bugs in this version of the program. Thanks for all your help this on this version.

The "Run" button on the main screen has been replaced by a "Force Re-Calculation" button. It's the same thing essentially, however just about everything you can do within the program that would require the prediction be rerun causes that action automatically. There may be cases where I've missed something and you will need to press this button. Email me about a failed auto-recalculate and I'll be sure to fix it. In the meantime, I'll leave this button on the program so you can make sure the prediction values are correct. 

Previously, when a new data file was loaded, all open screens were closed (this was to ensure old data was not displayed). Now, all open screens are updated with new data as derived from the latest flight prediction.

The main windows of the program (Main Screen, Synopsis, Charting, Plot, Forced Landing, text file viewer and Winds) now have "sticky" positioning. You can move these windows around on your desk top and when you close them their position is memorized. Next time you open them they will appear in that same location.

The Plot Screen now resizes. You can stretch it (if you have the display resolution) to make detail more evident in the track. 

Both the Plot and Text File Viewer screens will not only remember their previously opened positions, they will also remember their dimensions.

The buttons on the main screen to open charting, synopsis, plot, and winds are now toggles. If those screens are open, then clicking on the button again closes them.

Balloon Track will now accept a user grid reference. Look at the setup screen (first tab) to see how to set it. See the Tracking Grid Page for more explanations. The X,Y coordinates are now included in the ASCII exported comma delimited text file. Also, a name is now suggested for this file. It is the name of the opened data file with the file extension of CSV which is a recognized file type for Excel.

I have added the capability to save a "Forced Burst Altitude" to the ini file (from the Setup Screen). You can enter an altitude where you wish the program to terminate the ascent phase of the flight. There is a checkbox beside this altitude. If you select it, then the program will automatically use this altitude each time you run the program.

I also changed the color coding on the text on the main screen. Previously, regardless of altitude selected, if you were forcing a burst altitude, the text output of the program was highlighted with a red background to warn you you were not sticking strictly to the wind data file. 

Now, the background is red if you enter an altitude that is above the highest available altitude in the wind data file. This warns you the program is "making up" winds aloft for all altitudes above the highest reported altitude in your wind data file.

However, if you enter a burst altitude that is below the highest reported altitude in your wind data file, the program highlights the text output with a green background. This indicates that you are NOT using the full wind data file, but, you are using valid wind data for all computations.

I added several new graphs to the charting screen. 

Luis Briones  and Andres Fernandez LU2VEA have been testing and discovered something that led me to a possible resolution of many INI problems. 

Luis Briones discovered a bug with a fresh install. It may have to do with the lack of an INI file and incorrectly set default values for some variables. I've tried to ensure all values are set with valid default values.

Luis Briones also discovered a problem with some browsers saving text files in a format unrecognizable by Balloon Track. In his case, it seems it was UNIX style of text files that were saved. I've incorporated a text file test into the program. If it's a "normal" Windows type text file then it just loads (imports), however if it is in Unix format, the program recognizes this, and offers to convert it to a Balloon Track compatible format. The source text file in the UNIX format is saved with a *.bak extension.

Luis Briones wanted an export capability for a program called Ozi Explorer. I've added that to the program.

While playing with the program I discovered some inconsistencies when bouncing back and forth between metric and imperial measurement systems. I've attempted to iron out these problems. 

Web URLs that contained an equals sign in their address were not being saved and read properly in the Launch Browser dialog. Fixed

Added an FAA flight level 270 (27,000ft) as it is being requested for our current flight.

Because of some additional data now presented in some printouts, the font size has been reduced to get everything on one page. I also tried to get page breaks to line up more consistently.

• Version 1.6.4 (3-September-2000)

Mark Conner discovered a bug in the setup screen. If you entered any non numeric characters (blank out a value) the program crashed. Now, the program forces a numeric value for all these entries. If you enter nothing, the program generates a zero or near zero value to avoid a crash.

I was getting tired of entering my callsign for each APRS export file I was creating for a recent flight, so, now, whatever callsign you enter to create the APRS data will be used as the filename (i.e. I use N�KKZ-3 so the program now suggests "N�KKZ-3.TXT" as the export file.

Likewise, exporting to Street Atlas I was always being presented with the encoded long filename used to create the data file. Now the program suggests "latlong.txt".

Occasionally the burst point was incorrectly labeled. This revolves around having winds available for altitudes LOWER than your launch site. The program doesn't use these winds in the ascent part of the prediction and this was throwing off identification of the actual burst altitude. I think I have this fixed.

When producing predictions ONLY for FAA altitudes, the program was not printing the first and last (takeoff and landing) data points. They are now included.

• Version 1.6.3 (11-August-2000)

Well, Steffen Barth [DG�MG] discovered that I managed to totally destroy the import routines when making the changed in version 1.6.2. I've fixed them all and had to release this version to make the program somewhat useful. Sorry about that and thanks for keeping sending in those reports Steffen.

• Version 1.6.2 (10-August-2000)

Steffen Barth [DG�MG] discovered some regional settings problems. The program was not saving program settings in the initialization file properly. Or, for that matter, reading them back into the program correctly. Hopefully this is fixed.

I asked for it and I got it. Several folks offered URLs to websites with appropriate data for use with this program. Several sites used new formats of data so I built a decoder routine to support them.

I've re-coded the import routines. You no longer have to specify which type of data you are importing. If it is one of those formats supported by this program, Balloon Track will recognize it and use the correct import routines.

I also added an Importing Overview page. There are links to data sources for the various supported formats on this page.

• Version 1.6.1 (30/July/2000)

For EOSS-43, which was scrubbed, we were scrambling to acquire winds aloft. My usual source was down. So, I've written an import routine which will read FAA Winds aloft forecasts (FD). I've checked this out with several sources and it seems to work ok. The problem, FD forecasts only go up to 39,000 feet. You will need to fudge the winds above this level. 

To use this feature, find some FAA winds aloft info and save it to a text file. I've been going to:

http://www.awc-kc.noaa.gov/awc/awc-fd.html

Then, using the [File/Import/Import FAA FD] option on the main screen, select the file. A screen opens with the file displayed. Using your mouse, highlight the station name you wish to import. The only important thing here is to make sure that the highlight STARTS with the station name. You can be sloppy about where the station name ends. For instance, you could highlight several lines of data. The station name that begins this highlighted section will be the one imported, all other data is ignored. When the station name is highlighted, click OK. The program then imports the winds aloft for that station and suggests a filename to save that data to.

• Version 1.6.0 (17-July-2000)

After each balloon flight I seem to discover new things to add so:

James Ewen wanted a quick way to switch from Metric to Imperial Measurement systems. It seems that clicking on the setup screen options wasn't exactly doing the job without restarting the program. So, there is now a button on the main screen. Punch it and everything converts from one system to the other. All open screens (Track, Charts, Winds, and Synopsis) are also updated.

I wanted an easier way to quickly switch from one launch site to another, and one VOR site to another. Now, open the Setup screen, click on the Location Data tab, and then click on one of the three buttons at the bottom of the screen under each site. 

The first time you use these, there will be no sites entered and you'll be advised of that. Simply click ADD on that form, another opens. Enter the data for your new site. You will then return to the Select Site screen. Click on the pull down tab besides the Location field and all locations you've entered will appear. Click on the one you wish to use. Then Click on Activate and that data will be copied into the program's variables for that Site.

From then on, when ever the program loads, it will also load this alternate location data. Then you can quickly switch from one site to another and re-compute the predictions. Any changes you make can be saved to the INI files, or you can just click "Close Use these Settings" at the bottom of the Setup screen and they will only remain in force for that session of Balloon Track.

WARNING: You can still enter values directly into the Launch, Landing and VOR boxes on the Setup screen. However, these values will NOT be saved for future use (except possibly in an INI file. You MUST enter values by punching the button at the bottom of the Location Data screen and then click ADD on the form that pops up to add site data to the various data files used. Also, should you wish to delete a site, you'll need to open the related database.ini file with a text editor (notepad) and remove it manually. The three files created to maintain this inforomation are:

lanuchsites.ini
landingsites.ini
vorsites.ini

They are only created when you add your first site. And, if you follow the conventions exactly, you can use a text editor to add sites directly to the files. Notice that the vorsites.ini does not have altitude information, but instead includes the magnetic offset for the VOR. Balloon Track uses this value to create correct bearings for the balloon in Magnetic Degrees rather than True degrees.

EOSS ALWAYS maintains close liaison with the FAA. We report the predicted position of the balloon prior to flight to assist the various control facilities in "avoiding" us. The FAA is only interested in certain altitudes. So, a long time ago I added the "ADD FAA Reports" button on the main screen. But, all the program did was deduce the position of the balloon at those altitudes and ADD them to the total output. I was always cutting the "non-FAA" altitudes out of the file for easier comprehension. Now, that button has been relabeled to "Only FAA Reports" and only those altitudes the FAA is interested in are printed to the various report screens and reports. But, still, there are lots of altitudes they might be interested in, but don't always request. So, I've added "FAA Report Setup" to the Setup Screen. Click on this tab, then put a check mark beside each flight level you want reported. Then when you select "Only FAA Reports" only those checked altitudes will be reported. These values are saved in the INI files.

Clicking on the FAA button also automatically reruns the program to display those values.

• Version 1.5.9 (15-July-2000)

James Ewen wanted an export option to create APRS log file for plotting within his programs. Now, under File/Export there is an APRS option. Select it and a dialog box opens allowing you to specify the Callsign of the balloon and the expected time of launch  (both can be entered and saved on the Setup screen). You can select to output two types of APRS files. One contains nothing but the position, the other adds course and speed to the position. You can select "balloon" or you can set any icon character you wish. The protocols for and symbols used in APRS are listed in the documentation within the DOS version of APRS available from The Tucson Amateur Packet Radio group's web site at: http://www.tapr.org. This export routine works fine in APRS-Plus, but I don't use any of the other programs, so feed back to tweak it may be necessary.

• Version 1.5.8 (21-April-2000)

One new feature. On the setup screen you can now set the lat/long and magnetic declination of a VOR. The program will then calculate range and bearing from that VOR to the balloon for each reporting altitude in the printed reports. Some FAA folks may appreciate this. I know ours in Denver did. But each FAA contact will be different. These bearings may be of assistance to pilots who are participating in recovery efforts too.

Not exactly a new feature, but the setup screen was getting too cluttered. So, I've added tabbed pages to separate various categories of setup information. This tabbed dialog box requires the inclusion of a new OCX file. That is why a full download is required for this version.

• Version 1.5.7 (9-March-2000)
  
  Luis Briones and James Ewen both reported bugs with the ascent calculator. I've been trying to fix these problems but so far with little success. So, I'm removing the ascent calculator from the program. If these problems can be resolved, I'll restore this calculator.
  
  Luis Briones discovered that the program was incorrectly printing English measurement units when in metric mode. Fixed.

• Version 1.5.6 (2-January-2000)
  
  Luis Briones discovered that the lat/long converter wasn't working properly in his Regional Settings. I believe this is now fixed.
  
  Luis Briones also discovered that the Forced Landing Calculator wasn't handling the ascent/descent rates in Metric mode. That's now fixed.
  
  Luis Briones rightly pointed out you couldn't really read the labels on the charts. I just could NOT discover how to adjust this. But, finally the light has dawned and those labels are now lots larger making them somewhat legible.
  
  I also changed the Axis Titles to properly reflect the measurement system in use. If you're in metric, it says kilometers or meters, if you are in English, then feet and miles.
  
  For a little Gloss, I've added an internet URL link directly to the Balloon Track for Windows web pages on the "About" screen (under Help). Click on the URL or the EOSS Logo and off you go. Now you can replace the link on the "Internet Browser" screen with something more useful.
  
• Version 1.5.5 (25-December-1999)

  Joshua Rozovsky wanted more graphing of various data. I've added Lots of Charts to the program. This requires a download of the full installation file, as it contains some new (required) DLLs (charting). So for version 1.5.5, there is no "Lite" version available.

  Joshua Rozovsky's previous request to calculate a Lift Off site based on a predetermined landing site has been expanded. The "Reverse Calculator" is still available. However there is now also a "Forced Landing" calculator. You enter a lat/long for both the launch site and landing site. Balloon Track will calculate where the balloon will land by using 1000 foot burst altitude increments (starting at 10,000 feet above the launch site altitude). It will then display a table indicating which burst altitude caused the payload to land closest to the desired landing point as well as info on where each other altitude burst would place the package. You can set this up in reverse too, indicating you MUST land at a particular spot, the program will then show the burst altitude that will reverse engineer towards the desired landing spot. If possible you could then move your launch site to this location and theoretically land on the touchdown site. I will say this is really all fun and games. Variances introduced by delays in time, and distance from the NWS weather balloons makes these predictions fairly inaccurate anyway. But, it was a fun routine to add.

  Luis Briones discovered that you could overflow the program using extremely high rates of descent (no parachute). I've fixed that

   

• Version 1.5.4

  Luis Briones from Argentina found some bugs and had a request. First, the burst altitude on the main screen required English unit entry (feet) even when the system was set to metric. That's fixed and the label for the command button now indicates the unit of measurement expected in the input field - meters in the metric system, feet in the English system.

  Luis also wanted a way to manually select a balloon type on the ascent calculator. I've added a Generic option to the selections of possible balloons on that screen. And I've added a burst diameter field and a balloon weight field. These fields are locked and indicate the values of selected balloons when you pick one of the available balloon types. If you select Generic then the fields unlock and prompt you to enter values. This way you can calculate for balloon types not included in the preset selections.

  James Ewen has discovered a number of anomalies in the help balloons of the program. Hovering over some controls help balloons either asked for wrong information or more commonly asked for input in an incorrect measurement system i.e. when the system was set to metric, hovering over ascent rate would prompt the user for "Ascent Rate in Feet Per Minute" instead of Meters per Minute. I think I have all these problems resolved.

  James wanted a lat/long converter added to the setup screen. Done.

  James wanted COMM 3 and COMM 4 capabilities added to the Packet Data area. Done.

  James also discovered that, upon returning from the setup screen, the column headings on the main screen did not change from English captions to metric ones (assuming that switch had been requested) until a calculation had actually been run. That's fixed. Once you close the setup screen, whichever measurement system is selected will be reflected on the column headings on the main screen.

  Joshua Rozovsky wanted the ability to calculate azimuth and elevation for a secondary station (other than the launch site). That's been added.

  Joshua also wanted a way to calculate a LIFT OFF site based on the predicted track of the payload to a PRE-DETERMINED landing site. OK, that has been added. You have to run the program once with an arbitrary launch site. Once the program knows the bearing and range from that lift off point you can invoke the "Reverse Calculator". The program then opens a dialog box where you input the lat/long of your intended landing point. The program will then calculate a lat/long for a launch point that should result in a flight to the intended touchdown site. With all the possibilities for divergence from prediction, I don't know how helpful this will be, but it sounded like a fun addition so it's there now.

   

• Version 1.5.3

Joe Mayenschein, WB9SBD, discovered that one of the links on the Launch Browser screen was no longer valid. It was always possible to open "wxurls.ini" and manually edit it to change a web link. But, I've now added the capability to edit the URLs within the program. Open the Launch Browser screen. RIGHT click on the button you wish to change. An entry form will open. Enter the Name you wish to appear on the button in the top box and the URL (including http:// or ftp:// or whatever) into the bottom box. Click Save and that data will be saved to the "wxurls.ini" file and the Launch Browser screen will be updated. If you wish to blank out a button, just remove all text from the URL entry area on the form. When you save the data, the old URL and Name will be removed from the Launch Browser screen and the INI file.

I added another Folder setting on the setup screen. You can now specify to which folder you wish to save your ASCII and SA export files. If no ASCII folder is set, the program defaults to its home folder.

I've changed the titles on all the file dialog boxes to indicate exactly which open/save action you chose.

• Version 1.5.2

Luis Briones discovered a couple of more bugs when operating in Metric Mode. The descent rate on the Flight Synopsis screen was not being translated into meters per minute. The data on the Winds Aloft Chart was still plotting in English units. Both of these have been fixed.

I also added measurement qualifiers on the main screen (Altitude (m), Altitude (ft)) to indicate which measurement system is active.

• Version 1.5.1

A bug related to regional settings was discovered by Luis Briones. That's fixed

 

• Version 1.5.0

Luis Briones, LU6VG, asked for a metric compliant version of the program. I put this off for 4 months, sorry Luis, but this version incorporates the ability to work in either Metric or English units. The input data files still must be in the "proprietary" balloon track format or imported directly from NWS weather sites, but once within the program you can enter data for your home location, landing location and have all the output of the program converted to metric units of measurement. Generally speaking, feet are converted to meters, miles are converted to kilometers, ounces are converted to grams, pounds are converted to kilograms. 
The program is still working in the background in its own format, so metric data entered on the setup screen is immediately converted into English units. I mention this because you might peek inside the wbaltrak.ini file and be somewhat confused by the values you see there. Ignore them, refer to the setup screen and those English system altitudes in feet will be displayed in meters.

I also got rid of the double listing for maximum altitude. Assuming your maximum altitude in the wind data file was 100,000 feet, on the main screen you would see something like:

81 86515 107 40 21 1000 40.3009 -104.234 383
95 100000 104 43 22 1000 40.3242 -104.1669 414
95 100000 104 43 22 9534 40.3242 -104.1669 414
97 86515 103 44 19 6998 40.3276 -104.1574 383

I've dumped that duplicate record which cleans up the output somewhat.

81 86515 107 40 21 1000 40.3009 -104.234 383
95 100000 104 43 22 1000 40.3242 -104.1669 414
97 86515 103 44 19 6998 40.3276 -104.1574 383

• Version 1.4.9

Joe Mayenschein, WB9SBD, requested a new feature. It seems his group is planning an experiment in which they will try and use a helium balloon to "LOWER" the payload safely to the ground. They expect a fairly static descent rate rather than the precipitous one that usually occurs when a payload is separated from it's balloon. So, I've added a static descent rate option to the program. Select it and whatever descent rate you have entered will be used without any pressure modification. Set 1000 FPM descent and it'll take 90 minutes for a payload to descend from 90,000 feet instead of the more traditional 30 minutes with a parachute.

 

• Version 1.4.8

Added a new log file that captures the Altitude, Bearing, Range, Course and Speed (ABRCS) of the payload as well as a UTC GPS time stamp for that data. Last flight I was asked about the location of the balloon a few minutes ago. I didn't have that data available so ...

In the process of adding this new log file, I've revamped the way in which all log files are started. There is now a File Menu on the Packet Data screen. Open it and you can start log files for "raw packet capture", the "complete wind data file" and the new ABRCS file. When these log files are active a check mark appears next to the corresponding item on the File Menu. Selecting it again turns off that log file and the check mark dissapears.

I've changed the way the log files are formatted. Should be a little easier to read. Now, a header is written indicating what data is in each column when the log file is first opened. The data then lines up under that header.

I also realized I needed an easy way to View that ABRCS file, so I added a View Files option to the menu bar. Click it and you can open any text file. If you have started logging to any of the above files, the filename for each active log will also appear on this sub menu. You can click on it, and it will open in a View window.

Also, since these files are constantly being updated, I added a Refresh option on the View Screen's menu bar. Click it, and whichever file is being displayed will be reloaded with the latest data.

I discovered a bug. The wind direction was being incorrectly recorded if you had the GPS Diagnostic screen open. Fixed.

Bug, when opening the packet screen with the "Process Packet File" option, if you aborted, the program wouldn't recover. fixed

The help file has been updated to reflect these changes.

 

• Version 1.4.7

After the introduction of the Dashboard and GPS Diagnostics screens, I seem to have introduced a couple of programming errors. Log file would not be properly written, and the timeset function was setting the correct time but the incorrect date. - fixed 1.4.7

On EOSS's most recent flight, our APRS package was programmed slightly differently. Instead of sending  out GPRMC and GPGGA strings at the same time, they were sent at a 10 second interval. This generally confused the program and as a result, NO UPPER AIR data was collected. I've changed the way this is all handled. Now there is a 15 second window rather than the previous 10 second window. When a valid pair of GPS strings is received within this time window, the time stamp of the OLDEST string is used for the time stamp on the interval of 80 seconds between valid pairs before a new data record is created. These two changes should fix the problems encountered with GPRMC and GPGGA are transmitted with an interval exists between them.

 

• Version 1.4.6

A new feature. On the Packet Terminal Screen, there is a new command button, "Open GPS Diags". Open this screen and you'll see some diagnostics regarding the GPS receiver aboard your payload. In order for this screen to function, you need to have your payload transmit an additional NMEA string, $GPGSA. Whether or not you find this option useful, only you will know. But, the $GPGSA string is the only place where you can find out if the GPS receiver is operating in the 3D mode, thus putting out valid altitude data. This screen displays the Mode of operation the GPS receiver is in (manual or automatic), the type of fix the receiver is generating (no fix, 2D or 3D), the overall Precision of Dilution, the Vertical Precision of Dilution and the Horizontal Precision of Dilution factors, as well as a list of the Satellite PRNs used in the position fix. - added 1.4.6

The color decay feature on the dashboard could be mislead. If the payload GPS fails, many TNCs keep the last strings in memory and beacon them out. Balloon Track used to keep track of the arrival time of these strings to calculate the decay properties of the display. I've changed that. Now, the actual GPS UTC time from each packet is used as the time stamp rather than the packet arrival time. This means, Balloon Track will properly flag data as old if the UTC time stamp in the packet doesn't pass the decay rules as outlined in Version 1.4.4. - changed 1.4.6

• Version 1.4.5

  The help file was updated, but the hooks in the program weren't. Context sensitive help was sometimes missing. - fixed 1.4.5

  A bug quashed. If you opened the packet terminal, closed it and then reopened it, the program crashed. - fixed 1.4.5

  Strange but true :-) One of my computers displays the data in the Dashboard great, the other didn't work too well. So, I've added some formatting that has made the display match up on both systems. Hopefully, this will resolve any display problems others might have experienced. 1.4.5

  Shock!! All that problem with the time and date format ??? well, I slept on it and out popped the answer in the morning. So, All that blather about having to have your Windows Regional Settings set to English (US) are history. Now the program will operate with any time and date formats for both the Time Set and Color Coded Data Display on the Dashboard. Of course, you still have to set that UTC offset properly if you want your computer to operate on local time. - changed 1.4.5

• Version 1.4.4

  Updated the Help File. - changed 1.4.4

  Added a real-time clock to the Dashboard. Added the capability to set your computer's date and time from the received GPS data during a balloon flight. Note: All this time stuff requires your Windows Time setup to be in the North American Mode(i.e.: MM/DD/YY HH:MM:SS - in 12 hour format). Otherwise, the color codes below and the set time won't work properly. Hitting set time may really mess with your date and time if you're using any format other than NA. You can easily fix it by clicking on the clock on the Windows taskbar, but be forewarned. Sorry about that, but making this universal seems like a real tough job. I'll continue to look into it, but don't hold out any real hope at this time. - added 1.4.4

  A bug fixed. It's rare, but if the balloon is at the exact same latitude and longitude as the launch point, div/0 errors showed up. - fixed 1.4.4

  The values displayed on the Dashboard will now change colors according to these rules. If the UTC time of the last received packet is within 2 minutes 30 seconds of your system time, the text will be GREEN. If it is between 2'30" and 5 minutes, it will appear YELLOW and if it's older than 5 minutes it will appear RED. This necessitates a new variable, UTC Offset. You enter this on the Setup Screen. Enter how many hours your Local time is different from UTC. If you live in the Mountain Standard Time zone (MST), the difference is -7 hours, that is 7 hours earlier than UTC. Don't forget to enter the negative (-) or the display will always be RED. For this function to be meaningful, you'll also have to set your computer's date and time "exactly". The visual basic routines for time include the date, so be sure they are both set correctly. A few seconds either way won't make much difference, so if your clock is off, click on the clock on the Windows task bar and set the time when you receive a UTC stamped packet (or use the set time option described above). You'll be off by a bit (packet delay, TNC delay, GPS delay) but it'll be close enough to start properly using the color scheme. The idea here is to have a Visual way to alert you to the fact you're receiving OLD DATA. Maybe the GPS locked up or your TNC, or Balloon Track is experiencing a problem. Whatever, it's a good idea to be alerted to this problem at the soonest opportunity. - added 1.4.4

  Changed the Street Atlas Export Options. Now, from the SA Export Screen you can select any, all or none of the following, the altitude, elapsed time, as one item range+bearing+elevation, or footprint. The labels on the map now have labels themselves. ?? Well, when you select altitude you see "Alt=10000" instead of just "10000". This makes decoding the plots on the map easier, but a bit more cluttered. - added 1.4.4

   

• Version 1.4.3

  Some code polishing has occurred in this version. Some inactive modules have been excised, some debugging code removed. This should be an improvement. But, sometimes, bugs creep in during a process like this. So, don't hesitate to email me if you discover any.

  Lots of "ToolTips" have been added. ??WHAT?? When you hover your mouse cursor over an object (place it over an object without clicking), and text appears magically on the screen that text is a "ToolTip". Some of these "Tips" are just adding a bit of polish, but in other areas they may be quite helpful. Example: When you open the browser window, hover over one of the buttons and the actual URL of the site your about to click on  will appear. So if you don't know what something is or does, you might be able to find out by just moving your mouse over that object. The tooltips take a second or two to appear so make sure you deliberately leave the cursor over something for a bit to see if something pops up. All the buttons on the main screen have these (have had them for sometime, in fact). So you can get the feel of 'em by hovering over one of those buttons. Oh, if you place your cursor over something and don't get a ToolTip (not every object has one), and you think there should be one there, email me and I'll see about adding one for that object. - added 1.4.3

  My Balloon Track Folder was getting crowded, so, I've added the ability to specify two additional Folders (sub-directories) for the program to store and retrieve files. One is for data files, the other for Log files. Data files are the files that contain wind data, log files are just about everything else, all the raw and formatted capture files from the packet data area for example. Just go to the Setup Screen and either type in the names of the Folders you wish to use or click on the Browse button and select a Folder that way. If the folder doesn't exist, you'll have to use the Windows Explorer to create it. I may add that capability later. - added 1.4.3

  Something that's been lying in wait for the unwary has been fixed. If a balloon flight was taking place right around 00:00:00 UTC the program could become confused and miss capturing wind data from a payload if the two sets of data were separated by the rollover of the clock. Balloon Track uses elapsed seconds to validate wind data records and the easiest way to do that is to convert time of day, i.e.: 12:14:30 into 44,070. Comparing elapsed time from a packet received at 120 (00:02:00) and 86,280 (23:58:00) would seem to greatly exceed the validation parameters. So, I've opened a 10 minute moving window on either side of 00:00:00 in which the time strings are analyzed for this phenomena. As long as the difference in time is less than 10 minutes, they will all pass verification properly. But if you're beaconing out data once every 11 minutes, then the program may miss one wind fix. Not too likely, as more granularity is really needed anyway to accurately assess the winds aloft. - changed 1.4.3

  You can now toggle the Dashboard open or closed with the button on the Packet Data Screen. - changed 1.4.3

  On the Packet Data Screen, when you selected "Start Complete Wind Capture" the resulting log file was really badly formatted. I think I have everything lining up in neat columns now. Should make it easier to read. - changed 1.4.3

   

• Version 1.4.2

  I've added additional information to the "Synopsis Screen". In the Data File box, there is now a count of the good and bad records found in the data file. Previously the program just said "Bad Data File". This can be somewhat misleading. Now it indicates that there are "Errors in Data File", thus indicating the possibility (I hope) of a usable data file. Often there are a couple of blank records at the upper end of the RAOB. Balloon Track uses the last good record it finds to fill in these bad records. If there are only a couple of bad records, you'll probably get a good prediction. But, if you get massive numbers of bad records, your source file is probably in question. So, now when you view the "Synopsis Screen" you can see just how many data records were bad. This should assist you in evaluating the confidence of the prediction. This data has also been added to all the printouts. - added 1.4.2

  Not really a bug, just a suggestion to myself. Now on all printouts, the synopsis data appears alone on page one. If you are printing out a complete prediction with all data, the altitude by altitude data will start on page two and continue until all records have been printed out. - added 1.4.2

  With all this altitude stuff at launch added, I thought, what about touchdown? Here in Colorado, we fly out of the front range and land somewhere east. There's usually a significant elevation change. So, the program now has another entry on the Setup Screen for the altitude of the touch down point. Now, during the ascent phase of the program everything works as described below. But, during the descent phase of the flight, the Balloon Track computes out to touchdown altitude. This should improve accuracy somewhat when there is a great differential between launch and landing altitudes. Also, from the burst to the touchdown, the distance to LOS is calculated on the height above the touchdown location. When the balloon lands, it is considered to have an altitude of 1 foot (hoping that your antenna still points UP). This results in a 1 mile LOS range. The Elevation angle is still computed from launch site for the descent phase of the flight. This naturally results in a negative look angle if your balloon flies past your local horizon. When the elevation angle goes negative, it's a good indication that you'll no longer be able to receive any radio signals at the launch site from your payload. - changed 1.4.2

  I discovered some very minor flaws in the way the initial prediction point was calculated. Elevation and distance were slightly off. I've corrected this. - fixed 1.4.2

   

• Version 1.4.1

  Joe Mayenschein, WB9SBD, came up with a good suggestion. Include the elevation of the balloon as an aid to pointing antennas from a launch point. The data are available in the predictions but, during the flight the balloon invariably diverges from its predicted course. That's why a "Dashboard". So, I agree Joe, and now on that dashboard the bearing, range and ELEVATION are now available. This entails a new variable you should set on the Setup Screen for maximum accuracy. Your launch point altitude should now be entered too. During the initial few minutes after flight, this elevation thing will probably be a little inaccurate as the balloon moves rapidly in terms of angle of view. But, without a common frame of reference, the first few minutes would be totally meaningless. I let this pass in the prediction part of the program as it didn't seem all that important to know look angles while you could actually SEE the payload. But, might as well go for some accuracy here. So, the altitude setting should ensure a pretty accurate elevation angle. I've carried over the Launch Point Altitude setting to the prediction part of the program too, so that those numbers would more accurately reflect the true situation during the early minutes of the flight. See Bug notes below for additional information - added 1.4.1

  With the implementation of Launch Point Altitude to the Elevation Calculation in the predictions part of the program something interesting showed up. If you have a wind file that starts at an altitude below your launch point, it's possible to get a negative elevation angle. This also points out an inaccuracy of the prediction data itself. The program previously thought the balloon was flying through all those winds from an altitude below the launch point. This distorts the prediction in two ways. One, the winds might change completely by the time the balloon rises to your actual launch altitude. Two, the program is calculating the elapsed time of flight, distance and bearing using these erroneous numbers. I've CHANGED all that. Now, when Balloon Track starts up, it looks at the wind data file for the wind data most immediately below your launch altitude. When it finds the record most close to your launch point altitude BELOW you, it rewrites the altitude for that wind data record to your home altitude. It also resets the starting ascent point of your flight to this altitude and the first prediction is given for 50 feet above that altitude. It makes no sense to actually start a prediction on the ground as the balloon hasn't actually traveled anywhere. Anyway, this will result in some new elevation angles on the prediction report that may at first seem strange, if you were used to the previous output of the program. Now you will probably see much lower initial elevation angles than were previously displayed. This is because the program is accurately figuring the look angle from the altitude of the launch point to the first altitude of the balloon (50 feet) rather than the previous method which assumed a look angle from sea level to the balloon. In previous versions of the program that elevation angle always started out at a high 80s degree angle cause the program was looking up from sea level. Of course, this is all predicated on your launch point being at significant altitude. That's definitely the case here in Colorado. Of course if you launch from a minimum altitude, you'll hardly notice any difference. OK, ONE MORE THING. This is probably fairly common. Suppose the RAOBs you obtain for flight prediction are always ABOVE your launch point. In this case, Balloon Track will see that the first wind data record is located somewhere above you. So, it will rewrite the altitude to your Launch point altitude. This might introduce new errors. If your launch point is significantly lower than the RAOB data the surface winds may be different than those at the WX service location where the RAOB balloon was launched. Sorry about that, but you only have two choices. One, live with it. Two, estimate winds in your area and edit the wind file manually by adding a record BELOW the first data record provided by the RAOB data indicating the Altitude (your launch point) the direction the winds are coming FROM and the speed of those winds in KNOTS. Overall, I believe these changes will only make Balloon Track more accurate. - added 1.4.1

   

• Version 1.4.0

  I've added a "Dashboard". During each flight I'm often asked, where is the balloon, how high is it, how fast is it going, how far from the launch point is it and on what bearing. Well, now you can answer all those questions with Balloon Track. Open up the Packet Data/Process Incoming Packets. Enter the target callsign, press the dashboard button then press start capture. Needless to say, you have to be connected to a TNC. As the data arrives it is displayed on the dashboard. NOTE: The data between the packet radio screen and the Dashboard will not always sync up. The data captured for wind files is limited to one record each two minutes. The Dashboard will display all data received. - added 1.4.0

  Mark Conner, N9XTN, is never satisfied ;-). He suggested I implement an alternate tag for the plots on the Street Atlas file. Now, when you select File/Export/Street Atlas File you'll notice a couple of new options for the labels. Previously, you could have the altitude appear next to each plot or turn it off. Now, you can tag the plots with the altitude or the elapsed time of flight, or both or nothing. - added 1.4.0

   

• Version 1.3.9

  Mark Conner, N9XTN, keeps coming up with valuable suggestions. He wanted the program to save ASCII delimited text files specifically formatted for use with Street Atlas USA (www.DeLorme.com). I was unaware of this capability within SA. So, thanks Mark. I've added this capability. Run a prediction - then from the main screen file menu select export. A sub menu will open with two choices, Comma Delimited and Street Atlas File. Select Comma Delimited and everything displayed in the prediction window at the bottom of the main screen will be written to a file suitable for import into most spreadsheet and database programs. Selecting the SA option will take you to a form where you will have to select an Icon, Icon size, Icon color for the ascent phase and Icon color for the descent phase. You can also turn on or off altitude labels for each plotted point on this screen. When you click OK, the program will write these settings to your current INI file (so they become your default), prompt you for an output filename and save the file and return to the main window. To view the file in Street Atlas, open that program, from the file menu select import lat/long file and pick the file you just exported. Note: SA will NOT center on your imported data, so if for some reason your map screen in SA is zoomed in to New York, and you're plotting a balloon flight in Denver you won't immediately see it. Zoom OUT until the track appears. Then zoom in on it. - added 1.3.9

  I added a couple more buttons to the Launch Browser screen. - added 1.3.9

  Ini File parsing should be more reliable now. I changed the way that was working - changed 1.3.9

  The Process Packet File was flawed. Would only read a file 1000 lines long. That seemed adequate until our last flight. This was an arbitrary limit so I've arbitrarily increased it to 100,000 lines. I can't envision a flight that develops more data than that. - fixed - 1.3.9

  I changed the way winds are displayed on the "View Winds" screen. Previously, it was setup to show the winds just as they come from the WX service, I.E.: direction the winds were coming from. Most of us are interested in where the balloon is going, so that screen is now relabeled as "Flight Direction" (once you get to it), and the direction indications denote the path the balloon will be traveling at any given altitude. - changed 1.3.9

   

• Version 1.3.8

  Glenville Sawyer, VK5ZCF, of the South Australian Amateur Radio Balloon Experiment discovered a known omission on my part. Actually, he asked if the program would work for him. I checked it out and discovered that the way I was handling latitude/longitude computations would not work in the Eastern Hemisphere (positive Longitudes). So, I kicked the code around a bit, and now the program will accurately calculate lats and longs for anywhere (I think - haven't checked a cross polar scenario yet). - fixed 1.3.8

  Bill Davis, KG5IE, of the North Texas Balloon Project (NTBP) has discovered a bug. The computations on the Actual vs. Predicted touchdown screen displayed incorrect bearings. - Fixed 1.3.8

   

• Version 1.3.7

  Me again! There's a new selection choice on the main screen's menu. "Launch Browser" will bring up a form with three buttons. Click one of these buttons and your default browser will launch and go to the specified URL. These three buttons are customizable. There is a new INI file named "wxurls.ini". You can specify up to three URLs here. Open and read the INI file for information about its format. If you leave any or all entries blank then the program substitutes "Browser no URL" as the button label and launches the browser alone. You can then use your bookmarks or favorites to select a site. I've supplied two URLs in the wxurls.ini file. So, the program sets the third button to only launch the browser. I like it best this way as I can select any of dozens of WX sites from my favorites list or go to one of the two RAOB sites. The nice thing about this feature, when those URLs change/disappear/ or whatever you can edit it yourself for current sites. - added 1.3.7

   

• Version 1.3.6

  Rick von Glahn, N0KKZ. Hey I can sometimes come up with something!! When you load a data file its filename appears on the Main Window Title bar. - added 1.3.6

  Mike Manes, W5VSI, suggested I add FAA reporting altitudes to printouts. This was years ago. But, Mike, I've remembered and done so. On the main program screen is a button labeled "Add FAA Reports". Press this button and the program will add wind records to the data file (only in program memory) for 10,000 ft., 12,000 ft., 14,000 ft., 16,000 ft., 18,000 ft., 20,000 feet, 23,000 feet, 24,000 feet, 45,000 feet and 60,000 feet. Then when running predictions, the data for balloon position will be available for those altitudes. If you file flight plans and communicate with the FAA during flights, they want some or all of this information (ie: location in some form at these specific altitudes. - added 1.3.6

  Mark Conner, N9XTN, had another idea. He wanted to be able to save the Plot/Track display to a .BMP file. I've struggled and struggled, and finally figured out a way to save ONLY the graphics. There's now a button on the plot screen "Save BMP". Push it and the file PLOT.BMP will be created. None of the text that appears on that screen will save to the .BMP file, but this may suffice. Note: you guys can hit the "Print Screen" button on your keyboard and EVERYTHING on screen will be saved to the clipboard. Open Paint/Paintbrush or any paint type program. Select new file, and enter your screen resolution as the size of the picture (ie: 1024x768 or 800x600 or whatever your screen rez is set to). Inside the new image or on the edit menu click paste and presto, a snapshot of your screen appears. Use the crop tool and crop down to only the plot display and bingo, you've got a BMP you can print with all the text data. Hey, I know this is a lame way to do this, but, I've poured over VB5 for several hours and can't seem to get a handle on how to capture the entire form to a bmp, only the graphics drawn on a form. If anyone knows the answer to this quandary, email me! - added 1.3.6

  Mark Conner, N9XTN, had a good idea. He requested that I add a method to set the burst altitude. Sometimes, the winds are available to an altitude greater than you expect you payload to reach. Sometimes, the winds aren't available to that expected maximum altitude. Now, on the main screen, you can enter a burst altitude, push the "Select Burst Altitude" button and the program will compute the predicted touchdown for a payload that reaches that altitude. When the winds data are good to levels higher than you selected burst altitude, the program looks at the last wind data record below your selected altitude and uses the wind speed and direction to create a new record at your burst altitude. And, if the wind data file ends below your selected burst altitude, the program lifts the wind speed and direction from the highest data record and uses it to create a new highest data record with that information. Be wary of this latter option. If winds are good only to 30,000 feet and you enter 100,000 feet for your burst altitude, you'll be presented with a prediction that probably will bear little in common with reality. The balloon may go through a jet above, 30K, the winds may reverse direction at higher altitudes, hey almost anything could happen and the program is essentially wild guessing. However, if you have winds to 106,000 feet and your flying to 95,000 feet this feature should really help out as you have valid data at that 95,000 foot level. All data generated by the program will reflect the burst altitude you enter. However, the actual wind data file will NOT be changed. So if you look at that file in the frame in the upper right corner of the main window, you won't see any change. But, the prediction window below will show the proper data, the plot, synopsis and wind chart screens will all properly reflect your arbitrary burst altitude and all the printouts you might run will likewise show that burst data. When you hit the "Select Burst Altitude" button the text in the button changes to "Revert to Wind Datafile". If you punch it then, and run a prediction, the entire wind file will be used exactly as you see it in the view frame in the upper right. - added 1.3.6

   

• Version 1.3.5

  Mark Conner,  N9XTN, found a program bug. When importing a GPS file via the Packet Data Menu, the program would still try and initialize a comm port. Because Mark had his modem on comm1 (default comm) the program bombed. I've fixed that section of the code so that, if you're importing a GPS file, the comm initializations aren't run. This should clear up that problem. Mark did say the import worked fine when he switched to another comm port, but that shouldn't be necessary. Thanks for the report Mark. - fixed 1.3.5

  Charlie, KC5NBH, reported some confusion regarding the input screen for the ascent calculator. It wasn't too clear what unit of measurement was being requested for some fields. I've added labels to dispel uncertainties. - fixed 1.3.5

   

• Version 1.3.4

  Roger Sellers, N5EEA, requested a way to import previously saved NMEA files. Actually, during the testing phase of the packet radio module, I had some code that did just that. The code was still hidden in there, so I've linked it into the program. Now, on the main screen if you select "Packet Data" from the menu, you'll be given a choice of capturing incoming packets or processing a file. If you select processing a file, the program moves onto the packet screen as before, but if you hit "Start Capture" instead of looking at the TNC, the program will prompt you for a filename and then process that file. I would strongly recommend you fill in the Callsign of your payload so that the program doesn't garble up the data with packets from chase vehicles, if they are visible in the capture file. See the README.TXT file in Ver. 1.3.3 or later for more info. - added 1.3.4

  Roger Sellers, N5EEA, found a "sort of" bug. Some Zip utilities for Windows95 apparently don't always handle long filenames. So, ExampleImport.txt and SampleWinds.dat weren't being properly installed. I've changed those filenames to conform to the old 8.3 file naming convention and this should banish that bug. - fixed 1.3.4

  Charlie, KC5NBH, discovered a bug. The program crashes when either the latitude or longitude on the setup screen is set to zero. If nothing or zero is entered into either of these parameters, the program will substitute .0000001 for latitude and -.0000001 for longitude. - fixed 1.3.4

   

• Version 1.3.0

  Added two more calculators. Using BALLIFT9.BAS and DESCENT.BAS, two other Bill Brown programs as a core, I've included calculators that will figure both ascent and descent rates. The "Calculator" option has now become a cascading menu with these two calculators and the one in Ver 1.2.9. - added 1.3.0

   

• Version 1.2.9

  Added a calculator of sorts. On the Main Screen menu bar, there's a calculator option. Click this and you go to a screen where you can enter the actual latitude and longitude of the Landing Site after the balloon flight. The program will calculate a range and bearing from the launch site to that new touchdown point and also calculate a range and bearing from the predicted touchdown point giving you an indication as to how accurate your original prediction was. There's a print command on that screen. If you punch it, the summary data that appears in regular flight predictions will be printed with the addition of the comparison data at the bottom of the printout. - added 1.2.9

   

• Verson 1.2.8

  Two new logging functions. One, a raw packet log. Whatever your TNC sends to the computer is recorded in a log file. The second, a hybrid wind data file that includes the regular information and adds a time stamp (provided by the UTC time string in GPS packets, and a tag indicating the source of the data in the record, either pure GPS or estimated data. - added 1.2.8

  After discovering GPS would not give course, speed and altitude above 30K meters, I've added a wind estimator to the program. GPS will still give latitude and longitude. From this, a course and speed can be determined. Using a moving average of the ascent rate from the last 4 reports, I've fudged the altitude. This should be close enough for prediction purposes. - added 1.2.8

  Don Fraser, WA9WWS, reported (and showed me on his laptop) that balloon track installed TWO directories when installing. I couldn't get my installs to do that, but I "recompiled" the setup template from scratch. I hope this fixes the problem for others.

  Not a bug but two requests.

  • Tom Isenberg, N0KSR, didn't like seeing repetitive WARNINGS when importing wind files with errors (over the internet). So, I've changed that. Now the program will count the number of errors it finds during an import session and report that total in one error message for both the wind direction and wind speed at the end of the import run. - changed 1.2.8
  • Don Fraser, WA9WWS, thought the speed indicator on the plotting screen was a bit confusing. (See the screen shot above - it hasn't been changed to reflect the updated nature of the control) Instead of calling this "Plot Speed", it's now called "Plot Delay in Millisecs." This should make that clearer. We discussed having the lower numbers represent slower speeds, but it would have involved a bigger effort to make that happen, and I thought this fix might suffice. If anyone else hates it, let me know and I'll do the complete revamp of that control.  - changed 1.2.8

  Variations in the date field caused problems when importing internet upper air files. - fixed - 1.2.8

   

• Version 1.2.7

  Lots of errors were possible if some of the options were selected prior to loading a data file and running computations. These have been eliminated. - fixed 1.2.7

   

• Version 1.2.6

  Added a upper air wind profile chart. Selected from a command button on the main screen, the program displays a chart with speeds along the x axis, altitudes along the Y axis and plots a line indicating wind speed at various altitudes. - added 1.2.6

  The format of filenames for imported files saved back to disk has changed to sort them better. Used to be DEN_0000Z 98 MAY 15.DAT now its going to be DEN_98_05_15_0000Z.DAT. This means directories displaying sorted names will list dat files in chronological order. - added 1.2.6

  A font problem encountered. When Small fonts selected (desktop/properties/settings), displays garbled - fixed 1.2.6

   

• Version 1.2.5

  The View window now resizes. You can stretch it to view wide files.- added 1.2.5

   

• Version 1.2.4

  Type mismatch in winds files with wind speeds of 0 mph - Fixed 1.2.4