EOSS Upcoming Flights
-
10/19/2024 - 00:00 to 23:45
-
11/02/2024 - 00:00 to 23:45
-
11/09/2024 - 00:00 to 23:45
-
11/16/2024 - 00:00 to 23:45
-
12/07/2024 - 00:00 to 23:45
-
03/22/2025 - 00:00 to 23:45
-
04/05/2025 - 00:00 to 23:45
-
04/19/2025 - 00:00 to 23:45
-
08/02/2025 - 00:00 to 23:45
Flight Records
Flight Records takes the place of the old ABRCS file (Altitude, Bearing, Range, Course and Speed).
Commands
Include $GPRMC
Indicates the current state of the displayed data. If you click it, the caption for this button changes to "Skip $GPRMC" and those strings will NOT be visible on screen.
This button has two different behaviors. If you are capturing LIVE data from a payload then clicking on it will only remove $GPRMC data from the display. It will NOT remove the data from the file being created during the flight. In this way, you can toggle on or off the display of RMC data but you never lose any RMC data during a flight. It will still be available in the data file.
But, if you are in simulation mode, clicking to "Skip $GPRMC" will not only remove the RMC data from the screen, it will also omit it from the data file.
Why did I do it this way? After a flight you might want a nice and neat file with contiguous altitude reporting and feel you can live without the extra information and GPS track and speed. This "clean" file will graph much better than one with the gaps present in a file that includes RMC data.
So, during a flight you will never lose RMC data, it just disappears until you click on the button to bring it back. During simulation, the data is NOT written to the data file.
Delete Data
Hitting this button will erase the data file. Unless you are awfully certain, ignore this button. Data from multiple flights may appear in a single data file but, you should be able to discern the difference by the time stamps, altitude, position info. And, after the flight, you can go into the data file and edit it, perhaps extracting the old data to a separate file that might relate to a previous flight.
During a recent flight our Tracking and Recovery team needed the Grid X/Y coordinates at a specific time in the past. However, no one had that information readily available. I did have the bearing and range for that time but no X/Y. So, I've written this little module.
Each time a packet arrives from the targeted station (the balloon), the program now writes out a data file to your "Logging Folder" if one is set or to the folder where Balloon Track is installed if no Logging Folder is set. This file contains all of the above information and is automatically written regardless of whether or not this screen is open. So, at any time during a flight you can click on [View/Record Flight] from the menu on the Packet Terminal screen and see the entire history of your flight
The data file is named "Record_yyyy_mm_dd.csv", where yyyy is the current computer system clock's year, mm is the month and dd is the day. I am assuming that all flights will take during a single date, meaning, you don't launch at 23:00 local time and have the balloon up in the air at around 60,000 feet when the date changes on your system clock at midnight. If it does, then the program will open a new data file with the new date. You won't lose any data long term (the original data is there on your hard drive), but the data displayed on the screen above will suddenly look pretty barren as all the data prior to midnight will disappear. If this is a problem, I could code in a routine that would compensate for this problem. Let me know if you need this "fix".
This is a comma delimited data file which you can load into any spread sheet program after the flight. Don't load it into a spreadsheet during the flight as most spread sheets lock the file once opened thus rendering Balloon Track incapable of updating it. Might cause BT to crash ... I'll have to check on that.
You'll note that the most recently processed data appears on the first line and ages as you look down the columns. In the example above, the last (most recent) packet was received at 15:20:59. But, if the tracking and recovery guys wanted to know the X/Y coordinates of the balloon at 15:15:00, I could easily look down the table and pull out negative 4.5, 23.1 as the X/Y coordinates for the packet received at (or at least close to) that time.
In the example above, the data was derived from a simulation so the System time is substantially out of phase with the flight times. In a real (live) capture the system time would match pretty closely with the GPS time (except that it would be off by what ever amount of offset exists between your station and UTC). the important thing here would be that the minutes and seconds should closely match. If they don't then perhaps there is either a problem with your system clock, or perhaps the GPS is having problems. They will never be in exact sync as it takes time for the packet to be encoded aboard the balloon, transmitted to the ground, decoded by the TNC and dumped into the program's data pool. But, they should be fairly close in time. I'll be interested to see just how much latency exists in a future flight. Have to make sure I sync my computer to UTC first though.
The rest of the data is derived from the APRS or GPS packets received.
You will note some records contain no altitude related information, while others contain no GPS track or speed data. This is because the data downloaded from the balloon on this flight was in NMEA format. In that format altitude comes within the $GPGGA string and GPS track and speed data arrives with the $GPRMC string. Both strings include a timestamp and latitude/longitude information so the other fields can be calculated.
If you are using the "EOSS approved" :-) APRS packet format then all data will be filled out. Clicking on the "Include $GPRMC" will change it to "Skip $GPRMC", however it won't actually have any effect on the processing of the APRS received string.
If you need to keep track of the "history" of the flight while the balloon is still up there, this screen might be useful.
If you do not use a Grid (like EOSS) then those values will be blank. You might enter your launch site as the Grid Reference point (setup screen) and give it an X/Y coordinate of 0,0. Then the program will produce X,Y coordinates that indicate how far east and north of your launch site you are. Negative numbers indicate a location either South or West.
I would recommend that you include the GPRMC string data if you are flying an APRS system that transmits either both NMEA strings or the "EOSS approved" APRS formatted string. That way you'll have the maximum amount of data available to you during the flight. Even if you omit the RMC data temporarily, during a Live mission the data will still be available in the data file as described above.
If you are using the dual NMEA string data format ($GPGGA/$GPRMC) then, after the flight, you might want to run the captured log file through the packet simulation system (accessed from the Packet Terminal), disable the GPRMC strings and extract a file that contains only GPGGA data. This may plot more smoothly from within Spread Sheet programs. If you do run the captured log through the program in simulation mode you might want to be sure you rename the original "Record_yyyy_mm_dd.csv". Otherwise, your new data extraction will be appended to it.
Warning
One little word of warning. In order to ensure that the data is displayed in descending chronological order, the data is sorted prior to display. The field sorted is SYSTEM TIME, not GPS time. So, the warning, if you run the simulation rate up to a speed greater than one record per second, the display may become jumbled as the program will see two or more records "received" at the same time and have no intelligent way to determine which record comes first. This has NO effect whatsoever on the source data file. So, if you are just trying to create a CSV data file, run the speed up to whatever you wish. Even thought the display may be a bit confused, the data file will be just fine.