ATCC Controllers' Read Binder...

NOTAMS, FAQs and other info for users of ATCC

June, 1998

#1: Speech Recognition Driver

The previously mentioned speech recognition driver add-on is complete, but its release is being delayed for technological reasons. There is a delay time from when a phrase is spoken to when the IBM speech software returns the recognized phrase, on the order of 1-2 seconds on a typical Pentium 166 or 200. That is not much of a problem when you are dictating a letter, but when you are running a busy sector it is tough to keep the mike keyed a couple of seconds after every transmission to make sure it heard you correctly. You either need a fast CPU (300MHZ) or the speech software needs to be refined a little (which IBM is in fact doing). For now it is easier and quicker to just type the commands, but it is an interesting add-on we hope to have "playable" in coming months.

The new sectors (more from L.A., Chicago and New York Centers) include the main Chicago southbound departure sector (kind of 66-meets-97), a 97-ish low-altitude sector north of Washington DC and Baltimore (main arrival point from the northeast), the main southeast sequencing sector for ORD (something like 82 merged with 19), and L.A. sector 27 (like Chicago 75 but with a bunch of head-on departures). All of those are very fun and challenging...we may also add a couple 82-ish sectors (busy but straight-forward), and possibly update Chicago 75 (more east-west overflights) and L.A. sector 4.

Things should be ready in late summer or early fall. Probably the new sectors, speech driver and some new pilot speech files will be bundled together on CD-ROM along with printed sector maps, or possibly as a 30MB download.

#2: New Program Version?

In the preliminary design phase is a new version of ATCC probably for release in 1999. The core of the current program is as realistic as possible and does not really require updates, but some new features will certainly be added, including:

  • VFR aircraft ("flight following") and traffic advisories.

  • Visual separation (relatively new to the Center environment).

  • "Emergencies" (more like "we need to level off for a few minutes") or returns to the airport.

  • More weather (changing storm conditions, icing).

  • Different console graphics (higher resolution, "strip bay" screen toggled by holding down a key).

  • Modified, "easier" training process (demo or tutorial).

  • Sectors already full of traffic at the start.

  • Closed airports, refused handoffs and holding.

  • Approach commands (ILS, visual, VOR approaches) and working traffic into airports with towers.

  • Text-only mode will likely be removed (does anybody use it?)

Another feature that is possible but not too likely in the immediate future is a multi-player option. We would have to create a hypothetical area of 5 or so interesting, adjacent sectors, since most adjacent sectors in reality are pretty boring (and nobody would want to work the boring sectors). It can be done, but the above items are currently higher priority.

There will also likely be cosmetic screen changes (title screen and sector selection screen graphics), and a pause command in training mode only.

All of these features are on the design list, but there is no firm release date or time schedule, other than within about a year.

#3 Philosophical Issues

Some software publishers have been interested in ATCC as a more mass-market item, and along with some non-hardcore ATCC users have suggested improvements such as:

  • Pictures of little aircraft instead of backslashes, and no +'s, dots, I's or V's.

  • Color: Departures one color, arrivals another, changing colors, conflicts in blinking red, etc.

  • No blocky, cryptically labeled console buttons--a fancy interface with pull-down help menus and pop-up bubbles.

  • No weird computer datablock entries, no handoffs and complicated frequencies. Simplified datablocks.

  • Mach speeds, indicated speeds, tailwinds, much too complicated. Aircraft assigned 450 knots should show 450 knots!

  • No keying up microphones...all commands should be issued via easy-to-use pop-up menus (mouse click).

These are all good suggestions, in a way. It would make ATCC more accessible to a larger audience, and would make it more interesting (and easier to learn) to casual aviation hobbyists who aren't as interested in the details of Air Traffic Control.

However, we just currently don't have the resources to make an "ATCC-lite" game version. Wesson's TRACON game is such a program, and is still available (try Flight Sim Central). Some people prefer an out-of-the-box game and others a detailed, realistic sim... just different audiences for different programs.

We may put in the help screens and pop-up "what is this" bubbles suggestion (in training mode), but you won't see color or simplified datablocks until such a thing appears in the U.S. system (which is what ATCC simulates), and you won't issue commands by mouse pull-down menus until real controllers can do it too (via the "data link" concept, direct from controller to aircraft autopilot--who needs pilots anyway?)

It is a deliberate, philosophical decision to try to fully simulate reality instead of making a simplified, more "playable" game. The reasoning is that the reality is in fact a lot of fun, once you learn how to do it. And, the knowledge gained from "playing" ATCC easily crosses over into reality, whether for a controller trainee looking for extra training time, or for a pilot (or aviation hobbyist) interested in what really goes on in front of the radar scopes.

#4: Real-life ATC training

Though the process is still undergoing revision, the U.S. procedure for training new controllers is still highly inefficient. Trainees are mostly left to teach themselves, and some never do and are shuffled from place to place. Most U.S. controllers go through a process similar to this:

(1) Attend a one-month classroom session to learn about airways, VORs, phraseology, and the evils of weather.

(2) Spend a month memorizing and drawing (from memory) all the airways, VOR's, intersections, mileages and radials between every point for the entire Center (forgotten a week later, of course).

(3) Spend another month in the classroom learning the more obscure ATC rules and procedures (like "With celestial navigation, how far can an aircraft deviate from its centerline?" answer: 20 miles).

(4) Spend a year training on and just doing D-sides, learning the computer commands and becoming familiar with each of the six sector's procedures and traffic flows.

(5) Run 20-30 radar scenarios on the FAA's primitive DYSIM radar simulator (with aircraft that climb at 9,000 feet per minute, 747's that cruise at 180 knots and instant 90 degree turns).

(6) Plug in and start controlling, with another controller ("OJT instructor") plugged in with you and ready to step in if needed. The instructor also keeps a list of mistakes the trainee makes, then at the end of the day writes them all on a check-list form that goes in the trainee's file. For the "Separation is ensured" check-list item, for example, the instructor might write "Issued climb to FL290 to UAL255 with AAL512 crossing at FL280", and under "Uses proper phraseology" there might be "told DAL128 to descend to 'nine' thousand instead of 'niner' thousand").

Somewhere in the 2-3 year process of these six steps you are supposed to learn what you need to make it through your certification checks without a deal. For motivated students, there are plenty of opportunities to observe other controllers and pick up on their techniques. For those needing or preferring formal instruction, or "what if" sessions, or an analysis of what is going on, there is nothing. The honest truth is the controller "instructors" have no education or particular interest in how to teach, so most sessions are just a matter of telling you what you are doing wrong, or if you are doing everything correctly they say nothing. You are left to just shrug your shoulders and assume you must be doing it right, then.

There are some good instructors who explain theory or more big-picture concepts, but most just sit and watch. Probably your greatest education comes after you are first certified, when there is nobody to step in and fix things for you (and certainly no "pause" button). You have no choice but to put some quick thought into what is going on, then analyze it later in your head when you wonder if you could have done it better.

It is a similar process in ATCC, though you don't have instructors writing down all your mistakes. In either case, you just keep "training" until you have built up a bag of tricks big enough to carry you through a certification session without a deal. Even though you may not feel ready, they will put you to work right away, and it doesn't let up from there!

#5: Visual Separation

Visual separation has been around in the terminal (approach and tower) environment, but has only in recent times been approved for use in Centers, and only below FL180. The idea is that you can waive the 5-mile/1000 foot separation requirement if one aircraft has the other in sight, and you tell them to maintain visual separation. You can't do it before you are about to have a deal, though; they must first be separated as normal, then you tell them to maintain visual separation, then you may descend/climb/turn them "into" the traffic (within 5 miles/1000 feet). The snitch still goes off, the supervisor still comes running down the aisle, but you just say "visual separation" and he goes away.

It can be a useful tool, in many cases, when you have an aircraft stuck above or below another that obviously isn't a factor, but is within the 5 miles. You just tell them to maintain visual separation, they see the other aircraft isn't a factor and continue on their way. You do need to use good judgement, though. If you think they may cross paths ("merging targets") it's probably better just wait the extra 30 seconds for your five miles instead of shifting the burden (and possible miscommunication) to the pilots.

We will certainly put in visual separation in any program revision, since it is now in place in the Centers and somewhat (but not always) used. Some people just don't like setting off the snitch, even if it's not a real deal!

#6: Cheating the Snitch

The little (real-life) program that monitors all radar targets and lets you (and the supervisor) know when you have failed, is not all-knowing. There are in fact a number of "situations" that it misses, and to the great relief of controllers does not activate. Especially when the system is overloaded (i.e. much of the time), and the "deal" is only for 1 or 2 radar hits. It just doesn't blink, and the wide-eyed controller quickly looks around to see if the supervisor is watching (highly unlikely). If not, gee, he must have seen it deal! Actually, even if the supervisor is watching, most likely he will turn away, since they don't want deals on their shift, either. If it doesn't blink, it's not a deal, case closed, tapes erased and printouts shredded.

Controllers also learn the "Report Key" scam, though it's not part of official classroom instruction. One of the function keys (not implemented in ATCC) is "Report Altitude," intended for use if an aircraft's transponder isn't sending out the normal altitude readout. You just ask the pilot for his current altitude, and use the Report function key to manually put it in the datablock. The scam is that if you use "Report" it will override the regular altitude readout, even if it is working properly, for 1 or 2 radar updates (enough to avoid a quick deal). So, just before you have the deal, you "Report" the aircraft at altitude 999 (or "report" him at his ID#, and claim you "accidently" typed the ID# twice), so the computer thinks it is at 99,900 feet, and the snitch never goes off. The only catch is that you would be fired if the incident were investigated (like the pilot reports a near-miss) and they need a scapegoat. Some controllers do take the risk, though, to prevent a deal from going in their file. Foolish, but sometimes done.

A similar "out" exists in ATCC: if the datablock is not displayed, the snitch will not go off. If you have handoffs on both aircraft, unfortunately, you can't remove either of the datablocks. But, if you have already handed off one of the aircraft (even if you are still talking to him), click on the datablock to remove it from your scope before you have the deal, and it won't blink. One use is in sector 97, for example, when you have handed off an ABE arrival at 9,000, then get a head-on ABE departure climbing to 8,000--then Allentown approach starts descending the guy at 9,000! Just click off the datablock, and you won't be charged with any deal (in real-life it would be Allentown's responsibility to separate them, anyway).

And with this newsletter item you are advised that the ATCC supervisors (as well as the FAA?) consider it "for the good of the Agency" that you have as few "official" deals as possible. Read into that what you want.

#7: Changing your radios

An undocumented command (left over from a debug version) is the ability to listen in to a computer-controlled sector by changing the "frequency" of your radio receiver. First make sure you are unplugged from the sector (or unplug if you are already plugged in). Then type <F6>F and a 5-digit frequency without a space or the period, e.g. <F6>F13575 and <ENTER> to monitor sector 97 without actually plugging in. The normal radio buttons appear, but there is no transmitter window and you can't transmit. But you do hear the computer controller and computer pilots talking back and forth.

ATCC still thinks the "plug in" graphic is there, so if you click on it you will be plugged into the regular sector as usual. Just don't click on the radio controls, to prevent confusion. To un-monitor the radios and return to normal, press ALT-P twice to toggle on and back off.

You can also monitor tower frequencies (try 11910 for JFK, 12690 for ORD and 12095 for LAX), and you will hear ground- and local-control kinds of instructions (taxi to the ramp, etc). Though ATCC says "125" and "225" instead of "25 left" and "25 right" for runway numbers. Also, instead of "contact New York Center" you will hear things like "contact alpha" which is internal code for the different sectors.

The only problem is that the computer is expecting instantaneous communication with computer aircraft, so having to wait for the speech to play gets it backed up. After about 10 minutes the computer controller will stop responding altogether ("gives up in frustration"). Or, it can't understand why an aircraft isn't instantly responding and keeps repeating the same instruction, over and over. If this starts to happen, just stop monitoring.

This radio function isn't really practical, just a curiosity...

#8: More on Strips

It has been mentioned in this newsletter before that you really shouldn't need strips except when you first see a handoff, to note where the aircraft is going and maybe what type it is. Even if you forget, many times just the route or altitude the aircraft is already at will tell you (how many airliners in sector 66 coming from the south don't land at JFK?), but at worst all you should need to do is quickly bring up the strip to refresh your memory.

However, some controllers (and everybody has their own opinions, all correct really) use strips to pre-plan and even identify possible conflicts based on time estimates (real strips print a computer-generated time estimate for either a VOR it crosses, or when it should enter the sector). In sector 75, for example, strips might be delivered 20 minutes before the aircraft appear, and a D-side or even R-side (if not doing anything else) might note that two are estimating DBQ within a couple minutes of each other, both at FL330. This is really a hold-over from non-radar days, when such scanning was the norm. The procedure is to write a red 'w' (for "warning") next to the altitude, to note that it may be in conflict with another. Then when the aircraft appears, and the strip is brought down, the red W will remind the controller to look for the other aircraft as a possible conflict.

If controllers have the time (and manpower--there aren't always D-sides available), such a technique can't hurt, but most likely it is a waste of time. If you are scanning the radar and are keeping the "flick," no little red W on the strip is going to tell you something you didn't already know. Furthermore, the time estimates on the strip are based on a daily forecast of upper wind velocities, which may or may not be correct. So, it is not a very accurate method, but some Centers and controllers do teach and use the technique as a "just to be safe" kind of backup.

With the theoretical "next version" of ATCC and the planned strip bay display, you should be able to use this technique if you wish, or not if you don't want to. It is a "waste of time" in some controllers' opinions, and a "sometimes lifesaver" in others'!

#9: Storm Season

June through August is the peak storm season for most of the ATCC sectors (Chicago and New York at least), so be prepared! Pilots will not fly through storms, and will turn on their own if you try to ignore them. Responding to deviation requests should be one of your top priorities. You can estimate the urgency based on the size of the requested turn: 10 or 15 degrees means you still have a couple minutes (not so urgent), while 40 degrees is significant and you can expect them to turn on their own at any moment, whether you are ready for it or not.

In some cases of multiple storm cells, they may initially request only a slight turn, which you approve, only to come back a little later with a 90 degree (or even 180 degree!) turn. What happens is they get around the first cell, only to suddenly discover a larger storm cell behind it, with not enough time to warn you of the need for more turns. "Path-finding" is easy for human pilots, but one of the more difficult (and sometimes unsolvable) issues for computer AI, so prepare for possibly crazy maneuvers.

Real controllers in fact do (and should) expect almost anything when it is apparent there are storm cells in the sector. Don't put aircraft at the same altitude if they are anywhere close to each other (within 20 miles or so), just in case one needs to turn back. Also keep extremely vigilant with the scan, to be able to note within one or two radar hits that an aircraft is off course.

In both ATCC and reality, if one aircraft deviates it is likely the following aircraft at the same (or similar) altitudes will want to deviate the same way. It does depend on altitude, climb rate, and assigned altitude, sometimes. If the "tops" are at FL330, an aircraft level at 330 may request to deviate, while the one behind it at 297 climbing to FL370 may just stay on course because they project they'll be above the tops by then. Also, different pilots will have different opinions and experiences on how close they can get to the storms, so some may deviate just a little, and others more.

In real life, you can ask them how far they'll need to go before they can turn back on course, or you can tell them to deviate "no further than 30 degrees left." It would be unwise to base any kind of separation on that, however, so really it is meaningless. They may later change their mind, or see something they didn't see before, and you still have to accommodate anything they request. You may be let off of a deal if they turn 40 left when you told them no more than 20, but it is poor controlling. You should have seen it coming!

So, use altitude separation when possible, and be extra attentive with your scan. If the ORD-JFK aircraft wants FL330, but you already have several aircraft at FL330 with storms present, tell him he only gets FL290 as a final. If he says "Where's our traffic" or otherwise complains, tell him he's lucky flow control didn't hold him on the ground until the storms started to dissipate. Actually, pilots usually don't mind the extra restrictions. Weather deviations probably add a little variety to their normal routines, as it does for controllers (sometimes)!


The Read Binder is updated at the beginning of the month. All information is for use with Xavius Software's Air Traffic Control CenterTM only, is the opinion of the author(s), and may not reflect the official policies and practices of the U.S. Federal Aviation Administration and Federal Aviation Service. Or, it may. Send your questions and comments to!