Aerospace Engineering


I’ve spent the bulk of my career working in the aerospace field (with a few years out to run my own software company, Six String Software–see my Software page). My primary area of expertise is in orbital mechanics: satellite orbit determination, on-orbit maneuvering, satellite constellation design, spacecraft performance, trajectory design, and especially rendezvous and proximity operations. My resume can be found here.

PurdueCollege: I graduated from Purdue University in 1979 with a Bachelor of Science degree in Aeronautical and Astronautical Engineering (BSAAE), with a major in Astronautics and a minor in Rocket Propulsion. I also minored in Mathematics. At Purdue, I was inducted into the Tau Beta Pi engineering honor society and the Sigma Gamma Tau aerospace engineering honor society.

 

 
NasaNASA: After Purdue, I went to work for NASA at the Johnson Space Center. I worked in the Flight Dynamics section of the Mission Operations Directorate, the FIDOs of Mission Control. I trained as the first rendezvous flight dynamics officer (FIDO) and worked in the Trench–the front row of Mission Control–for the early Space Shuttle missions. I developed rendezvous displays and procedures, performed proximity operations analysis, and was responsible for on-orbit and deorbit maneuver targeting when on-console during simulations and missions.

 
BoeingBoeing: I left NASA in the early 80s to go to work in the private sector for the Boeing Aerospace in Kent, Washington. I worked in the technical staff, supporting numerous programs in guidance and navigation. While at Boeing, I support some two dozen programs, ranging from operational programs like Air Launched Cruise Missile to futuristic preliminary design programs for returning to the moon and conducting strategic defense from space.

 
Private Consulting: I left Boeing after 10 years to start my own software company, then returned to the aerospace field in 1999 as a private consultant. I worked for numerous start-up companies during that time, including Kistler Aerospace, Andrews Space, Lunar Transportation Systems, and SpaceDev. My responsibilities ranged from preliminary design to performance analysis to systems engineering.

 
Kistler-RpKKistler Aerospace/RpK: After several years of consulting, I was hired by Kistler Aerospace as a full-time employee, performing ascent analysis of the K-1 launch vehicle, rendezvous procedures and requirements, and interfacing with NASA JSC. After the merger with Rocketplane, I was the lead technical analyst for Rocketplane-KistlerĀ in winning a $207 million COTS contract from NASA. After RpK folded, I joined SpaceDev’s Red Team to review their COTS contract bid.

 


7 Responses to “Engineering”

  • Nice website design. Is this a template?

  • I started with a template, then adapted it to my own nefarious purposes.

  • Glenn Kubena:

    Terry,
    I read your article “RIP, MOC” with some interest. I started work with IBM in 1967 as a software developer for IBM. My very first assignment was to develop assembler code to monitor downlink telemetry for Apollo on the IBM 360/75 computers. I was paid about $8K a year to develop software to run on a million dollar computer (how times have changed). I was 23 years old and i had the best job in the world. I named the downlink monitor routine “TLQCAL”. I remember putting snaps in the code every 10 instructions or so because I wanted to make double dam sure it was working correctly. Since we had a CPU that could only do a million assembler instructions per second (which seemed enormous at the time) we were very judicious with the code. For example, since we knew a load address instruction ran faster than a subtract register instruction to clear a register we used the load address. Also, since most of the CPU usage was in the “unpack, calibrate and limit sense” loop we spent a lot of time optimizing that part of the code and got it down to about 30 instructions. Nowadays since hardware is cheap and developers are expensive and time to market is critical I guess very few if any developers do that anymore.
    One of my favorite “special comps” I developed was the PLSS software that monitored the crew as they walked around on the moon.
    After Apollo we re-wrote the software for Skylab and re-wrote it again for STS-1. The software of course was re-writted again in C/C++ by Lockheed to re-run on servers with the resultant reduction in sustaining engineering cost.
    After 32 yrs with IBM including working DOD and DOE contracts and another 11 yrs with United Space Alliance I am now retired.
    I noticed your interest in guitars. I have been playing for some time and have a garage band called “The Playing Possums Legendary Garage Band”. If you are ever in Clear Lake and would like to jam with us .. stop by. I also am bored at times and am looking for some other interests.
    Thanks for your article
    Glenn Kubena

  • That’s a great story! Nowadays, you’d be more likely to get paid a million dollars for working on an $8,000 machine!

    I, too, well remember writing in assembly language and optimizing every possible code fragment: not for my work at JSC, but for my game programming back in the 80s! (see http://www.terryburlison.com/software/search-destroy). Today, code seems so sloppy and bloated–made up for by sheer horsepower. Too bad.

  • David Gafllloway:

    Glen, Terry, on my last big project, which was a game, I still spent an enjoyable and important amount of time on writing very efficient assembler code for the x86 SIMD within a register (SWAR) SSE2 instructions. I did some cool tricks too like using floating point multiplies for shifts (they are fast!). On the Playstation 3 another engineer did a crazy amount of assembly SWAR coding on the idiosyncratic SPE co-processors (there are six) to software rasterize our 3D scene to a low res Z buffer to allow a occlusion culling on the co-processor. So while a vast amount of software is bloated and messy (even in our games as a whole) there are still plenty of assembly coding in real-time applications where just upgrading the CPU isn’t an option. Coding GPUs is done in a high level language now but we still look at the assembler to make optimizations in the source.

  • Ron Wade:

    I just read your account of the STS1 Pad 39A incident, I thought it was very well written and provided the type of incite I like. My father worked for North American Downey on Apollo SCM and I worked at Rockwell International Space Division Downey on Shuttle Orbiter as well as Rocketdyne on SSME and Atlas/Delta ELV engines. I supported STS2, they had a fuel leak on the FRCS module, I believe that a technician also died in that incident as well…. Have you heard of this?

  • No, I don’t recall an FRCS leak prior to STS-2’s flight. I remember the fuel cell failure on-orbit, though; it shortened the mission from five to two days. If you find any info on the leak, please forward it to me. Thanks.

Leave a Reply