Recap of EOSS-79

back to Main Recap page

From the Web Master
and
Prediction Center
Perspective

It is my intention to outline the job of both the web master and the trajectory forecast center for this recap. It is mostly a recap of the process, not of this individual flight. So, take off in you aren't interested in the mechanics of web mastering or predicting.

A flight for the web master begins, usually, months ahead of actual liftoff. This activity primarily revolves around keeping the Flight Announcement Page up to date with the latest information regarding the components of the flight as well as the intended frequencies to be used and the location of the launch.

From a prediction stand point, each flight begins approximately one week prior to launch. It is at that time that I begin to create predictions for the flight trajectory using Balloon Track for Windows.

For a peek at how this works, CHECK HERE. That page is primarily devoted to how accurate the forecasts are but, it shows a number of predictions which may prove interesting. You will note that long range forecasting is not all that reliable. I usually don't trust predictions until the 3.5 days prior to flight when I switch to a prediction model that appears to be pretty reliable. This is usually the Wednesday morning pre flight.

Usually, but not always, I generate a morning and an evening prediction. The results are posted to the Flight Prediction Page.

On the evening before launch I make my final prediction. This is posted to the Prediction page and also provided to the Tracking and Recovery coordinator so that he or she may create a recovery plan.

At that time, the T&R coordinator provides me with the Grid layout and tactical callsigns which I add to the Flight Announcement page. It is hoped that folks can print out this page during or after the pre-flight net and have something valuable to take along with them on the recovery the next day. I should advise you here that during the net I usually hear something that causes me to edit the Announcement page. So, if you plan to take the most accurate information into the field with you, wait until the net ends and print what you see. I'm almost always finished editing by close of net and the resulting edited material has been published to the website.

Flight Day

Flight day usually starts out around 3 hours prior to launch.

My first task is to start an audio recorder (Marantz PMD-670) which is permanently connected to an Icom IC-R8500 monitor. I tune in the frequency of the Tracking and Recovery operations and let it run. In this way I record the pre-flight chatter which includes the positioning of the Tracking and Recovery team as well as some flight readiness information provided by the ground station.

The PMD-670 is a solid state recorder that saves audio to a compact flash card. It can be set to save audio in a variety of bit rates and frequency response settings. Because this is repeater audio I record at a slightly overkill setting of 64 kbps and 44.5 kHz sampling rate and to save the audio in compressed MP3 format. Using a 1 Gigabyte flash card there is room for approximately 35 hours of recording. That's way more that I'll ever need but offers the peace of mind that I won't "run out of tape" at an inopportune moment during the flight.

If we are flying the Cross Band Repeater, I set up a second recorder (Sony ICD-MS515) and attach it directly to a second scanner (Uniden BC 780XLT) or possibly a handie talkie (Yaesu FT-530). I don't start that recorder as I will only want the flight audio. The audio from the Sony is in a proprietary format but is of high quality. That recorder saves audio to a flash memory card, in this case a Sony memory stick. A 64 megabyte card holds approximately 9 hours of audio on the highest quality setting.

Ok, it's time to get to work. The next step is to run a prediction. Since it is still several hours in advance of the flight, not many folks are actually out and about motoring to their assigned locations. However, this prediction is primarily for my peace of mind. I want to see if there has been any significant change in the predicted touchdown point from the previous evening. If the prediction is substantially the same (within say 5 to 10 miles from the previous prediction) I usually don't announce the results. They are only going to change as the morning's NWS weather balloon flights (RAOBs) will acquire more data and alter the prediction. Should a wild alteration of the prediction occur placing the landing spot significantly removed from the previous night's prediction I'd attempt to contact the T&R coordinator to allow him time to realign the distribution of team members for the new touch down point. For EOSS-79, no premature notification was needed. The prediction was essentially the same as the previous evening's run, possibly a mile or two different.

For the next two hours I essentially monitor the traffic haphazardly listening for my callsign and to see if a home station might be of service to the hunters (phone calls, etc.).

One hour prior to flight I run another prediction. This one is primarily generated for the benefit of the ground station. They rely on this prediction to provide information to the FAA. They must call this in approximately 30 minutes prior to flight and I like to give them the data a little early. Depending on the location of the ground station I either email this data or transmit it via voice over the repeater. A data link is always preferred as I can also send the ground station an Automatic Position Reporting System (APRS) file that will map out the predicted track on any APRS program's map interface. This prediction is also published to the prediction page so that the FAA controllers may have access to it and the maps should they wish.

Depending on launch time I will run a final prediction either just prior to flight or after the morning's NWS RAOB flight in Denver has completed, whichever comes first. This prediction is usually the most accurate as it incorporates data acquired by NOAA/NWS just before we actually fly our own payloads. In the case of EOSS-79, this prediction actually did differ substantially from the earlier prediction. So, it was necessary and important to get that information to the Tracking and Recovery coordinator so tracking teams could be repositions for a slightly shorter flight.

Fifteen minutes before liftoff of the cross band repeater I start up that recorder.

Now my pre-flight prediction job is finished. But, I'm just getting started.

I fire up Balloon Track and set it to record several different data files. In operation, during a flight my computer desktop looks something like this:

CLICK HERE to go to a page containing individual screen shots of each window.

By monitoring the actual position of the balloon with its predicted location I can apprise the Tracking and Recovery team of the accuracy of the prediction or its lack thereof.

While my main computer is occupied with the above data capture and analysis I also have two other computers watching the flight.

An iMac is set to watch the flight via Findu.com on the internet. I open a Safari browser window and open tabs for each APRS payload being iGated into the internet. I can then be assured that the FAA will be able to follow the progress of all of our airborne payloads.

A third computer is running Balloon Track exactly as above. In the case of a two balloon flight, it is set to watch the second launch. When we are flying a single balloon, I set it to watch either an alternate APRS beacon or simply act as a backup for the single and primary APRS beacon.

When the launch occurs I watch for the first packet on all systems. My home radio received packets and the internet iGated packets. Once acquisition of signal appears on all systems I report to the ground station that the iGates are working and the FAA will be in the tracking loop. A welcome change for EOSS-79, Mark Patton [KØYG] who was one of the iGates called in to the ground station to confirm his packets were making it into Findu.com just fine. I wish more iGaters would do that. It's great. But, often the iGates are setup to run automatically and so, I attempt to cover in that eventuality.

As the person responsible for the accuracy of the prediction, I keep an eye on the comparison of actual data with that predicted. Usually I don't get too excited initially if the balloon wanders from the predicted track, but if after the balloon has ascended to 20,000 feet or traveled 10 or so miles down range and there is a significant deviation from the prediction, I'll call the Tracking and Recovery coordinator and advise him of the variance and its trend, possibly even generating a new prediction. This is often the case when I note a significantly faster or slower ascent rate is occurring but the balloon is essentially tracking along its predicted path. In this case a new prediction with the observed ascent rate will generally provide a much better prediction.

Even though I may not have to contact the T&R team much during a flight I keep a close eye on all this accumulating data looking for variations from prediction so that I may be better able to keep the T&R coordinator focused on the expected landing point.

My job as web master occasionally attracts my attention and I pop off emails to various email lists outlining our progress. However, I have to admit that I am somewhat remiss in this department if all is going as expected. Only when we have a problem do I try and be sure to drop a note into the Lists so distant monitoring stations can be kept in the loop. We probably really should have a dedicated "reporter" who handles this. I often get "distracted" by my main job (prediction) and completely forget to send out any emails, as was the case on EOSS-79.

So, it goes up, I refine the predictions, it comes down and the T&R guys find it. What's next?

Once the balloons have been physically recovered I shut down all those audio recorders. That's it as far as they are concerned.

The job of prognosticator is over and web master begins.

First I gather up all the data files that have been generated during the flight. I move that data into folders for archiving purposes so that I don't inadvertently overwrite it with some testing with Balloon Track (a literally never ending process).

Then, I take a nap. What I'm really doing is two fold. One, I'm a tired puppy. I generally stay up to the wee hours of the morning. On flight days, I just extend my day by staying up until the balloons have landed. So, first off, it's time to rest. But this serves the second part of that fold. I need to wait until I start receiving information. People start deluging my inbox with log files from their TNCs and photographs taken during the flight process. I'm going to need all that info to create the "Flight Recap".

Flight Recaps have gone from the really simple (EOSS-1) to the somewhat complex, say this recap (EOSS-79).

Current recaps often have lots of data, pictures, audio, sometimes video. It's time to organize it all and attempt to offer it in a comprehensible way to interested parties.

I usually start out by taking ALL the flight position data and concatenating it into one huge file. Then using some sneaky tools, I get rid of all the duplicate information so that I have a single data file that contains the maximum detail possible. I then take that data file and run it through Balloon Track to generate a spread sheet format of it, and also to create the flight recap maps shown at the top of each recap's main page.

The maps are made. The actual landing location is compared (in Balloon Track) to the prediction and that data is saved. Then, the recap is started by showing the map and that error information.

Now it is time to start working on the audio files for the flight. I both delight in and dread this phase.

• I take all that audio I've recorded and drop it into Adobe Audition.

• I then massage it a bit by filtering out sub-audible tones (they are NOT sub-audible) and any hiss.

• Then I normalize the volume levels so all recordings match.

• Next, find that time where Marty Griffin tells all about the flight and save it to a separate file.

• Next, find the talking ID for the repeater if it has one and save it to a separate file. 

• Next, split up the audio into meaningful segments so it is possible to offer slightly smaller files for download. You know, preflight, ascent, descent, and recovery.

• Next, edit out some of the extraneous traffic if possible. I don't always do that but sometime it is necessary (ten consecutive IDs from the airborne Crossband repeater, no one wants to hear that).

• Next place the Voice Repeater ID on a track in Auditon

• Next place Marty's spiel on its own track

• Next place the segment audio of the repeater audio on a track

• Next move the tracks around so them flow into one another nicely.

• Next, check audio dissolves so that the recordings begin from silence and end with it and don't have any obnoxious pops, hums or strange occurrences when one track bleeds into the next.

• And finally, when the full track sounds good, compress the result into MP3 files for publication.

There that didn't sound so bad did it? Well, usually it takes me 4 to 6 hours over two days to get it all correct. Lots of time is spent laboriously searching for the natural breaks to make the segments. I just hate waiting 3 minutes for a 1.8 Gigabyte section of audio to be normalized. Many of the steps above insert significant waiting time while the old sloe poke 3 GHz P4 crank away with audio modifications. But, like I said it is both delight and dread. It's fun to do the editing part.

Now, the web mastering part. I copy the files into the web space (on my system), create entries on the recap page to point to them and make the links.

OK, audio is done. Now what? Why, you just received 30 Megabytes of photos!!

This is the most fun. I file away all the photos in full resolution in the EOSS archives on my hard drive. But then, I have to take an editorial look at them and select some for publication. Those I arbitrarily decide should be published are tweaked with Photoshop and reduced in size to something suitable for web page presentation. By tweaked by Photoshop I generally mean I play with contrast, brightness, color, hue, saturation and cropping. 98% of the time I leave the photo alone as far as trickery is concerned. However, on occasion, I do mess with photos. Generally this is done to improve the image. The most common bit of trickery? A part of a person appears on the edge of a photo that is cropped perfectly. I use Photoshop tools to paint them out. If something looks suspicious, email me and I'll own up quickly enough. I'm not attempting to slant the meaning of photos, just clean them up a bit. Here is just that example of "trickery".

By the way, a note here, if you see a picture you want to print but it is too low rez, contact me. I may be able to provide a higher resolution version. However, be aware, some folks reduce the pictures on their end prior to submitting them for publication. You should note that pictures are almost always saved with information that should lead you directly to the photographer. I usually name them:

eossXX_callsign_serial_number.ext

Where XX is the flight number, callsign is the person's amateur radio callsign.

When you contact the photographer to ask for a high resolution version, be sure to be ready to explain what you SEE in the photo. The file name is something I make up on my end to keep stuff organized, it is NOT the filename the photographer used when he/she submitted the photo.

Once I've edited and resized the photos, it's time to create links to them from the main recap page. Once that is done, photo publishing is done. Of course, I'm always open to adding more photos. The recap page is never "done". If you have good photos of a previous flight, you can always submit them.

Well, I'm done ... no wait, more email is arriving. Now it is the text recaps from the flight. Once again I'm cast in the merciless role of editor. I take these recaps and savagely edit them to conform to my view of the English Language. Keep in mind that this in no way means that the recaps are actually grammatically correct, just that I've leaned on them the way I think things should go. I lean on my spell checker heavily too, or was that two, or perhaps to.  So, if you are reading a recap and some phenomenally stupid construction of English stares you in the face, or you read a "corrected" spelling of a word that totally misuses the incorrect word, the fault should be attributed it to the web master not the writer. I probably got dazed and confused and messed up his or her perfectly good prose. I also will correct callsign or other factual information I know was incorrectly submitted or perhaps omitted.

Once edited, the recaps are either added directly to the main recap page or if sufficiently lengthily, given their own page on which to reside. Links are then provided on the main recap page.

Well, that's it from the Prediction/Webmaster center.

Congratulations to all for an eminently successful flight of EOSS-79.