|
Home
Version History
Known Bugs
Downloads
Program Overview
Importing Data
Exporting Data
Utilities
Source Code Statistics
Mailing List
| |
Older Versions History Report
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.
Intermediate fixes, no records of what they were (drat).
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.
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.
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
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.
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.
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.
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.
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.
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.
- The Kenwood D7 packets were not being charted at all. That's fixed.
- 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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
A bug related to regional settings was discovered by Luis Briones. That's
fixed
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
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.
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.
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.
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
|
