Tomorrow is the first launch that we are going to try and track, and I have been putting off building a way to visually track the balloon in 3D on my laptop. However with only hours to go before its time to rest the eyeballs, I thought it might be a good time to get started.
The idea I came up with was simple in my mind, but I knew that putting it into practice would be harder. The idea was that if a program (D-MET) could write to a file every second, then surely it would be possible to read a file every second as well? If this was the case, then surely it would also be possible to write what it read to a different file every second? These I knew could be done, but the one thing I didn’t know, was if a mainstream third-party application would be able to process a file change at regular intervals, in this case one second.
With this in mind I knew that it was what I had to test out first. Google Earth was my application of choice, as it is able to display 3D terrain in a virtual earth (which is very nice for visualization). However a nicer feature, and the one that sold it for me, is its ability to draw paths and polygons onto the map, in both 2D and 3D. The 3D aspect was essential as the weather balloon acts drastically in all three dimensions, as opposed to when we walk, we only really act in the two dimensions.
The problem was that up until recently, I had never actually seen a 3D path in Google Earth before. I didn’t know that they existed. However when Michael sent me some test data on a few soundings they did a while back, the Google Earth files (which are called KML files and stand for Keyhole Markup Language) were 3D paths. When I opened them in Google Earth, I had the option to save them to the program, meaning that whenever I closed and opened the program again, it would re-open the files I had saved and display them. This isn’t anything new, but it got me thinking that those files have to be saved somewhere. If I could find where they were saved, I could edit the source code and see how Google Earth responds to it.
After finding the files, I noticed that they were simple XML files (Extensible Markup Language; mostly used where humans have to read the code along with computers, so the results is a language with lots of rules), so I was able to edit it quite easily. When I edited one of the co-ordinates and saved the file, a message alert popped up in Google Earth asking me if I wanted to re-load the file. I did, and the updated path opened with the change I made. This was good news, although the fact that there was a pop-up box that had to be user-controlled was a problem. I needed to find a way to automatically show the updated file as soon as I saved it.
After a few Google searches, I cracked it. There was a feature within Google Earth that was built to link files on any network, which would automatically update every regular, user-defined interval. However the file that I wanted was on my local computer, so I just changed the location of the path to route back to a location on one of my local hard drives. I was then able to link a KML using this feature and to my surprise, it actually worked. Not only did the network link accept my location, but it displayed the path perfectly, and when I edited and saved the KML file, it updated immediately in Google Earth. This was a huge win, as I had solved the final problem, but now it was time to get to work.
The first step was to write a piece of code that would read the DAT file that D-MET was writing to every second. As my dad had a more extensive background in computers, I thought it may be a good idea to consult with him on this aspect of the project. After some testing, we soon found that it could be done in Windows PowerShell, by using a “Tail” command. All that this does is it monitors a file and every time it gets updated, the new content is displayed underneath the command. This was useful, but we needed a way to pick specific content from the file to write to a KML file.
What I discovered was that only one line of KML code needed to be altered: the co-ordinates line. Every point was drawn in 3D space, meaning it needed a latitude, longitude and altitude. The format for this was writing the longitude value first, followed by comma with no space, followed by the latitude value, then another comma and no space, and lastly the altitude value. The format for separating each point was simply a space, as the previous values had no spaces in-between the commas. This meant that all that needed to be done was read the latitude, longitude and altitude values from the DAT file, then write them to the end of the line and keep everything else the same.
Although the DAT file was a simple text database separated by commas, it had a lot more content than was needed. It had everything from temperatures, to humidity, to the azimuth, which was unnecessary for what I needed to do, so we had to find a way to read only the tenth, eleventh and twelfth values, turn them into and array, then stick them into a KML file on the correct line, after the previous co-ordinate and in the right order, as Google Earth co-ordinates with the longitude values first, which was weird. This entire process was done with a scripting language called PHP. When the code ran, it would read the file, find column ten, eleven and twelve, put those values into an array, and then place that array into the KML code which was embedded into the PHP as normal text, then save the file.
Now that the code was working, we needed to create a trigger to run it. We used PowerShell for this by using the “sleep” command. This basically ‘sleeps’ for however long we say, then it wakes up, does its thing and goes back to sleep. This is what the entire trigger code looked like:
Do {
php kmlme.php ‘./TEST SOUNDING.DAT’ > test3.kml
sleep 5
} while ($true)
Basically the code is running the PHP command, so it knows what language it is working with. Then the location and name of the PHP file is given, in this case we called it “kmlme.php” and it was stored in the same location as the PowerShell file. Next we told it where the DAT file was and what its name was, in this case: “TEST SOUNDING.DAT”, which was also in the route folder. Lastly, we told it to name the file the PHP script just saved to “test3.kml”, which was to be placed in the same folder as the other two files. Then there was the “sleep” command which ran for 5 seconds. Lastly, the function was closed with a “while” loop followed by a “($true)”. This means: “while this function is true, repeat it”, and since we didn’t put anything in there that could be false, it will simply run forever, or until we stop it.
The last step was to locate the file from Google Earth and set it up as a network link, then set the scan time to 5 seconds, matching the “sleep” command. This meant that every 5 seconds Google Earth would scan the KML file, see what had changed, then graphically display the changes as a 3D path.
We ran the code on some test we had and it worked perfectly. Happy with our results, it was time to rest for the big day tomorrow.
