Upon graduation from University High School in June of 1966, Dave took a summer job assisting graduate students doing research on bi-stable fluid amplifiers at the University of Nebraska Hydrodynamics Laboratory.
In September of 1966 he enrolled as an Electrical Engineering major at the University of Nebraska. He graduated (BSEE with distinction) from this five-year curriculum in four and a half years. During that time he received two scholarships awarded without regard to race or financial need. He was elected to Phi Eta Sigma (freshman), Pi Mu Epsilon (math), Eta Kappa Nu (electrical engineering), and Sigma Tau (engineering) honorary fraternities, and was a member of Triangle social fraternity.
During the first semester of his third year, he was the Advertising Manager of the Nebraska Blue Print magazine. He was appointed Editor during the second semester, and remained editor during his fourth year.
During his fourth and fifth years in college, he taught one of the electrical engineering circuit laboratories. He wrote the syllabus for a DTL digital circuit laboratory. (Diode Transistor Logic was used briefly in the days before RTL, TTL, and CMOS digital circuits were invented. The DTL circuit modules were made of discrete components potted in a solid black plastic box. )
In his spare time, Dave played in a rock and roll band, and gave as many as 30 guitar lessons a week at Dietze Music House.
Before the first semester of his fifth year, Dave was given a low draft lottery number, virtually assuring that he would be drafted and sent to Viet Nam immediately upon graduation. Consequently, recruiters generally turned the conversation to football during his employment interviews, and he received no job offers. Upon graduation he was surprised when he failed the draft physical because of a heart condition. He took one semester of graduate classes, mainly so he could keep his teaching job at the University of Nebraska while he interviewed for engineering jobs. At the end of that semester, he accepted a position with the Naval Weapons Center, China Lake, California.
Dave began his career doing analog circuit design for a group that did telemetry primarily for AIM-9 Sidewinder missiles. He personally designed the signal conditioners for the Air Force AIM-9J and AIM-9E missiles. The job generally consisted of designing analog circuits that measured voltages, frequencies, pulses, and output from transducers (such as accelerometers, pressure transducers, and roll gyros). These signal conditioning circuits produced outputs in the range of 0 to 5 volts at data rata rates compatible with 100 KHz Pulse Amplitude Modulation (PAM) telemetry.
When President Nixon decided to mine Haiphong harbor in 1972, Nixon had a problem. He wanted to give the civilian boats time to get out safely. It was too dangerous to announce that the U.S. was going to lay mines, giving the civilians time to get out. The enemy would have known what the U.S. was going to do, and would have tried to stop it with potentially great loss of life. So, President Nixon ordered the Naval Weapons Center to design some special mines with very long arming delays. These mines were dropped in the harbor, but did not arm themselves for several days. This gave the civilian and neutral boats time to get out of the harbor safely. Although Dave did not design the mines, he worked the graveyard shift for a couple nights soldering integrated circuits onto circuit boards. The elapsed time from President Nixon's order to design the mines, until the time when they were dropped in the harbor, was less than two weeks.
Dave designed the complete telemetry package for the Agile missile, including a unique mechanical configuration that held the circuit boards. Agile was the real-life version of the missile that James Bond fired from a helicopter, made a U-turn, and destroyed the enemy that was pursuing him. Agile was an infrared missile with an optical system that allowed it to look behind itself. It had a "thrust-vector control" airframe. That means that instead of using wings to steer it, it had a flexible nozzle on its rocket motor. This allowed it to turn very sharply.
In 1974, when Dave had finished the telemetry package for the Agile missile, he transferred to the group that was designing the Agile seeker. He helped develop the technology that pointed the Agile seeker wherever the pilot was looking, allowing the seeker to lock onto a target without having to point the airplane at the target. The pilot merely needed to look at the target to acquire it. To do this, Dave had to improve the Agile seeker's servo loop, increasing its closed-loop gain to a value ten times greater than the loop gain Sidewinder used at the time.
By 1975, Agile had several successful launches. Then Congress got involved. Agile was being developed to satisfy the Navy's need for a missile which could be fired from a bomber at a pursuing enemy fighter without having to deviate from a course which would take the bomber over the intended target. (If the defender can make an attacker turn to engage the defender, the attacker can't drop the weapon on the intended target, which defeats the mission.) At the same time, the Air Force was developing the Claw missile to support its need for a large number of small, cheap, low-performance missiles that could be fired in large quantities in a target rich environment. Congress got the stupid idea that one missile could perform both missions. Congress canceled both programs (which were both very close to successful completion) and took the money that had been allocated to complete them, and spent that money (and more) on a study to determine the requirements for a common missile. The study of course concluded that one missile could not satisfy both requirements. By that time, however, the teams that were working on Claw and Agile had been broken up and assigned to other projects. New teams would have had to have been formed to start nearly from scratch. As a result, neither Agile nor Claw were ever built.
In June of 1975, when Agile was canceled, Dave took two weeks of annual leave. With just the data sheets for the Motorola 6800 microprocessor, he taught himself how to program microcomputers. He wrote a program called "Space Ping Pong" and submitted it to the "World's First Microprocessor Design Contest" sponsored by EDN magazine and Motorola. He came in fifth, and won an HP 21 pocket calculator for his effort. (That was back in the days when Pong was the only video game, and pocket calculators cost several hundred dollars.)
Younger readers may not have ever seen a Pong game. It was essentially a two-dimensional tennis game viewed from above. The ball moved left and right. The players had knobs which moved the paddles up and down. If the ball hit the paddle, it changed direction and went toward the other player's end of the table. If the ball didn't hit the paddle, the ball went off the screen and last player to hit it scored a point.
Space Ping Pong was a tennis game viewed from the side. Each player had an analog joystick that moved the paddle left and right as well as up and down. The program calculated how hard the paddle struck the ball, and determined the resulting motion. The user could select gravitational forces equal to that found on the moon or Jupiter, as well as the Earth, to make the game more challenging. The game was never actually built, but Dave did write the software for it. This meant he had to write algorithms that solved differential equations of motion. This would turn out to be important later.
Coming back from annual leave, Dave found himself assigned to the AIM-9L Seeker branch. His first project was to work on an Automatic Gain Control (AGC) amplifier for a photocell detector. It soon became apparent that he needed to do transient analysis that would take into account the characteristics of the nonlinear AGC loop. The differential equations were the electrical equivalent of the mechanical differential equations he had just solved for the Space Ping Pong game. So, he used them to simulate the AGC response.
These equations worked so well that he simulated the entire AIM-9L seeker with them. This made it possible to see the effects of design changes much more rapidly than building hardware prototypes. Only the most promising designs were built, and they worked as predicted.
He published articles describing how to design AGC circuits ("Designer's Guide to Basic AGC Amplifier Design", EDN Magazine, 20 January 1974) and the equations for analyzing and simulating non-linear circuits ("Simulate Analog Circuits with Digital Filtering Equations", EDN Magazine, 5 October 1976).
Dave also used the discrete time equations to simulate the motion of the missile, target, and flares used as infrared countermeasures. This allowed him to evaluate various kinematic counter-countermeasures.
In 1976, the AIM-9L Seeker branch purchased a PDP-11/20 computer with analog interface cards. It was supposed to have the capability to simulate missile flight in real-time, and control a rate table and infrared source, so the AIM-9L seeker under test would experience realistic flight conditions. The cycle time of the simulation program had to be 62 milliseconds or less. Unfortunately, the BASIC interpreter and RT-11B operating system were much too slow to do this. So Dave converted the program to machine language, and wrote a monitor/debugger in machine language. The simulation program involved some very slow trigonometric calculations. Dave replaced them with lookup tables. He even created some base-2 logarithm lookup tables for faster multiplication and division. Dave's simulation had a cycle time slightly over 4 milliseconds, 15 times faster than required. Dave published the base-2 logarithm technique in EDN Magazine. ("Lookup Tables Provide Quick Logarithmic Calculations", EDN, 5 August 1977.)
It was at this time that the Battlefield Surveillance Radar (BSR), later called the Foliage Penetration Radar (FOLPEN), needed Dave's help. U.S. armed forces had suffered heavy losses in Viet Nam because enemy soldiers were able to sneak up on our jungle outposts. The FOLPEN radar was designed to detect slowly moving people approaching in dense foliage. It was a project with a lot of support, despite the fact that our intelligence sources suggested that the next war would probably be fought in the "jungles" of Iraq.
The contractor who was supposed to be building the special-purpose digital processor for the FOLPEN radar was way behind schedule, and way over budget. Dave overheard the BSR project manager asking someone else if the AN/UYK-30 processor could do the job. There were a number of reasons why it was not practical, so Dave suggested they use an LSI-11 processor, which used the same instruction set as the PDP-11 did. Dave wrote the signal processing software, and had it running on the PDP-11 before the LSI-11 was delivered.
The heart of the FOLPEN radar was a balanced processor that required two information channels to be closely matched in phase and amplitude. Dave invented and published a graphical method to determine the magnitude of the difference of two vectors ("The Pogge Plot: Vector Arithmetic Made Easy", EDN, 20 August 1975). He later invented an improved signal processing algorithm for the FOLPEN radar and was awarded U.S. Patent 332,397 for it. Despite the fact that the FOLPEN radar was hopelessly schedule behind when Dave joined the project, it was actually completed six weeks ahead of schedule.
Dave's next assignment was to build an exact replica of a shoulder-launched IR missile seeker that was being manufactured by a well-known communist nation at the time. He discovered that the design was very sensitive to individual transistor parameters. By substituting various transistors, he discovered how the system was supposed to operate. He then partitioned the seeker into functional blocks, and redesigned each block with American integrated circuits. Each block performed exactly like the original, but used fewer parts and did not have to be hand-tweaked during assembly.
Since he got finished several months early, he assisted with the design of the grip stock for that same weapon. In the process, he inferred from the schematics that the weapon had a previously unknown operating mode. He reported this to intelligence sources, but they said they were sure the weapon absolutely did not operate as Dave said it did. Finally, after much insistence, they agreed to investigate. They discovered the weapon not only had the mode of operation Dave said it did, but that was the most useful mode.
The replica Dave designed was produced without difficulty in moderate quantities.
It was used for training and analysis of susceptibility to countermeasures.
Working with foreign material is fun, but limiting. If you think of some way to improve it, you aren't permitted to do it. That's because your copy must work exactly the way the original does. It is of no use if it works better than the real thing. So, with the successful conclusion of his foreign IR missile seeker project, Dave went back to microprocessor design.
In 1978 and 1979 Dave took a part-time job at Cerro Coso Community College, teaching microprocessor programming two evenings a week. He spent $3,000 of the college's money to buy laboratory equipment, wrote the course syllabus, and wrote the textbook for the course. At the time he was also producing a weekly religious radio broadcast, The Word With Us, that took about 10 hours per week to produce. (The Word With Us aired on KZIQ from 1979 through 1984.) The college job took a lot of time, and didn't pay very well, so he turned the class over to another teacher.
During the day, Dave was writing the firmware for the DSU-28B Target Detecting Device (commonly called the "fuze") for the AIM-54C Phoenix missile. The DSU-28B used an 8080A microprocessor, with four 2Kbyte ROMs (later versions used an 8085 with two 4-Kbyte ROMs). This was the first NWC Fuze Department project to use a microprocessor. There were no procedures for firmware documentation and management. Dave had to develop software development procedures as well as the software itself.
This was a challenging job more from a management aspect than from a technical aspect. The bureaucracy didn't know how to handle microcomputers. Congress had mandated ridiculous controls making it difficult to buy computers. The 8080 chips were considered computers. A waver form had to be filled out for each 8080 purchased, explaining why the DSU-28B did not use the mainframe computer that ran the payroll program. The fact that the computer was going to be put in a missile, fired at an enemy aircraft, and blown to bits, was not sufficient justification for some bureaucrats for not using the existing mainframe computer. These were difficult days. The computer that controlled the test equipment used to test the DSU-28B a HP 9825 desktop calculator. Hewlett Packard understood government procurement rules very well! Dave was appointed as a member of the Fuze and Sensors Department Microprocessor Committee, which worked to bring sanity to microprocessor management practices.
The DSU-28B was ready on schedule, but the AIM-54C guidance section was not. That meant there was no vehicle that could take the DSU-28B close enough to a high-speed target to test if the DSU-28B could detect a target or not. Dave came up with a plan to test the DSU-28B against a supersonic target on the ground.
Tests of missile guidance sections and aircraft ejection seats are conducted routinely at the Supersonic Naval Ordinance Research Track (SNORT). Rocket powered sleds carry payloads at supersonic speeds along the fastest railroad track in the world. Dave wanted to put the DSU-28B on the ground, near the track to see if it would detect the rocket sled as it went by. The only problem was that somebody had to be right there with the DSU-28B to turn it on and measure the output. Even if someone foolish enough to do that could be found, the Safety and Security Department would not allow it. So, Dave designed a little droid, named R2D3, to do the job. R2D3 was a standard 19-inch wide equipment rack, 30 inches tall, on wheels. It contained an analog instrumentation recorder, power supplies, relay cards, and an 8085 microprocessor. R2D3 successfully took data from the DSU-28B on every test run, despite getting thumped by a sonic boom each time.
Dave had some time on his hands, waiting for the guidance section to get finished, so he started improving the telemetry for the DSU-28B. The Phoenix missile used the same kind of telemetry system (64 channel, 100 KHz, PAM) that Dave had worked with at the beginning of his career. As was usually the case with Sidewinder telemetry, the fuze designers were left out of the initial telemetry design. So, the 64 channels were apportioned as normal--5 channels for synchronization, 58 channels for the guidance section, and 1 channel for the fuze. All the diagnostic information for the fuze had to be multiplexed onto a single channel. Dave did this with a clever combination of steps, pulses, bi-phase digital data, and NRZ data.
The DSU-28B is a smart fuze. It determines when to detonate the warhead based on a variety of parameters, including distance from the target, altitude, closing velocity, aspect angle, type of target, etc. Some of this information it determines itself. Some of the information it gets from the guidance section. It is necessary to know what the guidance section told the fuze to determine if the fuze did the correct thing. So Dave also included some of the guidance information on the measly one telemetry channel allotted to the fuze.
The telemetry output was very complicated, as you can imagine, and Dave was the only one who knew how to read it. That meant he had to support every test flight. After each test flight he would analyze the oscillograph output to figure out what happened. This was a tedious job that took hours.
It was especially odious for those flights that were done at the Pt. Mugu Sea Range, which is about a 3 hour drive from China Lake. Typically a launch would be scheduled for 7 AM. Dave would leave China Lake at 3 AM get there in time. It would be foggy, however, and the launch would be delayed until 11 AM. At 11 AM a higher priority test would be scheduled, so the launch would be delayed until 1 PM. At 1 PM a Russian "fishing trawler" (with lots of antennae) would be spotted on the range, so the launch would be delayed while the Coast Guard would go out to chase it away. Finally, at about 5 PM, the range would be clear, but the light would be too bad for video tracking, so the test would be rescheduled for 7 AM the next morning. This routine sometimes went on for three or four days before the launch actually happened.
It didn't take long until Dave couldn't take it any more. He built another droid named James Baud. James Baud was built in a standard government-issue plastic briefcase. It had BNC connections for IRIG-B time and the telemetry signal. It had an RS-232 serial output for a 7-pin dot-matrix printer. It also had a 110-volt AC power cord that plugged into the wall. James Baud had an 8085 microcomputer and 2 Kbyte ROM containing a program that knew how to read IRIG-B time signals and interpret the telemetry data. One merely had to press the reset button, and James Baud would print out the date and time. Then James would sit there quietly until something happened on the telemetry line. When it did, James printed out the launch time, the time when the fuze armed, how far the target was when it was detected, what the closing velocity was, etc. Everything you would want to know was printed in plain English on the dot matrix printer.
The DSU-28B worked almost flawlessly in every test. The same could not be said for the guidance section. Most of the first tests never guided close enough to the target for the DSU-28B to detect anything. By the time the guidance section worked well enough to get close to the target, Dave was using James Baud instead of interpreting the output manually. This was fortunate because the first few tests that did get to the target appeared to be fuze failures, but weren't really.
In one particular test, video showed that the missile went right by the target, but the warhead didn't go off. This was a very high-profile test, with lots of VIPs watching. Before the missile hit the ground, Dave had the printout from James Baud, telling in plain English that the DSU-28B had detected the target, had generated a fire pulse at the proper time, but the safe-and-arm (S&A) device had failed to arm. (This was the first of several such failures, which resulted in a redesign of the S&A.) The VIPs were assured it was NOT the DSU-28B TDD's fault.
In another test, the warhead failed to destroy the target on an extremely long range shot. James Baud immediately diagnosed the problem. The guidance section, which had not been programmed to take into account the fact that the world is round, thought that the missile had gone underwater when it went over the horizon. This was immediately obvious from the erroneous altitude information sent to the fuze. It took the contractor two weeks to analyze the guidance section telemetry and confirm that the guidance section had this problem.
In September, 1985, Dave transferred to the Electronic Combat Range, which was called the Electronic Warfare Threat Environment Simulator (EWTES) at the time. He worked in a group that was called the Test Support Branch, Code 3551, until April 1988 when it was renamed the Software Engineering Branch, Code 6441. In more recent years that same group has been called Code 6447, 3331C, 525600D, 525700D, 525300D, and is (for the moment) called the Data Systems Branch, Code 527300D.
Despite all the name changes, it has been basically the same job. The computers have changed from Gould SEL 32/9780 computers to SUN and SGI workstations, and Pentium PCs. The language has changed from FORTRAN to Ada, but the work remains the same. Data is collected from threat radars and other tracking systems and displayed in real time. Dave has written several programs that take this data, process it, and display it in various ways for a variety of customers. This involved writing programs that interface with IEEE-488 instruments; obtain data from special direct memory IO devices; use TCP/IP and UDP network interfaces for client and server tasks; and interface with low-level graphics.
Specifically, he wrote and documented a 70K source line of code (SLOC) graphical display program in Ada. It was completed on time, at a cost of approximately $300K. That's more than 50 lines of code per calendar day (not work day), and a little more than $4 per line of code. This program is functionally equivalent to a display and control program that a contractor wrote for another test range at a cost of over 4 million dollars, and was several years late.
During that time he also wrote a 15K SLOC preamble server, a 23K SLOC project server, a 4K SLOC clock server, a 13K SLOC user server, a 27K SLOC controller simulator, a 16K SLOC target simulator, plus test software. About 90% of the code in the simulators and servers is software that was developed for the display program. He knows how to write reusable software!
More recently, he wrote the Surveyor program, which allows the user to compute the relative position of surveyed data points, expressing the results in a variety of coordinate systems. Surveyor is an Ada program which resides on a server accessible to all ECR computers connected to the corporate network. Test managers, data technicians, and radar crews all access this program using their favorite web browser (Explorer, Netscape, or Mozilla). Surveyor presents them with easy-to-use forms for data input, displaying the results in another form when the data entry is complete. Surveyor is different from the program it replaced in that every user had to have a copy of program on his or her local machine. Every program had to be updated every time a new survey location was added. But the new Surveyor program reads data from a central database, which means that all users have access to the most current data without having to update the programs on their computers.
As a member of the Embedded Computing Technology Office (ECTO) committee, he helped plan and run the Embedded Computing Technology Symposia in March 1986, March 1988, and November 1989.
Dave taught Ada programming classes for the Naval Weapons Center Training Center from 1988 through 1994. During this time He was the Naval Weapons Center's representative on the KAPSE (Kernal Ada Programming Support Environment) Interface Team (KIT). On May 20, 1988, this group produced the Common Ada Programming Support Environment (APSE) Interface Set (CAIS), DOD-STD-1838A. In 1989 he was selected to be the only Navy Ada 9X Distinguished Reviewer. The Distinguished Reviewers gave technical assistance to the Ada 9X project office, which produced the Ada 95 Programming Language standard.
On June 15, 1990, Dave was made an NWC Fellow. This is
no small honor. His plaque reads
R. DAVID POGGE
IN RECOGNITION OF YOUR ACHIEVEMENTS IN ANALOG AND
DIGITAL SIGNAL PROCESSING, USE OF MICROPROCESSORS IN
FUZE DESIGNS, AND SUPPORT FOR ADA.
Dave helped write the "Draft Guidelines for Common Real-Time Graphics Environment" for the Range Commanders Council in December of 1992. In 1993, the Naval Air Warfare Center's Deputy Commander asked him to participate in the Software Process Improvement Initiative. In 1994 he was selected to be a member of the Data Systems Technology Team to study commonality between the Electronic Combat Range, the China Lake North Range, and the Pt. Mugu Test Range.
Dave became frustrated with the long review cycles that are required to publish anything that can be attributed to the Navy. By the time the review cycle is complete, the information is no longer relevant. Since 1983 he has used the pen name, Do-While Jones, to avoid any association between his personal experience and Navy policy.
In 1996, Dave helped found a California non-profit public benefit corporation called Science Against Evolution, of which he is currently the president.
From January 8, 2005, until it moved to Van Nuys on January 16, 2010, he volunteered at Ridgecrest's Biblical Archeology and Anthropology Museum (BAAM), and maintained the museum's web site.
Dave retired on February 28, 2005, after nearly 34 years of Federal service.