Home
About
Apple
Career
Experiences
General
Graphics
Hardware
History
Humor
Interface
Networking
OS
Opinion
Politics
Programming
Quotes
Reviews
Security
Software
Sound
Thought
Web
Cheap International
Airfare Online
Wachovia online banking
Get Free Coupons Online
Finding the perfect
discount hot tub
Payday Loans
Stock Trading Online
Stuffed Animals
Smart Investing Online
|
|
Rockwell Collins Radio
1985-1988
By: David K. Every
|
Kind:
Created:
Size: |
Article
May 05,2003
11 KB |
|
|
 |
 o after I left Rockwell, I went to work for Rockwell. Rockwell is huge, and a many divisioned hydra. I moved from Long Beach and Airplanes (B1-B), to Santa Ana (Costa Mesa) and Satellites (Milstar).
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. I always had to work harder to prove that I wasn't just "Fran's kid"; and because I couldn't get over the stigma, this was the last major contract I did for her. If I wasn't so stubborn, I would have just walked out. He grilled me, and brought in some others to grill me, with some of the toughest questions they could think of on programming. Things like, "what is the difference between recursive versus reentrant, and I'd like you to create an example of each in assembly language on the whiteboard", and so on. I did fine, and I have to thank him for my first brutal interview; it gave me a lot more confidence. I've had worse since, but the experience was useful. They hired me, and I was in, another "6 month contract".
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.
Never have I worked with such a ragtag bunch of humans. I was only there 3 years, but it seems like a lifetime, or more.
 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"; which while isn't completely possible, is the basics of what I was tasked with. 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. 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.
To this day, 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.
Because I didn't know what I couldn't do, and didn't listen to the politics, I went and did it, 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, let's see how much we can throw at this guy before he fails; or the flipside of the peter principle.
They put me in charge of a project where two others on my team hated each others, and were ready to battle to the death, and take the whole project down with them. They were already well down this road. I just did all our jobs, while they did whatever they did; and things worked out fine. I had to create all the software to test the machine on startup, and verify that it was working. This was another conundrum, since if the processor wasn't working, how you use the processor to tell if it was working? It is mostly possible, but an interesting set of problems. Another year down, and another project completed.
You can read a bit more about both in Nothing in the Archive.
       
Two successes, and two years down, meant they had to make things really tough.
There was one project that was even more behind than the rest. Or maybe it was just that everything is always behind in military projects. There's actually a good reason for that, but this one seemed worse than the rest.
Always behind? The reason projects are always behind is because the actual process of procurement. They have to go to the lowest bidder, and biggest liars. If you tell the truth then you cost people their jobs, throw away money, cost people their lives, and so on. So politics makes lies necessary. And there are legitimate reason for the overruns; you could read some of it at Why does a toilet seat cost $500?. But it is more complex than even that; it is not as simple as a sound bite and some politicians or media people make it out to be.
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. I had to write my own network from the ground up. Packeted protocols, timeouts, protect against overwrites and so on. It was cool stuff. It started out simple; but just kept getting more and more complex.
The reason I had so many problems was that I had no guarantees that data would get from one processor to the other, communications could be lost and reestablished, and I was wrapping many foreign protocols in my own, and so on. So it started easy; just a point-to-point communications protocol. But it ended being nearly as complex as the other two projects combined. While this project turned out to be horrendously challenging, and just kept getting worse (because no one realized what needed to be done); the harder the task, the greater the reward.
   
Now just to be "fun" during my time at Collins, I was using 3 different machines 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; and I was going insane typing the wrong command in the wrong machine. Or some used things like source-desination and others used destination-source patterns, and so on. So I did the only thing that would make it better; I created a 4th Operating System - my own.
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 (or to remap commands to 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. I thought I was real smart until I learned the costs of my "featuritis" and focusing too much on the tool, over the results. While I regained in productivity any loss in developing the stuff, by the end of the project I realized that I couldn't work quickly on anyone else's accounts, and couldn't remember half the commands for each of the machines. The lure of command lines and 'increased productivity' was a false lure. This was one of the things that convinced me of many of the greatest flaws in Command Lines over GUI's; they are very syntax rigid and literal, instead of contextual and loose; like humans. Great for coders and short term, but often sucks for users and long term. Live and learn.
I left on mediocre terms, as you could tell by reading Time To Go. Again, I had one enemy and many friends. But sometimes one enemy is all it takes. 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.
 Format for Printing  Mail
|
|
|
|
