MILSTAR - AFSATCOM Transition Terminal
Specialist on Communications, INIT/BIT, Machine Code
Specs: 22,250 mile orbit, 5KW Solar Array, 51' x 116', 10K lbs. 224 secure channels.
Uplink:44 GHz EHF, 300 MHz UHF.
Downlink: 20 GHz SHF, 250 MHz UHF.
Survivability and endurability requirements are satisfied by anti-jam, hardening and system autonomy features.
Once again, I'd decided to work through my Mom's Consulting Company; and once again it worked against me. When you walk into the interview, and someone says, "So you're Fran's kid?", you know you're in trouble. Ah stigmas.
This was the last major contract I did for my Mom (I went back to finding my own jobs, or using other agencies or contacts). The interviewer grilled me, and when he couldn't stump me, he brought in a few other seasoned engineers to grill me with questions like, "what is the difference between recursive versus reentrant", and "I'd like you to create examples of each (in assembly) language on the whiteboard" and explain your work. I did fine. It gave me a confidence after that, that someone who was obviously trying to find an excuse NOT to hire me couldn't find one (along with his team). They hired me for another "6 month contract" that last 3+ years.
Collins was working on the MILSTAR Satellite Communication Terminal. They put up a bunch of satellites to relay military communications on many frequencies and using a variety of techniques (hopping, phase and frequency modulation, and so on). Good stuff. I like the military attitude; when it absolutely, positively has to get there. This was the follow on for a previous solution called the AFSATCOM; which was just the simpler version of these satellites. Rockwell, was doing the terminal that communicated with them (from the ground) and was used for most of the secure military battlefield communications. More than just that, we had to do the transition device; not only had to speak the new protocols (MILSTAR), but also all the old protocols (AFSAT) - so that if anything happened during this transition, that the military could communicate on either or both. Which made this terminal more complex than either of the others on their own.
I started because of my Assembly language and low-level communication skills. I was given an older DataGeneral (AFSATCOM) and "newer" Rolm Micro/Mini computer. The older device had core memory. Core memory was made before you had RAM, it was little magnetic donuts, each wire-wrapped individually. It would ring when it was running, because the magnets would charge the wires and cause them to vibrate. I'm thinking, "I'm programming a fricken piano". I'd done some lower level stuff in school and home, like burning my own processors (back when you used to program them with the instructions you used to run on them) programming microcode and the like; but I had no idea that I'd actually be using this stuff. The good news about Core Memory was that you could pop a nuke next to it, and it wouldn't fry (as easily) as RAM or other chips. (It was resistant to EMP bursts).
Not any more: You have to understand the military thinking; it can be slow, it can be expensive, and it can be old; but the damn thing has to be rugged and work. They usually design stuff to be operated by someone with not more than a 10th grade education; not because most military people are that uneducated - but just in case some are. Almost everything is made of many modules that can be replaced. That can cost money and performance, but in their minds it saves lives; which are more expensive.
To give you an idea of how far they go, we had two "processors"; which were really mini-computers. Each one was about 3 1/2 feet by 2 feet by 1 foot long. Each was made out of a single block of machined aluminum. Something about machining a solid block of aluminum was better at nuclear resistance than just bolting and welding pieces together; for only 10 times the cost. It was slower than my first home computer, but cost many tens of thousand of dollars.
So one day, the Air Force was coming by for some progress meetings. And one tech is moving two of these from one lab to another. He goes from the linoleum to the carpet with his cart; or at least that was his intent. The cart stops, and the computer keeps going, and bounces and rolls right in front of one of the Generals.
The General gets pissed, under the illusion that this guy works for him, and bellows; "That's a $50K piece of hardware you just let fall off the cart." This laid back surfer looking lab tech gives him a casual look and says, "Not any more". In truth, the processor turned out to be fine, despite the pratfall; and I can't imaging throwing another 100lb mini computer around, and having it still work afterwards.
This was in front of my cube, and I had to bite my cheek hard, to stop from laughing. While the computer was fine; the technician got reamed. The Air Force doesn't like it when you manhandle their toys, or don't treat them with proper respect. The surfer tech didn't get fired, but he was clearly explained the error of his ways.
My first job there was they needed to write something to load the computer from nothing; the bootstrap. This comes from the concept of "lifting yourself up by the bootstraps": you have to write the code to load the code to load the software which loads the rest of the software, which loads the computer. Since, the machine can't do anything until you've loaded it with some program, and you can't load it with something until it can do something. You have to write this to load stuff to do stuff -- but you don't even have the routines to use a keyboard: you put it into the system by using a switch panel: an archaic software engineer torture device, that has a bunch of switches. You flip each switch (but) into either the on or off position (0 or 1), and say "load" and then go to the next address and do the same. When you get many hundreds of instructions loaded, you hit the execute button, and watch the lights flash for a while; and hopefully load enough other code, so you can stop using the switch panel.
This was ancient stuff, even when I was doing it, I started a slogan that went around the office; "U.S. Air Force: work on yesterday's technology tomorrow". Because there was little documentation, I just mapped out the entire instruction set in binary on a one-sheet piece of paper (that others used).
It, like all projects that have consultants on them, was behind schedule and under the gun, and had been screwed up by others before me, which was why I was thrown at it. Shit rolls down hill, and "the new guy" is the valley, and consultants are often the hole at the bottom of that valley. Because I didn't know what I couldn't do, how long it should take (and didn't care) I just went and started over and wrote it from scratch, and got it back on-schedule; actually ahead of schedule. So this meant that now I deserved to be given a tougher challenge. The old, "increase load until failure" technique of motivation, or the reward of hard work is more work.
People often ask why I left consulting. Part of it was that most projects that get consultants are screwed up, which is why they need consultants. At some point, I decided I wanted to help avoid the problems before we needed consultants; and engineer out of the problems, instead of just charging to fix them after the fact.Always behind? The reason projects are always behind is because the actual process of procurement: there's more to it than just this, but it is not as simple as a sound bite and some politicians or media people make it out to be.
There was one project that was even more behind than the rest: there are two halves to the terminal (two separate processors), one for the secure data, and one for the insecure data. My next job was to make the two halves communicate. They thought I had to write a simple serial driver to get the two processors talking (the previous guy had tried and given up). I came on, and after a few days, quickly figured out that something wasn't quite right. (It wasn't working reliably at all).
Sherlock Holmes said, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." Well, my code wasn't the problem, so it must be the hardware. You have to understand in software, new programmers always think it's the hardware, and are virtually always wrong -- so most programmers learn to believe that it's never the hardware. But I brought in my own Cable Continuity Testers and validated that the cable was designed wrong: the lines that put a throttle on sending data weren't wired up right.
I tried to push back on the design and explain proper RS-232 to the hardware guys, but they said, "we're not fixing the cable", so a simple serial driver, became me having to write my own network stack from the ground up (packeted protocols, timeouts, protect against overwrites and so on) all to get around someone not knowing how to design a cable right. It was way more complex than I was supposed to have to do, but as long as I delivered on time, no one cared how I fixed it -- and I delivered on time. My glee at my own cleverness of figuring this out was magnified many months after I left, and 4 others failed to figure it out. But I'm getting ahead of myself.
The bonus was this project had been ongoing for a while, and was a project where two other members of me team, HATED each other and were ready to battle to the death, and take the whole project down with them... and they were both 20+ years my senior and weren't exactly hot on a kid who still had acne, telling them what to do. I guess management figured if I hadn't failed at code, at least I could fail at people management.
My solution was simple (and the immature one), they could both do nothing, and I'd do all 3 of our jobs. They didn't have to talk to each other, they just submitted whatever they wanted to me, I'd ignore it, and write something else to make it all work, and they got credit for the code, while I got credit for getting them to work together.
Tools to make tools
Now just to be "fun" during my time at Collins, I was using 3 different systems at the same time. I had a PC and DOS, a DEC VAX and a DataGeneral (AOS/VS) for our code. And I was dragging my Mac in, and using it as a smart terminal for them all - at least for most of the project; when things went more secure, I had to stop. However, my use of Macs had convinced Rockwell to buy quite a few secured Macs that didn't leave the building; and I ended up spending my spare being a network admin.
The big issue to my productivity was that all the machines used slightly different commands for the same things; so you're constantly using the other machines command for something and getting an error until you remember this machine. (Worse they flipped things like source-desination versus destination-source patterns, and so on). So I did the only thing that would make it better; I created my own Operating System to rule them all.
There's a joke that in software architecture, there's no problem that can't be fixed with another layer of abstraction. Though it's more of a fatalistic true'ism. Well that's what I did for my too-many-languages problem. I had to learn the hard way, why this solution just moved the problem.
What I did was write my own command language in macros, and then implement it on all the machines. Or more accurately, I created hybrid commands, cross-implemented many commands on every machine, so that you could type in any variant on any machine. It was really quite simple; just a bunch of commands to make other commands. In the end, it didn't matter what machine I was on, I could always type the right commands, because they were the same.
This was typical engineering; often you're creating the tools to make the tools to make what you want.
In a way, it worked brilliantly. I was more productive than others, in the day to day stuff. But after a year or two of this, I was near useless if I wasn't on one of my accounts (with my macro-language). And while I was a little faster all the time, there had been a fair amount of time implementing and maintaining it in the first place. If you're going to be there for years, it's probably worth it... but I never did that again. The cost/benefit versus risks just didn't work out right.
Coming of age
We watched the Space Shuttle Challenger disaster on live feed at Rockwell that morning. When it blew up, there was a bit of stunned silence. After a while, I walked back to my desk, and thought about the lives lost, and the politically correct environment, and what it would mean. Then I used a big red cancelled stamp I had acquired, and stamped it in red across a poster that was on my cubical wall: turns out, that was not a politically correct move.
Two Girls, a Guy, and a Sushi Place. Actually, a few more than that. At Rockwell Collins, Sushi became a ritual. I've tried lots of foods; frogs legs, snails, game animals, snakes, and just about anything. After all, if God didn't want us to eat Animals, he wouldn't have made them taste so good: kind of an interesting attitude for an atheist and off-and-on vegetarian, but whatever. While it's common fare today, back in the early 1980's Sushi was something exotic, and this was before "Sexual Harassment" required special training and stifled people's bawdy talk during the two martini (or beer) lunches.
As a consultant you were paid to get things done. Badges? We don't need no stinkin' badges. Over, under, around or through: problems will be solved. Thus permission was something for the political employees to get, I just made things happen because you either solved problems or they ended the contract and got people that could get the problems solved. It made you far more productive than the employees, but a bit of assholes that they resented, because while they were going through the process, you just made political messes for them to clean up.
I had been a bit of a hack in High School and College(s). I was never the worst/best, both because I could be lazy about it, and because I had better things to do. But I could break into systems, and did at various times, and in various ways. But most of it was not criminal or vandalous; it was usually very focused and for a reason (or the conquest of a challenge). I'd gotten over it quickly, especially when a few friends got arrested by the FBI, but as I said, it took too much time, and was too dangerous, and I mostly left well enough alone. I was having too much fun getting paid to be criminal about things. Until one day...
I've had a somewhat interesting life, as have many people I've known. And we humans are strongly made up of our experiences. But our experiences not only happen to us; but if we are smart, we can learn something from what happens to people around us (if their actions/stories truly effect us, and we can learn from it). One person that had many stories, and life lessons, was Dave Quigley; even if some of his lessons were "how not to", or at least just "Life is fleeting, enjoy while you can".
Now I've lived an interesting life, and been one of those people that things either happen to, or happen around. A lot of those experiences aren't necessarily things that I'd wish for; but heck, if I learn from them then they aren't a complete waste. Many that start hearing the extent of my life stories, start staring at me, agape in disbelief - or often just look at me with skepticism, and assume that I have to be a bullshitter, because that doesn't happen to one person (until I present witnesses or evidence). But I've lived a pretty bland life compared to some I know... and a few of those I worked with a Collins. Dr. Roger Parks was one of them.
Again, I lasted a bit over 3 years on a 6 month contract. And again, it turned out I made many friends and one enemy -- but one wrong enemy is all it takes (especially as a consultant). So I left on less than optimum terms: with one enemy and many friends. But when they tried to make me look bad after I was gone, it backlashed, and Karma exposed my detractors as not very bight big-mouths.
It was no big deal; 3 years and 3 major projects was long enough. I'd made many friends, and kept in touch with a few for a while. A couple became my Martial Arts students; one making it to Black Belt and I still keep in touch with today, nearly 20 years later.
Life is about experiences; and Collins gave me lots of them. After like 8 years in Aerospace, I was ready to see what else life had to offer. I went back and did some follow on contracts in Aerospace here and there; but they were all a few months here, maybe half a year there. I was ready to move on, and see what else life had to teach me.