1975-1979 Labels

New Requirement: a Programmable Signal Processor

When the AF funded motor contractor to develop new Gimbaled Booster Nozzles they also funded them to study servo actuators which used solid propellant “warm gas” for power – the use of hydraulic servos was excluded –because hydraulic was already a refined art. This greatly increased the demands on control electronics. When told they would use 100 hp gas generators to direct drive clutched servo actuators – I knew signal processing would be required to tame the beast. Missile attitude had to be held within 1.5 degrees or it can flip -- the center of pressure is forward of the center of gravity – it’s like flying an arrow feather end first. Hydraulic servos-actuators were fine tuned to deliver rapid accurate response – digital electronic now had to be programmable to accommodate unknown needs. Thankfully the semi conductor industry had recently produced an Arithmetic Logic Unit that process binary bits in parallel rather than by prior serial methods. I knew the the minuteman mission computer operated in a primary and secondary control cycle. I consulted with office mate Mal Johnson, an expert on computer simulations, on what would be needed. However my first need was to understand how to do digital signal processing?

Arithmetic Logic Units

The new 4 bit ALU was a godsend to the computing business. Prior to it’s arrival arithmetic was done by serially shifting “A” and “B” numbers through a two bit adder and accumulate them in a “C” shift register. Fortunately ALU’s created a big stir and trade magazines included articles on how to multiply, a process of repeated additions. Soon there was a companion Look-Ahead Carry chip that permitted automation of the carry process. Two 4 bit ALUs could be connected to make an 8 bit parallel processor. I soon realized I need a good text book to understand such things as 2’s complement numbers.

Arithmetic Logic Unit

Digital Computer Design Book: I found a book at right published in 1963 and poured myself into learning how to do arithmetic computations. I learned you must precondition binary numbers to be either in 1’s Compliment or 2’s Compliment before or after doing an arithmetic operation, only the very end of the book referred to parallel processing; there were no “cookbook” designs to follow but I was able to extrapolate. Booths Algorithm, is the logic used with look ahead carry to complete an add.

Binary Number Systems: The 2's complement number system is one of the three common notations for representing both positive and negative numbers; the others are 1's complement and signed binary numbers. The 2's complement method was the one usually used in examples I found. There is a unique code for each number and all numbers are treated alike in arithmetic operations and in Digital to Analog and A to D conversions, regardless of sign. Arithmetic operations are implemented through a single path, providing a greater computational speed than is possible with other notations.

Definition of 2's Complement Numbers Positive binary numbers are known as true binary. To represent negative numbers a sign bit is sometimes added; these are known as signed binary numbers. However, binary numbers in either 1's or 2;s complement, are more useful representations for positive and negative numbers.

Commonly used number systems.

Most significant binary bits at left, sign bit at far left.

Hexidecimal	Decimal	Signed Binary.	2’s Complement	1’s Complement	Decimal
F E D C B A 9 8 7 6 5 4 3 2 1 0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -A -B -C -D -E -F	15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 -15	01111 01110 01101 01100 01011 01010 01001 01000 00111 00110 00101 00100 00011 00010 00001 00000 10001 10010 10011 10100 10101 10110 10111 11000 11001 11010 11011 11100 11101 11110 11111	01111 01110 01101 01100 01011 01010 01001 01000 00111 00110 00101 00100 00011 ()0010 00001 00000 11111 11110 11101 11100 11011 11010 11001 11000 10111 10110 10101 10100 10011 10010 10001	01111 01110 01101 01100 01011 01010 01001 01000 00111 00110 00101 00100 00011 00010 00001 00000 11111 11110 11101 11100 11011 11010 11001 11000 10111 10110 10101 10100 10011 10010 10001 10000	15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 -15

The generated command and feedback numbers are read as signed binary. The numbers are the same for: plus signed binary, 1’ and 2’ complement numbers. For a negative signed binary invert the magnitude value to get 1’s complement then add 1 to get a 2”s complement magnitude number.

Algorithm

1. Line up the MSB of the multiplicand register with the MSB of the accumulator.

2. Starting with the LSB, examine successive bits of the multiplier. For 0 to 1 transitions, subtract the multiplicand from the accumulator. For 1 to 0 transitions, add the multiplicand to the accumulator. If there is no change (ie, 0 to 0 or 1 to 1 ), leave the accumulator unchanged.

3. Shift the contents of the accumulator to the right by one bit, but do not change the state of the MSB.

4. Repeat steps 2 and 3 for all bits of the multiplier, but do not shift after operating on the last bit (the MSB).

Booth’s Algorithm for look ahead carry

Test bits:

01 Add multiplicand X, then shift partial product right 1 bit.

10 Subtract multiplicand X, then shift partial product right 1 bit

00 Shift partial product right 1 bit.

11 Shift partial product right 1 bit.

Block diagram of 2's complement multiply

Multiply by repeated addition: The Arithmetic Logic Unit’s can add or subtract but not do multiply or divide. You multiply by performing repeated addition.

First Processor The diagram shows my first attempt to perform multiplication functions. Board at right is not for circuit show.

Successive Approximation Register for Feedback conversion: A micro electronics research engineer told me he was working on a Successive Approximation Register and explained roughly how it worked. A short time later I found such a device, with an appropriate application circuit in an AMD sales booklet. I ordered one and built it into our system. (Yes this is the same AMD now giving Intel a rough time in the CPU market for PC’s.) The SAR compares it’s “guess” with the unknown signal to home in on the unknown. On a scale from 0 to 100 it

will first guess 50, then if the unknown is lower, next guess 25 and so forth until it has resolved it’s lowest bit. It was very fast and I was delighted to incorporate it into our system.

Digital Processor Requirements: I initially assumed we’d use hydraulic servos and asked Mal Johnson to provided a worst case requirement for such a system. I next asked Mal what it would take to control gas generator powered servos? We discussed this at some length, as it’s a very different animal. Mal expressed the requirement in Laplace transform terminology as used for an analog system. I was stuck, I didn’t have a clue on how to do Laplace transform functions digitally.

Hydraulic Servo nil filtering – Turbine Gas Servo much filtering

Dr Blare Bona’s “Rosetta Stone”

Differential Equations > Laplace > Z Transforms > and Sample Data methods

The rate of change of position is velocity, the rate of change in velocity is acceleration

Sample Data Systems: I was having a terrible time, becoming as irritated with the books as my own ineptness. Dr Blair Bona, visiting office mate Mal, became aware of my struggle and came to my rescue. Blair said forget the stuff in those books, this is what you need. He proceeded to my black board and wrote translations, beginning with differential equations, which I could follow. He then expressed the same information in Laplace transforms used for analog systems, which I didn’t understand, then in Z Transforms and converted those to Sample Data representation. I didn’t understand right away how it worked, but I could certainly follow the data processing method. He’d written a Rosetta Stone translation which immediately illuminated the way to do things. I said don’t erase anything until I can write that down. Thank goodness he happened by, lifting me out of my pit of ignorance.

Digital Processing required for One Gas Turbine Servo Actuator

With this Sample Data loop closure diagram I knew what I had to do.

Introduction of “Wire Wrap” connections

Test Equipment: we were using an analog electronics test lab, and Jessie, the lead man provided us a dual trace scope and some old hand calculator parts from when he worked for near by Microelectronics division. I needed something to use for test equipment and after studying the hand calculator parts, I decided to use the keyboard and display, for input/output and memory electronics on a board under the keyboard. We could issue a command and capture the response. 128 bit RAM chips had just come out so I ordered some and made a design. It took technician Lloyd Gardner about a week to “wire wrap” the parts and have it working.

4 bit full adders set up for 8 bit computations for Sample Data mechanization.

It took awhile to figure out how to do a single multiply process, then time to handle two servo loops per cycle. With our home made test equipment we knew it worked, we were on the right track.

How fast is fast enough? The design had to perform “7 multiplies” for each servo for each control cycle. I designed the “data bus demonstrator” to use 4 bit devices to create an 8 bit binary number and shipped them over the data bus as 8 bits pitch and 8 bit yaw in 16 bit packets. The actuator command, convert the four least significant binary bits to 16 step increments, most significant bit were full on. It had worked well so I decided to continued with 8 bit binary words, using two four bit integrated circuits per word. Thus I needed 8 bit “sample data” hold registers – I needed multiple read write storage registers. I clocked the system to run full out to achieve maximum available speed.

TRW data bus presentation to AF at Norton AB. Carl Boody in charge of flight control cabling asked me to attend a meeting with him at Norton Air Base, for a TRW presentation of their “data bus” studies. I was unaware the AF had funded TRW El Segundo to make such a study. I paid close attention to the assumptions they made for their study – their choices of what an MX would need sounded like my assumptions. I turned to Carl and said my gosh those numbers sound familiar. Carl smiled and said they should, the numbers came from your report – they too need study money to tide them over.

Who should provide the Servo-actuator Electronics? We had meetings with TRW G&C, the AF advisors, on what would be needed to control the new motor contractor gas powered servos. They asked what would happen if the electronics was given to the motor contractors along with the servo actuators. I said the responsibility for control and stability should remain with Autonetics, prior undertakings made it obvious the propulsion people did not understand flight control or electronics. TRW G&C and Propulsion agreed that once motor contractor proved their new motor nozzles that Autonetics would conduct perform tests on the selected servo actuators using Autontics electronics. Each competing gas turbine servo actuator contractors was providing their own electronics for static firing tests.

Abandon Data Bus – Use Direct Wire: I made missile wiring layout for moving all downstage electronics upstage and direct wire command and feedback via flat signal wiring – it was a doable concept. I told Lou Purpura, on chief engineer Shuler’s staff, I believed we should move all downstage electronics up stage and find a way to time share the electronics from one stage to the next. Lou agreed – adding we can probably make it a part of the Flight Control Computer. After having sold the idea of a data bus I now had to show a direct wired time shared processor was better – knowing I was working myself out of a job.

Dr Ken O’Kief Purpura called saying Terri Miwa of TRW wanted to arrange for their new employee Dr K. O’Kief visit me so I could bring him up to speed on missile thrust vector control. Lou and I knew Terri from MM 1, 2, 3 days, Terri was now head of TRW’s Flight Simulation Group. I said it’s fine if OK with Shuler (our chief engineer). Lou said Tom’s already approved the idea – he wants us to keep in contact with TRW as they look into new concepts. Thus began a fascinating relationship where Ken and I meet every other week, at Autoneics or at TRW Redondo. Ken adopted our term, missile MX, thus it was no surprise the new missile was contracted as MX and later named the “Peace Keeper”.

Guidance System inside Post Boost Propulsion System. I was involve other studies as MX configuration concepts. I asked Ray Ajamean, an excellent design engineer, to show a concept where the G&C system fit inside the MX Post Boost Propulsion System. My new boss Dale McLoud, long time Guidance and Control supervisor, said no way “We will always be have our own G&C section”. I shrugged and said Dale they are not going to let all that empty space go to waste. Sure enough when the MX was implemented the G&C system fitted into the PBPS as Ajamian had drawn the concept.

MX thrust vector options I prepared four reports for Ken, covering various options for doing flight control on a future MX missile. O’Kief used these in preparing his reports and recommendations. TRW engineering at Redondo CA and TRW Project engineering at Norton Air Base Riverside were warming up to the idea of using time shared digital electronics upstate for downstage nozzle controls using flat cable dedicated wiring.

Segments of Digital processor.

Servo Command Method Feedback Method

Programmable Coefficients: It was necessary to store different filter coefficients and processing for each stage. Epilog: much later while working on the B-1B in El Segundo I stopped by my Autonetics office and happened to meet Terry Miwa of TRW arriving for an MX meeting regarding booster servo controls. After a pleasant greeting with my long time friend I started to move on when Terry turned back to say, they should have stuck with your design. I asked how’s that? He said someone removed the programmable memory from your design and used fixed coefficients which now have to be changed. I was pleased Terry remembered such details, but he would, he appreciated the need for adjustment during the development phase – we’d been through that before.

New System Mockup: After being moved from various buildings and laboratories, to accommodate contract changes, we settled in a new lab in a different building. The lab was under Frank Phelps who assigned technician Lloyd Gardner to work with Karl Lofgren and I. Karl a recent hire form Bell Labs had a masters degree from MIT had assigned by my new boss Group leader George Anderson. We needed a “missile” mockup so Lloyd Karl and I took at plastic patio tables. We found a kind we could stack to make booster stages. I bought the tables and we took them into the lab – like kids with a Christmas toy. We installed gimbaled actuators with plastic funnels as thrust nozzles on each stage with a time shared signal processor at the top e connected to launch control on a near by work bench via and umbilical cable. Our “missile” at the back of the lab looked quite impressive.

Launch Control Karl had previously worked for Bell Labs and knew about the new microprocessor systems and in contact with Earl Hicks head of the Micro Processor Lab. Earl provided Karl a Motorola 6800 microprocessor system for our use. We set this up as “launch control” on a work bench and strung an umbilical cable from it to our near by missile. We also added an Autonetics built AIM computer to aid in setting up the signal processor program. The AIM 65 used the Autonetics Micro Electronics division produced 6502 microprocessor. It was an impressive looking setup.

I learned a great deal from Karl. Four binary bits could be condensed to one column of hexadecimal bits – you could “see” the system on a monitor and were soon able to read ASCI codes for letters and numbers. Though these new devices could not be used for missiles, which requiring hardened parts, they were a huge aid for developing our system.

I already told you that: Karl was going on vacation so I decided I’d better learn how to run the 6800 processor and tried to set it up – I got stuck and asked Karl how to do a certain thing. Karl said, but I’ve already told you that. I smiled and said I’m aware you have almost perfect recall, but I do not. You showed me a lot of stuff two weeks ago and I need your help in refreshing my memory. We had a good chuckle and moved on. I didn’t recall a required digital coding. This was long before BASIC language replaced strings of binary code.

New Speed Requirement Mal said we should close each servo loop every 2 milliseconds. Since a final design would be built with nuclear hardened parts; I assumed a down grade of 50% in speed as compared to commercial bi-polar parts. After speed calculations and I realized our design could not do seven multiplies on four servos, two staged at once at stage separation. The transition between stage I and II would be the most critical because staging was done under the influence of atmospheric pressure. Again Dr Blair Bona came to my rescue.

Princeton Algorithm: Appraised of the new speed problem Blair said you should use the Princeton Algorithm. This permits setting up coefficients so multiplication can be done a different way faster. That was 1976 and I no longer recall the specifics but the method took advantage of the fact that shifting a binary number does an instant multiply by shifting the binary “decimal point”. I modified the design to handle arithmetic in this way – the computations could now be done fast enough. I presented these findings to Dr O’Kief of TRW, which he rewrote for distribution within TRW.

Princeton Algorithm Mechanization Princeton Algorithm Multi Coefficient

Executive program A time shared processor required an executive program – and a means of communicating with launch control for periodic check out.

Dr O’Kief’s Appraisal: We were at TRW Redondo going over concepts for what I called a Digital Signal Processor, when Ken leaned back and said, “this design is fantastic – but it’s not a processor, it’s a full up programmable computer.” Since I didn’t know about computers, I’d never thought of it that way, I was only following my nose, making use of new devices to do necessary signal processing; going another step each time to solve a problem. It was then Ken the told me, his Phd was in computer science. I asked, why didn’t you tell me? He said you were so far ahead from what we were doing in school I was too embarrassed – especially when you kept telling me you didn’t know what you were doing. We discussed how this came about. Not knowing what I was doing was true, and in a way helpful. Each day I faced something I didn’t know how to do and innovated. The availability of supplier information on new parts and access to an expert like Dr Bona plus knowledge of missile control, made it possible for a non-expert to ride a wave of technology change.

Autonetics Presidents: John Moore Navaho & MM 1 Fred Eistone MM 2 & 3 Don Williams MM 3 & MX

Fred a graduate of K-State prematurely died of cancer

Lou Purpura Darrell Landau Jim Anderson Frank Lettang Elliot “Buck” Buxton Dr Bob Nease

Due to Buck’s efforts we were contracted to do the MM 3 Post Boost System. Though Buck recovered somewhat from his stoke he was trapped by circumstance – before retirement benefits were set up to handle needs of the disabled.:

System Review Elliott Buxton, chief engineer for MM 3, recovering from a stroke, came by to see what we were doing and was quite impressed. Some time later Chief Engineer Tom Shuler came by and after a brief look said I want Dr Bob Nease (chief scientist) and Dr Tom Gunkle (head of computer department) to see this. Gardner and Lofgren happened to be gone and I played host to Tom and Bob for almost a full day – they were truly professionals and I an amateur in their domain – they were nice and listened to this hydraulic & rocket engine guy tell them about their specialty. Tom mostly listened while Bob asked questions as I went though the why of each segment of the design concept. Tom was probably aware I’d been working with Dr O’Kief who attended Tom’s briefings on a pending MX flight control computer. Tom would have been aware we were paving the way for what would come under his domain if we received a contract based on current advanced planning. Neither had prior experience in the nitty gritty of thrust vector control.

Gas Turbine Servo-Actuators failed when tested by Autonetics. There were two competing kinds: One used the output of a gas generator to drive a gas motor which drove a flex shaft about a 90 deg turn to power a mechanically clutched servo. The other method delivered hot gas direct to turbines built into the linear motion actuators. We were asked to test the one with the flex drive. I was invited to look at the experimental unit – I pointed at a sleeve bearing and said that’s the weak link. Sure enough that bearing took a beating. When asked why that had seemed obvious I said I used to work in Everett McGee’s tire shop in Oberlin KS and found it very difficult to hold a flex shaft – and that was only with a ¼ hp motor – not start-stop of 100 hp – making a 90 degree turn with a flex shaft placed a huge load on the small sleeve bearing.

Return to proven hydraulic servo actuators We with MM 1,2,3 flight control experience were convinced the use of these experimental gas powered actuators could be a disaster for the MX program. We agreed we should apprise Buxton of our concerns and ask him to speak with his MM 1,2,3 TRW G&C Flight Control friends of our concerns. We appraised Buck of our concern that the propulsion people had become enamored with their experimental mechanism while excluding proven hydraulics. Jim Anderson had been in contact with Moog who were ready with hydraulic servo’s actuators designed for the application. Buck spoke with key TRW G&C people as did Moog. AF and upper TRW management decided to place responsibility for thrust vector controls back under G&C who called for return to proven hydraulics technology. The need for 7 th order digital filtering and the Princeton algorithm went away.

O’Kief footnote 1 When out to lunch O’Kief told me of his night class on Mexican history and I told him about my night class on biology; of a paper back book on DNA by Asimoff and a book by Watson, co-discoverer of DNA, on Molecular Biology

O’kief footnote 2 Returning from lunch Ken asked” “do you think it would be possible to make a computer that could replicate itself? His question caught me off guard, I’d never given any thought to automated assembly of our signal processor. I pondered his question, imagining an automated production line. I could imagine automating everything except the supply of parts. I said, “no, we could not automat the supply of parts.” Ken smiled and said, “I’m looking at one.” It took an instant to change gears and recognize what he’d said. We humans are computers that auto replicate ! For days I pondered, how does nature handled the supply problem. About a month later, observing particles drift in the back yard pool, it came to me. I knew from Molecular Biology how atoms can assemble themselves by chemical attraction to a chemical code which took place in a fluid environment. Random thermal motion of a liquid can transport chemical parts for assembly to a pattern that rejects all but those that fit the code key. Life began in the water and all living things need water to transports the chemicals of life.

Without a Job Autonetics received a contract for the Guidance and Control system for the MX missile which defined a configuration where the booster servo-actuators were to be controlled by upstage electronics. I had worked myself out of a job. But not for long, I was sent to help restart the B-1B.