I started programming computers in 1977 and was quickly addicted. It was simply amazing to me, the power that was available literally at my fingertips. I was limited only by my understanding. Making the computer do what I specifically wanted it to (at first even the most trivial things), took long days and nights as I struggled with all the new abstractions. I didn’t even know what was meant by a “variable”. I’m not joking either. I’m not talking about syntax, I’m talking about basic concepts. Defining one, giving it a value, inspecting its value, and especially using it to control the flow of a program were all brand new to me. I could stare at just one page of the little book that came with my TRS-80 for hours – and then do it again the next day. Once you’ve learned a programming language, they start falling like dominos. The first one was really hard though. It took me months to move beyond BASIC. But trying to write video games on a computer with 4K of RAM was motivation to do so!
In the early ’80s after a few years of obsessing at home writing video games and the like, I managed to get a job at Scientific Atlanta (2nd job) through a lab-tech friend of mine that I had been interacting with, learning more about digital electronics. At the time, Scientific Atlanta (and most of the world) was early in the process of using microprocessors in the devices they manufactured. I was tasked with writing the firmware for a new antenna position tracking device. Like the name implies, this was a seemingly simple device with a digital display that showed the angle of rotation for a microwave antenna. Position indicators were used primarily during construction of new microwave antennas, where prototypes would receive signals while being positioned at virtually all possible azimuth and elevation angles, while recording equipment would store amplitude modulation data that was also correlated with the position in an antenna test range.
The work was led primarily by Bob Hyers who was the principal engineer. Beyond Bob’s detailed work on the high level design, the real work was done by two engineers Steve and Charles. We quickly became good friends, and they taught me how to work with the prototypes they were building in the lab, as we worked on getting things working a little more every day. Steve and Charles were responsible for defining exactly what components to put in the unit, and they laid out circuit boards and all interconnections. Then came me – the unit was not going to do anything at all in the way of indicating or transmitting antenna positions without somebody to write the necessary software. I learned from the ground-up how to debug code in a lab environment with no user interface, just an oscilloscope and some pretty amazing debugging tools (logic analyzer) that were more powerful than anything I used before or since on traditional computers. My software handled every button press, changing display modes, actually calculating the position of the antenna as a decimal angle of degrees, and displaying the position or transmitting it to other test-range equipment in a timely manner.
It was on the last point of having timely position that was at the heart of most of the complexity in the design. Scientific Atlanta already had a position indictor at the time and used it heavily. The positions it indicated were perfectly accurate too. The problem was that the position was not calculated frequently enough. Since the antenna in the test range is moving, by the time you get position data it’s already out of date due to group delay. So to make a good graph of position vs. amplitude modulation, the antenna had to be moved very very slowly as thousands of data points were recorded. This took a long time to do. Then the antenna might undergo some changes to make improvements, and the whole process had to be repeated. The problem was further complicated when the signals being transmitted were distant from the antenna receiving the data. The new position indicator would radically improve on these problems.
None of the engineers knew a thing about writing computer code. So in that sense I had a blank slate. But the algorithm was still well conceived before I came onboard. The goal was to generate accurate position data every 200 nanoseconds (ns). When I first heard this, it sounded like an impossible problem for a microprocessor of the day. The hardware design was based around an Intel CPU with a hardware clock ticking at 5 MHZ, which happens to be every 200 ns. But it was in fact impossible for the processor to calculate anything in just one tick of the clock! Even a single microcode instruction can’t execute in a single tick. But learning more, I discovered that the design was not as crazy as it sounded. It was also an opportunity for me to let my programming abilities expand a lot given the nontrivial behavior that would be called for to pull it off.
The hardware of the 1885/86 Antenna Position Indicator as this model was known, included a “rate counter”. This was a device that could indicate a changing angle, and steadily increment that value by perhaps a few thousands of a degree every 200 ns. – all with literally no action taken by the microprocessor. As intelligent as the rate counter was (including wrapping a 359.9999 position to 0.0000 at the next increment), the rate counter did not know what angle to display and did not know what increment to apply to it at the next clock tick. Telling the rate counter what to do was the job of the firmware I was to write. But in order to save manufacturing costs, my ability to control the rate counter was very limited. I could in fact not even tell the counter what angle to display! All my software could do was to change the increment that the rate counter would apply at each clock tick. Essentially, I could find out what position the counter was indicating “now” (more on that later). And I knew what increment it was currently applying at each tick (by remembering what I last told it to use). And finally, I knew the current position of the antenna. So I have these three inputs: the angle being displayed, the actual angle of the antenna, and the increment being used currently. It was up to my software to now generate one little piece of information – what should be the new increment the rate counter was using? That was my single means of controlling the position output. So it was up to me to see that the indicated position would reasonably quickly converge on an accurate indication of antenna angle.
While the hardware seemingly tied my hands behind my back, this was my favorite kind of thing to code. I want nothing more than a seemingly impossible problem that in fact has a solution. Don’t get me wrong though, the problem had been figured out already, including very detailed mathematics that my software should apply in the solution. But as always, there’s a million miles between a concept and a working device. A successful project takes competent engineers building the device and for a reasonable cost that turns a profit for the manufacturer.
The firmware I designed to do this was organized around a core software routine that was interrupt driven. Every 16 milliseconds (ms) the hardware would raise the interrupt-line on the CPU. Doing so would cause the CPU to execute an INT instruction. This meant the CPU would save its current instruction address (i.e. the address of the next instruction it plans to execute) on the system stack. Then it would immediately jump to the address of the interrupt handler (pointed to by a table in the first page of RAM). There, was a tight little piece of code I wrote in assembly language (but most of the code was written in C-language). The function of the interrupt handler was to schedule the most high priority task defined in my self-designed SAMOS (Scientific Atlanta Multitasking Operating System). There were various tasks for the software to regularly perform, including updating the display, responding to button presses by the operator, transmitting position output to the front panel or other devices on the serial I/O bus, and miscellaneous maintenance and diagnostics tasks.
As its last step the interrupt handler transferred control to the SAMOS scheduler to execute the current highest-priority task and that happened to pretty much always be updating the position. To calculate the angle, the code would read a couple values from the synchro that was attached to the base of the antenna. These values were not in constant motion, like the antenna itself. Instead they were latched at the time of the interrupt immediately beforehand. By applying some trigonometry to ratios from the synchro, it was possible to generate a digital angle in degrees. Like many things though, even that was a lot harder than it sounds given the real-time requirements of the device. The trigonometry calculations could naturally be done with floating point math. But to do that would mean using a floating point library, given the limits of the instruction set on the 8088 processor. That would have been way too slow. If, in the execution of this task, the software takes too long to calculate the angle and the new rate and along comes another interrupt signal then you’ve failed! That’s an overspeed-condition. It’s absolutely essential to prevent that. Downrange measurements will be wrong to a degree that’s supposed to be impossible.
Various techniques were used to multiply or divide without using floating point arthmetic. In some cases the code just looked up a number in say a 1KB table stored in ROM (truncating index bits as necessary, but also often using them to skew the looked-up table entry). Another simple example would be to use the processor’s shift-left instruction to shift a variable by a small number of bits (where each shift is a multiply-by-2), then multiply or divide integer variables (usually by a pre-calculated constant that’s also been shifted). That generates an integer result, then finally use the shift-right (divide by 2) to get the result back in the intended scale. It takes a lot of care with the scale of the numbers to avoid overflow conditions, while still achieving accuracy requirements.
As always, latching was key to synchronizing the calculations done in the firmware with the time of the moving antenna. Input latching means that the software is always calculating using numbers that are now obsolete given the moving antenna, but were known to be accurate at a specific moment in the recent past. Output latching means the software calculates updated rate values the equipment should now apply, but the change is only applied at a well defined moment in the near future. All this makes it possible to make precise measurements and control, in spite of the variable response times in the software.
As a point of real pride, I was named on the United States Patent 4,853,839 for Antenna Position Tracking Apparatus and Methods. The basis for calling this a new invention, is that for the first time this results in a position indicator with zero group delay for an antenna moving at a constant velocity. It does that essentially by predicting where the antenna will be in the near future, rather than always showing obsolete position data. I’m named as one of four inventors – Steven Nichols, Robert Hyers, Walter Stovall, and Charles Trawick. Good times I’ll always remember fondly.
(use the tool-bar for full-screen and zoom/turn pages, how it all works is on pages 20 & 21)