(Mouseover any identifier to decode)
Okay, fast forward to ZAU. I arrived there in August of '73, as previously reported. ZJX, as the prototype NAS facility was the last to get Model 3 (after I left, so to this point, I'd never actually operated with it). By now, ZAU was thoroughly immersed in it as if they'd been doing it all their lives. The upside for me was because I had been an instructor on Model 3 back in ZJX, I had very little learning curve to overcome. Moreover, if I had stayed at ZJX, I'd have had to endure a protracted period before Model 3 was installed, and then with atrophy of my acquired skill, struggle to get up to speed. Jumping in relatively fresh was much better. In fact, it was hardly a speed bump at all.
Nevertheless, after a year or so of FPB (the automated data blocks on the radar) I had gotten quite used to the convenience, and although the jump from Model 3 to the full fledged RDP (radar data processing that was part of the Model 3 package) would be relatively quick compared with FPA to FPB, they were nowhere near ready to go with it at ZAU. In fact, I'd probably been there six months before they started briefings on it. My memory is foggy at this late remove, but I'm pretty sure we weren't on RDP full time as late as Spring or maybe Summer of '76 (when I went to West Terminal). I can remember training in WT on lots of rushes with broadband (see * below) and shrimp boats.
As it turned out, RDP wasn't bad. There was no denying the auto data blocks were a huge improvement. I remember one coworker (about fifteen years older than me) saying it had extended his career by several years. But we gave up some functionality. First, RDP worked differently than our old friend radar that I'd been using up to this time. Previously, every scope displayed a single radar site. You could see the sweep going around. A practiced radar man could read weather pretty well (it wasn't a good idea to say “weather”—we always called it “precip”) and many is the time a light plane without onboard weather radar benefited from a vector around precip. But RDP was horrible in its weather depiction—so much so as to be nearly unusable for it.
On the other hand RDP displayed a mosaic of radar returns from two or more radars. There were some advantages to that—for one thing, we no longer needed the McCook radar on a vertical scope above the horizontal one displaying the IOW radar. The four principal radars I described earlier at each facility came in on microwave links—necessary because of the huge amount of data in the analog signal. That was called “broadband.” With RDP we were able to get radar data from supplemental radar sites that were digitized at the site and then sent in on TelCo (commercial telephone company—pre-divestiture AT&T in those days) lines. That was called “narrowband.” Eventually, the distinction became blurred and whenever we were using RDP we called it being on narrowband and if we were not on RDP and using shrimp boats with the old, conventional radar, we called it being on broadband *.
Ha, ha—an aside. Broadband was so named because the information from the radar site was real time, wide band television, essentially, and required wide band transmission capabilites to send it from the site to the facility. On the other hand, the new radar information was digitized (turned into ones and zeros) at the site, which basically has less bandwidth than voice, and thus could be transmitted on standard TelCo voice lines, hence, narrowband. That’s not to be confused with today’s broadband internet service, which is so named because the higher speeds of the ones and zeros take up more band width (laws of physics) and need better transmission lines than POTS (plain old telephone service—really, I’m not making that up—it’s a telephone industry term). That’s why you have to be within so many hundred feet of a CO (central office) of the phone company to get DSL. Cable, on the other hand, is already broadband because they’re sending video over it, consequently, RoadRunner or other cable internet is also broadband. I hope you were able to follow the irony of the reversal in meaning of the terms broadband/narrowband as it applied to ATC.
Another capability we lost with narrowband was somewhat minor, but it seemed important at the time. Our Air Traffic Procedures Handbook (7110.9 at the time—now 7110.65) provided that we ensured five miles of separation between the ends of the targets (regardless of narroband or broadband). However, with broadband, if within 40 miles of the radar antenna (called “the main bang” for some mysterious reason) we could use three miles. We no longer had the option with narrowband—it was five all the time. The reason was, we had no way of knowing which site the computer was using on a particular sweep as it mosaiced (ohmigod—I worked for the gummint too long—I’ve started verbifying nouns!) the various radars into the single, narroband display. In truth, though, the percentage of circumstances in which center controllers were able to take advantage of the three mile rule was extremely low—I’d guess around 2%, so while a factual loss, in the real world, it amounted to little.
For all that, just as I had experienced with FPB, having data blocks instead of shrimp boats, altitude readout, and automated handoffs were worthwhile gains for the system as a whole. As an old dinosaur, I missed the art of using broadband radar, but as traffic increased it became increasingly apparent that narrowband had arrived not a moment too soon. However, although it was a big help in the long run, implementation was not without incident. There were far too many hiccups as the system matured and bugs were shaken out. Imagine doing a complex task that's really important (I kind of think of ATC like that). Imagine whatever tools you're using to accomplish that task stop working—without warning and for no apparent reason. Multiply that by, say, 20 airplanes and 5,000 lives. It kind of gives grand experiment a whole different flavor. By the way, as trying as that was, the NextGen snake oil being sold today will be worse by an order of magnitude. At least we had some backup (broadband radar, strips, direct voice comm over phone lines). NextGen has no practical backup in any of its phases.
Nevertheless, we eventually got up to around 16 hours per day, every day with RDP and ran that way for years. For a long time we shut down on the mid and reverted to broadband, the software people using that time for testing, troubleshooting, and hardware maintenance. Moreover, they eventually developed a way of displaying the data from the individual radar sites directly onto the radar scope, which operated independently from the radar processing part of the computer. It was called DARC (direct access radar channel) and served quite well as a backup to RDP. It even got limited data block capability. Perfect on the mids. Not so good at 1700 during the arrival rush, but better than nothing.
Here's an amusing side story along the line of computer down time on the mids. Whenever we took the computer down (less frequently as years went by, and this story relates to the '90s) we lost the flight plan processing capability and reverted to hand writing strips and manual (interphone) coordination with adjacent facilities (most of the time we had DARC, though). At ZAU we didn't staff an A-side on the mids by that time, although other facilities did. Periodically I would get a call from ZMP with two or three flight plans. It was obvious from the unsteady voice on the other end that it was an A-side rather than an FPL.
After the exchange denoting I was about to get some flight plans, the A-side would start to pass the information—slowly. Excrutiatingly slowly. At the rate of a flight plan a day it seemed like. I refer you back to Chapters Two & Three in which I relate how we could copy flight plans and even mark up one strippers while copying the succeeding flight plans. Those guys were good! So, I tried to get the kid to move along—speed it up—I don't have all night (well, actually I did, but we were in the middle of a game…). After two or three nudges, the kid hadn't increased past the three flights per day stage, so I upped the ante. I told him, “give them to me as fast as you possibly can. Trust me, you can't give it faster than I can copy it.”
It was kind of unfair. He had no idea the guy he was talking to had trained on and worked manual flight data for nearly two years back in the day. I almost was able to say, “go ahead,” before he even finished the route of flight (the last element of the flight plan). In all fairness, experience, aside from the Flight Data days, came into play as well. For example, I knew what the destination was from two or three of the fixes or routes leading up to it. I knew the airspeed before he gave it from the type of equipment. In some cases, I even knew the type aircraft from the callsign.
There was another factor, too. Back in the day, we used to “short strip” routes of flight. There were only two strips in the facility that needed the entire route of flight—the first (from which succeeding strips were prepared) and the last (from which coordination with the receiving facility was given). All the controllers in intervening sectors needed was the route in and out of their sector. Short stripping was an art form lost to twenty years of automation, however, as the computer printed a lot more of the route on every strip than we ever did manually. There were a couple of other items, too, which were unnecessary in the coordination that a rookie like the kid trying to bury me couldn't possibly know. So, as I said, it was unfair. But in a way, it was kind of fun to chip the rust off retired skills acquired so many years before.
Last updated: 15 October 2009
Prev.
Main Page