EOSS Upcoming Flights
-
05/04/2024 - 00:00 to 23:45
-
05/18/2024 - 07:00 to 14:30
-
08/03/2024 - 00:00 to 23:45
-
10/19/2024 - 00:00 to 23:45
-
11/02/2024 - 00:00 to 23:45
-
11/09/2024 - 00:00 to 23:45
Known Bugs
Bug of the Moment
"Process Packet Data"
This isn't so much a bug as a part of the program that has fallen into disuse and thus not been updated. If you attempt to process a saved log file through this screen (reached from the main screen menu) you may be disappointed. Many types of APRS data are NOT supported.
Several years ago I implemented a "Simulation Mode" in the Packet Terminal part of the program. I initially did this so I could test how the program would handle incoming packet traffic. However, simulation mode is identical to actual reception of data from an airborne payload. It soon became obvious that this was the ideal place to post process packet logs as well as troubleshoot the program. At that moment of "ah-ha-ness", I made the simulation mode publicly available in the program and not a hidden debug feature. Since that time I have NEVER worked on the "Process Packet Data" screen. When a new packet type came along needing decoding, I wrote the algorithm once in the Packet Terminal screen and did not update the "Process.." screen.
So, bottom line, process log files via a simulation in the Packet Terminal and don't rely this module. I'll get rid of it once I've moved some highly proprietary EOSS decoding algorithms into the Packet Terminal.
MapPoint Bug
This bug will remain until I rewrite the program to only use MP 2004 exclusively. At that time, this notice will be replaced with a note to that effect.
If you have MapPoint 2004 and you install Balloon Track, you will probably get error messages if you try and map predictions or real time tracks to MapPoint.
Balloon Track was designed to work with MapPoint 2002. However, it has been reported that if you FIRST install Balloon Track, then install MapPoint 2004 the installation procedure of MP 2004 will "fix" the problems by directing Balloon Track to use a different interface module.
After you have installed the programs in this order open the Balloon Track Setup screen. Click the Folders/Files tab and put a checkmark in the box at the bottom of the screen labeled "MapPoint Available".
I can attest that Balloon Track and MapPoint 2004 work together if they are installed in the "proper" order. What I can not do is fix this problem (yet). At my current level of understanding, I would have to break the connection to MP 2002 in order to make MP 2004 work correctly automatically. I haven't yet found a way to get external programs to work with both versions of MP.
At some distant time in the future when I believe everyone has migrated over to MP 2004, I'll break the connection to the older version of MP and bring the behavior of Balloon Track back to that of a good citizen. In the meantime, the use of the sequential install above should cure the problem.
Bug in version 1.8.9
Some users were reporting problems with installation, specifically with the file MSVCRT.DLL.
I discovered a rather nifty feature in Microsoft's scripting DLLs that allowed me to accomplish several file management tasks faster and easier than having to hand code it all. However, I've received two reports of problems with this DLL which is associated with the time saving libraries, so I've dumped all that code and rewritten it to use standard vb runtime libraries in versions 1.9.0 and above. I hope this solves the problems with this DLL.
Users experiencing the problem should uninstall Balloon Track, then reinstall this full installation beta.
If asked to remove MSVCRT.DLL during the uninstall, something that should NOT really happen, I recommend leaving it in there unless you are sure you don't need it. If you are unsure but want to get rid of it, then go to your windows\system32 folder, find the file and rename it to something like MSVCRT.DLL.BAK. Use your system for a few weeks to ensure its "absence" isn't causing any problems. They you can dump it for real, I suppose. I HATE to say you should do that because it is a shared DLL and some other application may be in need of its availability. You won't discover that until you finally run that application for the first time since removing the DLL and finding it crashes. Renaming the file should keep it out of system memory and cause any calls to it to fail. This should suffice unless you are really strapped for hard disk space.