IMPORTANT: This module of the program has been superseded by the ability to run log files through the Packet Terminal in simulation mode. Therefore, some packet types will NOT process properly through this module. I need to leave this in the program for now because it has some totally proprietary EOSS decoding algorithms I need to process old log files. At some point I will move those decoders over into the Packet Terminal part of the program and then delete this module.
So, you can try and run a log file through this decoder. If it works fine, if not, run the file in simulation mode to extract the data into usable spreadsheet files.
The best wind data you can use for predicting a touchdown would be that obtained during the ascent phase of the flight. This is exactly what importing GPS or APRS data will provide you. See Prediction Example for some screen shots of this capability as tested (post flight) on the data received during EOSS-46.
You must be flying an APRS or GPS equipped payload, and it must send down specific data to the ground via packet radio (formats listed below).
Remember to open a log file at or prior to liftoff of your balloon in either Balloon Track or your APRS or Packet program and save the PLAIN TEXT LOG of all received packets from your balloon.
Some APRS programs save data in a proprietary format, but they usually also allow for logging of plain text files of the received packet data. Make sure you open such a plain text log file.
Red and Yellow Warning boxes only appear under
limited conditions described below under "Warning"
Once your balloon has burst, or you have cut down your payload, click on "Packet Data" on the main screen and select Process Packet File.
When this screen first opens, it is relatively blank. However, as you will see below, once you select a source file the program will make a few educated guesses.
The program will use the Flight Call Sign (as set on the setup screen) to fill in the Callsign Key.
The first time you run this screen the default value for the "Minimum Altitude Interval between Data Points in Feet" will be 1200. However once you change this value it will be used in all subsequent program runs. It is saved to the ini file.
Depending on which type of data is imported, the program will either use the ascent rate as entered on the setup screen or the ascent rate as calculated from the data.
If the input file contains GPS data, the Ascent rate is calculated.
If the input file contains an APRS string with GPS generated time stamps (types 1 and 3 shown in formats below), the ascent rate is also calculated.
However, one obsolete APRS string (type 2 below) is supported that does not include a time stamp. In that case the program REQUIRES an ascent rate to calculate the remaining values.
You can change the ascent rate on this screen. Changing the ascent rate and selecting to Load the new data file (see below) will change the ascent rate in the prediction routines of the program to use that new ascent rate. However, the setup screen will retain the old ascent rate value which will be saved to the INI file, should you make any changes that require that file be re-written.
Balloon Track generates wind direction and wind speed for different layers of the atmosphere by comparing the current packet being processed with the previous packet processed. I recently produced some graphs for EOSS-53's recap pages to show this. You can go there and see that BT generated data is fairly consistent with GPS provided data.
First, click on the Source File browse button (at the top). The program will use the directory (folder) entered on the setup screen's locations tab as the default directory, however, you can change this when the dialog box opens. Then, select a file that was received via TNC from your balloon that contains either GPS data formatted in NMEA strings or an APRS formatted file that conforms with that of EOSS's Cross Band repeater.
Once you have selected a source file, the program quickly looks in this file and determines which callsign repeats most often. It guesses that this is your payload and sets that callsign as the "Callsign Key".
Next it looks at the type of data. If it sees more NMEA data strings than APRS strings it guesses the format is GPS, otherwise APRS. If there are an equal number of each type of strings then the program leaves the default APRS selected. This will probably only happen if you open a file with NO recognizable data of any kind.
These guesses are not written in stone. If they are wrong, just enter the correct values for the Callsign Key or data type and those values will be used.
Next tell the program what name you wish the output data file to have and specify either "Balloon Track" or "CSV- Comma delimited", a format suitable for import into DB or Spreadsheet programs. The program will suggest a filename and point to the directory you specified as your default data file directory on the setup screen. You can use it or not as you choose. The suggested name will be in the format of the name of the flight as set on the setup screen along with the computer's system date and will look like this:
EOSS-47_01_01_16.dat
or perhaps
EOSS-47_01_01_16.csv
if you elect to export a CSV file.
That system time is in the format of YEAR (2001), Month (01 for January) and day of the month (16). This format sorts out nicely on directory listings if you precede it with the same flight name.
One thing to keep in mind, your Flight Name must not contain any characters that would confuse the filename, like a backslash. If you entered EOSS\47 as the name of the flight then the program would suggest:
EOSS\47_01_01_16.csv
That would create a new subdirectory named EOSS and a file by the name of 47_01_01_16.csv in that subdirectory.
Next, if the callsign of the packet data for you payload does NOT agree with the Callsign key on this screen, highlight your payload's callsign in the "Import File (Pick Callsign Key)" text window as shown above in the screen capture and copy it and then paste it into the Callsign Key box above. Balloon track needs this data to properly identify packets from your balloon payload.
Next select the proper input format. Either "APRS" or "GPS". This is important as the program needs to know which extraction parsing routines to use. Hopefully the "guess" was correct.
If you select an APRS format and are receiving the obsolete type of packets (type 2 below), you must enter the ascent rate for you balloon as the program needs this information to calculate some of the values. The default value from the setup screen is initially set in this box. See the notes below about how the program works.
You can check or uncheck the "Omit Home Station Lat/Long Checking" box. See the Warning section below to discover just what effect this check box might have on your predictions.
Click on either "Make Data File" or "Run Post-Burst Prediction. The wind data file is displayed in the output text box, and the data file is written to the file name you selected.
IMPORTANT: If you elect to load the data into the program ("Run Post-Burst Prediction"), a new prediction is immediately generated. This prediction is made using the "Drop Mode" of prediction. Balloon Track temporarily resets the Home Latitude and Longitude to that of the Balloon at Burst. It also lifts the GPS time and will use it in the prediction if "real time" instead of elapsed time is selected on the Setup Screen. When the program runs, it starts at maximum altitude and plots the course of the balloon as it descends from the burst point to the landing site. Once the prediction has run the original Home Latitude and Longitudes and Launch times are restored and the prediction mode reverts to that indicated on the setup screen.
If you select Balloon Track Format, the exported file will contain:
Altitude
Wind Direction (from)
Wind Speed (knots)
If you select CSV as the exported file then, depending on the data available, the following values will be included:
Time(UTC) - in serial form as received from GPS if available, otherwise calculated from elapsed time
Elapsed Time
Altitude - from GPS
Wind Direction (from) - calculated between altitude intervals
Wind Speed (knots) - calculated between altitude intervals
Latitude - from GPS
Longitude - from GPS
GPS Track - from GPS if available
GPS Speed - from GPS if available
Ascent Rate - calculated between altitude intervals
See the Notes section on the Callsign Counter Page on how to use this "Serial Time" in a spread sheet.
In order to properly produce a prediction, Balloon Track must use the same ascent rate that you either set into "Force Ascent Rate" input box or the ascent rate as determined by analysis of the data. When you click "Make Data File and Load Into Program" the ascent rate as entered on this form (or derived from the data) will be used for all subsequent predictions in Balloon Track. You can restore the value as entered on the setup screen by opening that screen, and clicking on "Close Use these Settings". If you wish to change the value of the Ascent rate on the Setup screen to match the one you used on the Extraction screen you will have to do that manually.
If you have set a burst altitude, and enabled it, that option will be ignored when you load a data file directly from this Extraction Screen. Theoretically, the program has detected actual burst altitude from the APRS/GPS file and it will use that data point instead of an arbitrary burst point.
These two files were generated by Balloon Track in its export routines. The ultimate source for the data is the log file from EOSS-47. You can use these programs to test this process and in the Simulation mode (Packet Page). You might just use them to help design payloads. The APRS file follows the conventions used in String 1 shown below in the APRS section.
For GPS calculations the program only needs the NMEA string $GPGGA. But, it must be preceded by a callsign to be properly identified. Secondarily, if the $GPRMC string is available, the balloon's current course and speed will be extracted. It is only used in a CSV export. The course and speed of winds aloft are calculated from position movements occurring with changes in altitude, not the momentary reports of the GPS course and speed.
Here's a strange packet we sent out recently in a test of a Mars (Military Amateur Radio Service, not the planet) system payload.
NN0RPM-11>MARS,GATE,GATE,WIDE:$GPGGA,195619,3925.6554,N,10438.4935,...
I cut out the remainder of the standard $GPGGA string to save space on the web page, but the important thing to note here is that there is a callsign beginning the $GPGGA string and that the program will ignore the unproto path (MARS,GATE,GATE,WIDE). That unproto path is ignored in the APRS formatted strings too.
For APRS data the string can be in one of the four formats shown::
W0WYX>APRS:@164054h4026.59N/10450.62WO095/041/A=020729
W0WYX>APRS:@4026.59N/10450.62WO095/041/A=020729 (NEW)
W0WYX>APRS:!4026.59N/10450.62WO Alt = 20,729 Feet.
W0WYX>APRS:@164054h4026.59N/10450.62WO095/041/ Alt = 20,729 Ft.
They will be automatically recognized by the program.
The first two strings are 100% pure APRS format.
The last two strings are variants of semi proprietary EOSS strings. The initial part of the string is APRS format, however the altitude is in the "comment" area of the packet and thus, not decoded by APRS programs. EOSS has changed the RMRL repeater's APRS string to that shown in the first example and abandoned the proprietary second two.
Another important consideration using the Second APRS format is that you MUST have an accurate ascent rate calculated for the program to determine the speed the balloon is traveling horizontally. Since there is no time stamp in this string, the program calculates speed by finding the differences in altitude between the previous and current positions, then calculating a time interval for that distance covered in ascent by using the ascent rate (current altitude - previous altitude) / ascent rate). When the time interval is known, the speed is calculated by (distance covered in nautical miles * 60 / time interval).
The GPS string $GPGGA includes a time stamp, latitude, longitude and altitude. The program works as above, however it calculates the ascent rate by determining the interval in minutes between the previous and current position fixes using the time stamp included in each $GPGGA string.
Also a note about the number of records generated. The program will only generate a new record if the difference from the previous altitude to the current altitude in the input file is equal to or greater than "Minimum Altitude Interval between Data Points in Feet".
You should experiment with verified data to determine what interval works best. The greater the interval the more averaged speed you get for that altitude level. However, if you set it to a value too large you may miss wind shifts in different layers of the atmosphere. So far, with the data files I have on hand, a value of around 1200 feet seems to be working pretty accurately.
If you get strange results, you might come back here and read this carefully. Understanding how the program develops this data might help you to eliminate any problems.
This routine uses the altitude, latitude and longitude of your launch site as entered on the setup screen to determine the data for the first record of the wind file.
After you press either of the "Make Data File" buttons, the program will calculate the speed of the balloon for the first data point by determining the distance from your Home latitude and longitude and the first lat/long for the payload (above your home altitude) in the data file. It will then calculate the difference in altitude from your home station and the altitude of the balloon at the first altitude in the data file. Then either using the forced ascent rate, or the calculated ascent rate, it will find the elapsed time to ascend to that altitude. Speed = distance/time.
Once the speed is known, the Extract routine runs a check on the FIRST and only FIRST data point to ensure that the balloon is NOT traveling faster than 20 knots. Anyone who can launch a balloon that sustains an average speed of 20 knots during the first few thousand feet of ascent is incredibly expert in balloon launches. Usually we try and launch in winds no more than 10 MPH (8.7 knots).
If the speed is greater than 20 Knots, Balloon Track believes your home location is in error and it produces the WARNING box shown in the snapshot above.
Depending on the status of the "Omit Home Latitude/Longitude Checking" check box, the program either discards this initial data record, and continues to build the data file or includes possibly invalid information in the data file.
All subsequent calculations (after the first) will ignore the 20 Knot speed limit and you will have a data file that should be good. However, if you load the file into Balloon Track for a prediction, that possibly bad home location data may significantly degrade the accuracy of the prediction.
If the speed for the first data point is under 20 knots, a green box is displayed with this message
and the program generates a full wind file. Checking or un-checking the "Omit Home Latitude/Longitude Checking" will have no effect.
I checked this box for the web page snapshots to illustrate the problem detailed below. Normally, you should not check it so as to ensure you get the most accurate possible winds aloft data.
If you check the box then any possible errors in your Home coordinates will be ignored and all data will be used in creating the data file. However a warning will be displayed as shown (Red text on a Yellow Background) on the full screen snapshot above. It is RED to alert you to a possible serious error in your wind data file.
Note in the above full screen shot that the first record in the output window is:
7294,167,3479
This translates to 7,294 feet above sea level, winds from 167 degrees true at 3,479 knots.
If this record was imported into the prediction part of the program, Balloon Track would calculate winds from the Home station's Altitude up to 7,294 feet as a monolithic block of wind traveling 3,479 knots from 167 degrees. In this example, the home location data was in fact in error and set to a location 107 miles SSE of the real launch site. This "alert" would greatly improve accuracy of the prediction if you were prompted to properly set the correct launch site coordinates.
If coordinates for the actual launch site are unavailable, then un-checking this box will ensure that you get valid wind data for all available levels of winds. This will result in a much more accurate prediction, even if you are missing the surface winds!
If you leave the check box unchecked (default) and an error is detected then the box displayed above in Red with Yellow text would change to a Yellow box with Red text.
It is Yellow because, while you have lost the surface winds, it isn't as potentially serious as a bad home location data point inclusion might have been. The wind data file would start with the second record shown in the screen snapshot above (8505,310,20) which is good data.
When unchecked, if the speed of the balloon at the first data point is faster than 20 knots, the program ignores your home latitude and longitude. It then creates the first data record by comparing the first airborne packet in the input file with the second. The program does NOT calculate surface winds (home location to first airborne packet).
The program will check to make sure that the first packet used MUST be at an altitude above the altitude set for your Home Location (setup screen). If you set this value incorrectly, the first wind data file record will suffer in accuracy.
Enter, as accurately as possible, the latitude and longitude of your launch site. It's critical for the speed calculations for the first data point generated. After that first data point subsequent data will calculate properly regardless of your settings for your home location.
Enter the altitude of the launch site as accurately as possible.
I will consider writing parsing routines for any STANDARD format. If you use some other APRS string, send me examples of your data. If it conforms to the APRS standard formats, I will implement it. I know some APRS strings include time stamps. If you fly using this type of string, send me examples and I'll code for it.