In November of 2018, I went back to JSC to participate in the sendoff of one my old FDO buddies as he retired. It was great seeing so many familiar faces again. But, after lunch, my old office mate (Big Bird!) took me on-site to the old MCC stomping grounds. Afterwards, we went back up the FDO offices where we had spent so many years “doing space stuff”.

Bookshelves full of old FDO Console Log Books were there, like some old nearly-forgotten library of some of the really cool stuff we did.

I easily spotted some of the flights when I was Lead FDO – including my last flight, STS-86.  With some pretty heartstring-tugging nostalgia, I opened the book, flipping through pages and remembering writing these entries like it was yesterday.

When I got to the page documenting my final shift, though, it kinda got to me for a minute.  I remember the feelings of that day… knowing I’d never wear the headset again.  Knowing that I was making a huge life-altering decision.

I took a picture of that last page – that’s my handwriting (in black ink) from the top of the page through my signature at MET 8/19:48.

STS-86 FDO Console Log - my last shift

So what does that gibberish all mean?

For a FDO, it’s not a horribly exciting set of entries.  But hey!  You’re here to see “how things were done in the Shuttle Program”, right?  Plus, this is specifically about my last shift on console.

 

So … enjoy.

Here’s the translation for you:
Click on each item below to see more.
TOTAL WT: 224971
This was noting that we had done a routine update of the current Orbiter weight (in pounds), based on various things – including fuel expended so far, cargo/payloads transferred, consumables used, etc.

It was important to know the vehicle weight for not only on-orbit state vector propagation, but also in the event of an unplanned or emergency deorbit situation to know if we needed to burn off extra fuel to get down below a certain maximum down-weight level.

NAV SV to V39
This was, again, normal housekeeping.  Part of the FDO’s job was the maintenance of the overall current and planned trajectories, in a propagated series of state vectors called an ephemeris (or ephemerides, for plural). 

The “NAV SV” was the latest Navigation-computed State Vector, based on tracking from both ground-based (C-band and S-band) tracking stations and TDRS (S-band) tracking.  

V39 was the normal Mission Operations Computer (MOC) vector storage slot reserved for the “current/best state vector”.

Note that I had entered the Δa and Δv values.  This was to note the difference between the newly computed State Vector and the last SV (in Ephemeris 1) and the current onboard SV (FLTI) for both semi-major axis and downrange deltas. There were specific Space Shuttle Flight Rules written to define the values within which the FDO would keep the SV inaccuracies. (hint: these were within those values)

MOC in High Speed/Landing Phase
Since we were the pre-Day-of-Landing shift, there were some checks that needed to be made over various ground stations to make sure we were ready for the next day’s “High Speed” trajectory/telemetry processing.

To do that, the MOC had to be set into a special processing phase and verified a day in advance. I was just noting that event here, and the reason why we hadn’t yet updated the onboard SV.

22Z SV to SPADOC
SPADOC (Space Defense Operations Command) was the new acronym for the USSPACECOM (US Space Command), aka “NORAD”.

The FDOs were the points-of-contact for SPADOC, providing state vectors for evaluation of potential orbital debris conjunctions. In addition to providing post-burn trajectory planning vectors well in advance, we would provide “regular” daily update vectors just to refresh the SPADOC ephemeris for the Shuttle – since we were better at predicting our “big bird” than they were. 🙂

So this was indicating that I had sent the 22Z (Zulu, aka “GMT”) vector to SPADOC.

OPS Phase
The High Speed/Landing Phase checks were successful … and the MOC was back in OPS Phase.
40101 to O/B
Remember the NAV SV update above? Well, it’s time to update the onboard Shuttle computer’s navigation state.

This is done with a very special command uplink, known as the 40101 upload. The FDO, through the DYNAMICS backroom controller, would create a 40101 command set containing the selected state vector and would then ask INCO (Integrated Communications Officer) to upload to the onboard computers – after receiving permission from FLIGHT, of course. If the crew were awake, CAPCOM would announce the SV update to the crew – for situational awareness, if nothing else.

Since this was my last flight and my last shift, my INCO buddy asked if I wanted to actually “push the button” and send the physical state vector to Atlantis. OF COURSE I jumped at that opportunity… and with that, at Mission Elapsed Time of 8/19:48, I unplugged my headset from the FDO console for the last time.

If you liked this, or have any other questions – please leave a comment below!

3 Comments

  1. Mark Jones

    So cool.

    Reply
  2. Samuel Alves Pereira

    I am interested in knowing how intercom loops work in the control center.
    How are the communications between team members?
    How do communications in one loop not interfere with the other?
    What about the hardware and software involved?

    Reply
    • Roger Balettie

      Hi Samuel – great questions!! Sounds like I should make a blog post just about MCC communications! 🙂

      Stay tuned. I’ll do that!

      Reply

Submit a Comment

Your email address will not be published. Required fields are marked *