We must be willing to let go of the life we have planned, so as to have the life that is waiting for us. E.M. Forster, Writer. 

“Don’t get too used to this,” I thought. This isn’t how it is always going to be. But I had to admit, it was very nice. I had just been shown my new office on the ninth floor of the Logicon building on 5th Street in San Pedro. It was a private office with a large window overlooking the Port of Los Angeles, with cruise and cargo ships coming through regularly. “How am I ever going to get any work done with a view like this?” I asked myself. The shift from being a math instructor in South Bend to an engineer for a government contractor was stark, from the increased pay and generous benefits to a facility whose roof did not leak whenever a summer thunderstorm passed through. 

My decision to go with Logicon followed a search that down selected me to two choices: Logicon in San Pedro and Raytheon in Lexington, Massachusetts. Several factors influenced my decision. Raytheon’s project was the Patriot missile system. Logicon’s was an experimental maneuvering reentry vehicle. Raytheon was a big company (large pond), and Logicon was a medium sized company of 700 employees (small pond). And Logicon was close to my family in Southern California, while Massachusetts was light-years away. Besides Logicon did a great job recruiting me, taking me to the Papadakis Greek Taverna for my interview. The meal was delicious and I was sold. As it turns out, the choice was more fortuitous than I could have ever imagined. 

My roommate from college, Doug Burum, was getting married that fall in Pasadena, and had asked me to be best man at his wedding to another friend Belinda Busteed, a graduate of Scripps College. Because I now lived in Southern California, I was able to attend a shower for them in October. At the shower, I ran into Melody Shipherd, a woman I had known throughout my time in Claremont, but whom I had not seen for three years while in Indiana. Doug and his then girlfriend had set us up on a blind date at Disneyland in May 1971. We became good friends, going to concerts, lectures, and picnics, always having a fun time together. But I had moved to Indiana after graduation, and we lost contact. Now it was October 1978, and there she was at this party. When I saw her and began talking with her, a new feeling happened inside, one quite different than the one had felt before. This time, I saw her as more than just a casual acquaintance, but rather a woman I wanted to be with, see more of. We started dating, and three months later on my birthday in January I proposed to her. We married on May 12, 1979, a very, very hot day in Southern California. And here we are, 45 years later, still happily married, and very much part of each others’ lives. 

In San Pedro, I worked for Logicon’s Strategic and Information Systems Division (S&ISD). My first project at Logicon was AMaRV, the Advanced Maneuvering Reentry Vehicle, with Bob Brooks as program manager, and Larry Amor, the software testing project lead. We had a matrix organization, however, which meant that engineers could be assigned to multiple projects. They were not required to work on one project only, but often worked on multiple projects simultaneously. 

Logicon had developed its niche performing independent verification and validation (IV&V), meaning that while other contractors developed a capability, Logicon would independently test it to verify it met system and design requirements and validated its mission. Although this was an expensive undertaking, it was really an investment at the front end of a project that ended up saving the government and system users much greater expenses and heartache much farther down stream. I was to learn this was the case decades later when the GPS ground control system went through an extensive overhaul with costs far exceeding original budget. That of course is a later story. 

I moved to San Pedro in July 1978, and was able to rent a small 1 bedroom house on 19th Street in San Pedro, close enough to bicycle to the Logicon office in the dry southern California weather. Logicon occupied an eleven-story building overlooking Los Angeles harbor, just blocks from passenger and container terminals for Princess Cruises and American President Lines. 

On July 18, I arrived at Logicon, entering the large windowed reception room on the ground floor, and soon received an escort to take me up for processing in at the human resources office, where, true to government fashion, I was given a pile of forms to read and sign. I learned that Logicon eschewed titles, and instead each employee was referred to as a Member of the Technical Staff, or MTS. This was an approach taken by the founders to eliminate layers of management. Instead of departments, there were projects with project leaders and members of the technical staff assigned to supported those projects. Training was an important part of the work we did, and I was able to take a number of courses both onsite and at remote sites to learn methodology and hone my skills.

I was introduced to many members of the team and discovered my amazing office environment. The team I worked with was young, professional, and very dedicated to their work. Leon Palmer had a PhD in astronomy and worked on many of the algorithms we developed. John Kooker was a bright and capable engineer, and a good friend. Dr. John Berg, joined our team for a few years, and he and I helped plan the Logicon company picnic one year.  Our project manager, Bob Brooks, was a friendly and supportive boss with a great sense of humor. Every year, he would organize a limerick writing contest for the Division, then host the reading of the limericks at a potluck. 

The Logicon building was a rectangle, with offices located around the perimeter, each with windows overlooking San Pedro, a section of the city of Los Angeles at the harbor. Two elevator shafts went up the length of the building with a row of storage rooms between them. Secretaries were assigned to large bays just outside the elevators.

Office life in the 1970’s was nothing like we have today The personal computer did not exist. We prepared all our materials by hand, in pencil or paper on yellow legal pads, and formal reports were sent to the secretaries who typed them up on typewriters for us to proofread and return. We were trained on the protocols of editing a document, including a blue pencil to run a squiggly line through a letter to delete it or penciling in “stet” if something was to remain unchanged. 

In the office, the most advanced technology we had was an IBM Display Writer word processor, a massive dedicated station available only to a select few who used it to prepare formatted documents. Typically, reports and formal letters were typed on the IBM Selectric typewriters by members of the secretarial pool. Only occasionally were we allowed to use the typewriters ourselves. 

We had telephones in each of our offices, but not with separate phone numbers. Calls from the outside were routed through the receptionist on the ground floor to the extension telephones in each office.  Behind the reception desk was a switchboard where the receptionist would route the received calls to the correct office by plugging a wire into the appropriate outlet of the switchboard. Eventually this was replaced by a PBX (private branch exchange) system, eliminating the need for a person in the loop. 

Since the company was spread out over many floors in the building, we sent handwritten correspondence by using Interoffice Correspondence envelopes which were large manila envelopes with a tie string flap and a grid of blank boxes printed on the outside. If one person wanted to send a memo or document to another, they would place it inside the envelope, write the addressee’s name on the front of the envelope using the next available blank line, and place it in the outgoing bin on the desk for a mail person to pick up. If receiving Interoffice Correspondence, the recipient would draw a line through their name on the front, remove their correspondence and tuck the envelope into a folder in their file cabinet for later reuse. 

I first heard of GPS in 1978 while working on AMaRV. We were testing the on-board navigation and control system, and the code had a reference to inputs from something called GPS. The inputs were for positioning information, but no one knew how it worked, and since it was years away from implementation, it was not discussed further. Now that I had heard about it, however, I was intrigued, and watched for any further news on its development. I remember thinking to myself, if I can ever got onto that program, I will. Unknown to myself, this decision was the first step in reorienting my career’s heading. 

My job on the AMaRV project was independent verification and validation. We were testing the mission software for a missile which was to fly from Vandenberg Air Force Base in Southern California to a lagoon at Kwajalein Atoll in the south Pacific, along a predetermined yet not fixed flight path. My job was to analyze the flight computer program code used by the on-board computer, an LC-4516D fixed point computer manufactured by Litton Industries. It was programmed in the base programming language for the processor, called assembly language. The program was printed to a punch tape then loaded into the computer onboard the reentry vehicle. Punch tapes were like punch cards, a film with holes in it, and were read by a tape reader to upload the codes into the onboard computer. 

For our project, IV&V had two tasks. One was a static analysis of the program code, which involved examining the program and analyzing the various control paths it would follow. The other was dynamic analysis, in which we ran the program on a computer simulation to see how it would behave. The simulation modeled the aerodynamics of flight and the control surfaces of the reentry vehicle. Since I was a junior engineer, I was given the less demanding task of code analysis. Later I learned that other engineers considered this level of work beneath them, because they were not participating in designing systems, but rather just looking at the designs of others. For me, I found reviewing thousands of lines of existing code quite helpful in learning how the logic worked and the pros and cons of good program design. 

I jumped into the static analysis work with an immense curiosity to understand what the program’s code was doing. This involved looking at each function to find out how it was called, what functions it called, and what calculations it performed. I remember taking long hours to read through the code, highlighting lines, and establishing a method whereby I could quickly understand the full cycle from end to end. The code used an “interrupt driven” technique employing fixed point arithmetic, which forced me to understand how these processes worked. “Interrupt-driven” means that while the program was running, events would take place forcing the computer to act immediately on the events, then go back to doing whatever it had been doing, much like we do at home when we are busy vacuuming the floor and the door bell rings. We shut off the vacuum cleaner right where it was, then answer the door, then return to the vacuum cleaner and continue from where we were at. In this case, however, the program was performing what is called GNC, or guidance, navigation, and control, and not “vacuuming the floor”. The program would calculate its progress along the intended flight path and issue commands as appropriate. Every 5 milliseconds (that is, five thousandths of a second), an interrupt would occur (like the door bell ringing) to tell the flight computer that a new set of inertial data (accelerometer and rate data) was available to process. The flight computer program would then read in the inertial data, and use it to compute an updated position and velocity solution, then the computer would go back to its flight guidance, comparing the current navigation solution to the expected trajectory. It would send commands to the actuators (controllable fins) to cause the missile to adjust its flight to match the intended path. 

Fixed point arithmetic posed a set of challenges for engineers developing and testing the program code. Fixed point arithmetic uses integers for all calculations, not numbers with decimal points. This presents real problems when you want to use numbers with decimal points. For example, to multiply 1.1 and 1.2 to get 1.32, you need to multiple 11 and 12 to get 132 and remember that the result is 100 times larger than what you want. Every number had associated with it the units it was in (such as meters or seconds), the maximum size of the value (such as 32728 for a 16 bit value), and a scale factor (such as 2^-12). If this sounds complicated, believe me, it was. But it was also intuitive, and after working with it for a while, became easy to work with. Analysis of code was more than checking that the algorithms were correct, but also that the units and the scaling were correct. One might ask, why use fixed point arithmetic instead of floating point calculations? Back in the 1970’s only fixed point computers were available on flight control systems, so we really did not have a choice. 

My work on fixed point arithmetic got me into hot water with the company’s president one day, however. In addition to my regular duties on the project, I would occasionally volunteer for other activities at the company. I offered to serve as editor of the newsletter for the Strategic and Information Systems Division. This involved sharing news of what was happening with people and projects, and other items of interest, including humorous stories and limericks. One day, I decided to do something in jest. I would write an article declaring that the company was opening a new division, called the Integer Division. In my youthful mind, I thought this would be hilarious, for anyone reading it would see that I was making a joke with integer arithmetic, like integer addition or integer multiplication, but in this case integer division. Unfortunately, this was not how the company president, Jack Woodhull saw it. Shortly after the publishing the newsletter, I heard back from our group leader, Roy Goern. He asked what was going on, and I explained the joke, which he relayed to Mr. Woodhull. The president’s response was curt, “cease and desist, and if you plan to do something like this again, pass it by the higher ups.” I was suitably repentant and promised not to do it again. I continued to publish the Division’s newsletter, but steered clear of such ambiguous stories. 

In addition to analyzing the program code by hand, we had also developed a 6-degree-of-freedom model (meaning it modeled the three dimensional components of angle and rotation) of the flight regime for the reentry vehicle in Fortran, which ran on an IBM 370  mainframe computer. To operate the models, we would prepare a deck of IBM punch cards and submit these to the computer room before going home at night. Then in the morning we’d pick up the printouts to see how the program run had gone. Not a few times did we find out that some trivial mistake had been made the night before, and the run had to be redone the next night with the mistake corrected. Punch cards were a challenge to work with. They had to be punched on a special keypunch machine which had a keyboard like a typewriter, and holes were punched one the cards in specific locations to match the letters or numbers being typed. Cards had to be placed in a cardboard box in the right order so they were properly read in and processed by the computer. These were bulky to handle, with large programs taking up a whole box. Needless to say, tripping and falling while carrying a box of cards was not a good thing. 

Technology was nothing like we have today. I still clearly remember the fall of 1978 when my friend Rich Zucker came over to my house and showed me his Apple II computer. It just blew me away. What! Could I really own my own computer and keep it at my house? Could I program it to do calculations for me? How I would have loved having this in college, when I had to analyze data by hand, adding up columns of figures, calculating square roots and sines and cosines using a slide rule, and doing all this repetitively for every problem I had to work on. Oh, the time this would have saved! And the mistakes in calculation I could have avoided!

Since AMaRV was my first project as an aerospace engineer, through it I learned many of the basic principles of aerospace systems. For example, this is where I learned about earth-centered, earth-fixed (ECEF) and earth-centered inertial (ECI) coordinate systems. These serve as reference frames for describing a vehicle’s position either relative to the earth, such as at 49.4 degrees north latitude and 133.3 west longitude, or relative to stellar coordinates (distance from the center of the Earth relative to the poles and a point in space called the first point of Aries). I also began to learn about inertial navigation and how inertial sensors worked. These are sensors on a vehicle that provide information on acceleration and heading and roll rate changes. I learned the term “angle of attack,” that it was not dangerous, but just a measure of how much the nose of the flying object was pointing up or down.

The day finally came when the first flight of AMaRV was to take place, and I wanted to see it. I had been told on December 19, 1979, the launch of AMaRV on a Minuteman I missile was to occur at nighttime at Vandenberg Air Force Base in California, home to the Air Force’s Western Test Range, north of Santa Barbara, California. So I hopped into our red Ford Pinto early in the morning for the three hour drive. When I arrived at the base and stopped at the gate, the guard looked under my vehicle, and came back saying, “Water is leaking. I think you may need to replace your water pump.” So I pulled the car over to the parking area and started walking toward the Logicon office on base.

My plan was to fix it myself, but I had not brought any tools. It was lunch hour, and when I arrived at the Logicon office, it was empty of all personnel except for a secretary. I explained that I needed to borrow some tools. She said that tools weren’t her area of expertise, but some of the engineers should be back soon to talk to me about any software tools I might need. With a laugh, I explained that my need was not for software tools, but real hard metal tools, like a wrench, to fix my car. “That,” she said, “I can get for you,” and she brought me a tool chest with the sockets and wrenches I needed. As it turned out the launch was scrubbed that night, and so I had the next day to pick up the part and work on my car to get it running again. I witnessed the launch that night, which was nothing like the ones I had seen on television of the Apollo missions. Instead of a slow eruption and lift off of the vehicle, there was a loud hissing sound and a bright flash in the sky, then the rocket was off in a flash. Within seconds it was gone, heading west southwest, traveling on a long arc towards Kwajalein Atoll in the south Pacific. Word came back that it successfully followed its programmed path and landed where expected in the lagoon. Work on AMaRV was completed in Feb 1980. That was it. I had completed my first project successfully. After AMaRV, I started picking up a number of new projects.

In January 1980, I was assigned for eight months as engineer to a project called Survivability Computer Program. Logicon was tasked with developing a database for the US Air Force Satellite Control Network which would model the utilization of defense satellite ground station network resources, and my role was to help build the database. To gain familiarity with the program, I was sent to Sunnyvale, California April 3 & 4, 1980 to learn about the Satellite Control Facility (SCF), where I took the course #SCF-203 “SCF Orientation”, a multi-day training session on how the Air Force managed its mixed fleet of communications, weather, intelligence, and sensor satellites with its network of tracking stations around the globe. While today, all military satellites are controlled from Schriever Space Force Base in Colorado, back in the 1980’s they were controlled from a windowless rectangular building managed by Lockheed Missiles and Space Company, just off the interstate highway in Sunnyvale, California. It was painted blue and everyone called it the “Blue Cube”.

The course was an eye opener on the world of operationally managing a various collection of satellite types and missions. The Air Force Satellite Control Network consisted of stations around the world with exotic sounding names, like HULA (Hawaii), POGO (Greenland), LION (Oakhanger England) and BOSS (New Hampshire). Since every system had its own mission and priorities, scheduling communications or “contacts” with the satellites was generally regarded as a nightmare. The scheduling group would roll out a long length of butcher paper, and lay over the top of it the scheduled contacts for each satellite using a thin, adhesive tape, colored differently for each program. This would work for planning until one of the tracking stations went off line, and the schedulers had to scramble to recompute contact periods, pull off the colored tapes and reapply them. This was easier said than done, for commitments had already been made for tracking stations, and a change required voiding some contacts in favor of others. The rumor was that priority went to whichever program could get the highest ranking officer to weigh in. At that point it became a battle of the generals. 

One surprising thing I learned was how satellite photo imagery was conducted back then. After the U.S. lost a U-2 spy plan over the Soviet Union, we implemented photographic surveillance by satellite. Digital photography was not yet available, and so satellites were launched with cameras that used canisters of film. After taking photographs, the film canisters were ejected and came back to earth in large buckets suspended by parachute. Airplanes were sent out to catch the falling buckets before they plunged into the ocean, and these were brought back to earth for processing. The Satellite Control Facility was responsible for coordinating the recovery.

I also learned the fundamentals of TT&C (Tracking, Telemetry, and Commanding), a common feature of all satellites systems. These involved listening to the satellites, sending them commands, and tracking their flight through space. Learning this was essential to the work I was to do later went on to work on GPS. 

From March through July 1980, I was assigned to work on a project called Teal Ruby Experiment, a space-based infra-red earth sensor. For this project, I did requirements and test program analysis and development of an independent test program. This was a cool project, opening my eyes to remote sensing methods from space using “staring sensors”, which are the basis of today’s digital cameras. Although the Teal Ruby sensor could collect data at different frequencies, it was small, only 1,000 by 1,000 pixels or 1 megapixel. Today’s iPhones can take images up to 48 megapixels. My duties were to review prime contractor Rockwell International documentation to perform a preliminary criticality analysis for the Teal Ruby Experiment, then conduct a tradeoff analysis to determine hardware and software tools to use in the IV&V effort, collecting data from hardware and software vendors, as well as personnel from the Aerospace Corporation and Air Force Space Division. Teal Ruby was scheduled to go up on the Space Shuttle, but after the Challenger disaster, it was put into storage. As it turns out, the satellite was never launched, and thus this was a program I worked on that never saw the light of day.

Life at Logicon was a bit laid back. Sure, it was intellectually challenging and gratifying. After all we were working on the design of reentry vehicles and satellites, modeling the program code with six degrees of freedom simulations of their trajectories, control laws, flight surfaces, and atmospheric drag. But most of all it was downright fun. We worked long days, sometimes late into the night. But it was a group team of folks, and there were times when Melody showed up with a batch of cookies, and all was well. 

Over the lunch hour we took breaks from our work and enjoyed ourselves. Many of us played Go, or dabbled with the latest technology like Mattel’s Intellivision, which included sports games like football and baseball. Colleague Leon Palmer quickly learned to play this game well, and it was not long before he was regularly winning pretty much every game we played. We also played Stratego, which Leon also dominated as well. 

One of the highlights of lunch time was playing a game of Hearts with the other engineers. These typically involved Gordon Small, our project manager, as well as Larry Amor and Leon Palmer. Having grown up in a family of three sisters and no brothers, I was constantly trying to show off, and when it came to games, to prove my dominance (which was more in my own mind than anyone elses). Playing Hearts at lunchtime was no different. I played to win. And if I couldn’t win, at least I could cause as much damage to other the players’ scores as possible, with Gordon Small being my main target. In the game of Hearts, each heart is a single point, and the Queen of Spades is worth 13 points. Since the winner is the person with the fewest points, the Queen of Spades is a very bad card to take. However this is another strategy to Hearts which is risky, but pays off handsomely if done correctly. It is called “shooting the moon” where one of the players takes all the points, and as a result receives a zero score while everyone else gets 26 points. This approach requires good planning and a bit of luck. For me, the temptation was often too great, and I tried to “shoot the moon” whenever I had the chance. I got pretty good at winning the round at lunch time, which caused Gordon no end of grief. One day, I had a hand that was terrible. I was dealt one Spade only, and it was the Queen. This was bad news for the holder, ensuring they would get stuck with it and the 13 points. What was I to do? I thought. Gordon was to my left, and so I came up with the only thing I could think of. I led the Queen of Spades. Gordon was immediately anxious and concerned. I could hear him thinking, “Was John going to shoot the moon? If he does. this must be the only trick he can’t guarantee he would win.” In an instant, he decided to do the honorable thing and stop me. So he took the Queen of Spades after I led it, rather than risk me shooting the moon once again. My ploy worked. I won the game, and Gordon never forgot how he had been tricked. 

I mentioned my chance meeting with Gordon on the elevator in 1980, and how Melody and I were taking a month-long trip across country. Well, my friend Leon was not about to let this happen without injecting a bit of fun. While on the trip, I called in by phone to find out how things were going. Leon reported the there had been a reorganization at Logicon and everyone had to move to new offices. He assured me not to worry about it, that he and the others had taken care of my office move for me. So when we finally got  home, I hunted down Leon to find out where my new office was. “There’s a memo on your old desk that says where everyone’s new office is.” So I headed up to my old office. The room was empty except for a sheet of paper on the desk. It listed the names of everyone and their new offices. John Lavrakas was now assigned to room 911. So I headed down the hall to find 911. The numbers on one end of the building were low numbers, 901-908 and on the other end of the building higher numbers, 914-922, but where was 911? I was quite confused, walking between the elevators at each end of the building. Finally I found a door with that number on it, but the door was on the interior of the building. Had I lost my window office? I briefly thought. I pushed open the door, and was greeted by a bright flash of light that temporarily blinded me. Then as my eyes adjusted to the light, I saw Leon there with a flash camera, taking my picture as I stared into the janitor’s closet. There on the sink he had placed my desk plant along my photo of Melody and me. I had been pranked! Welcome home. 

Once I got settled back into my real office, Gordon brought in a pile of documents describing the GPS operational control system. “Read these,” he said. Out he walked, and the next chapter of my career had begun.