Understanding Handoffs and Coordination

[Andrew Doubleday]

This should be required reading/training for all radar controllers in VATUSA, and probably other parts of VATSIM would find this extremely useful as well.

 

More often than not these days, I find myself working with controllers that have no knowledge or concept of what, exactly, a handoff really is or how to understand and accomplish coordination appropriately along with the specific phraseology. Learning this material will not only make coordination easier between each facility in VATUSA, but also help to train pilots how to properly "check-in" with a controller from radar handoffs and during non-radar situations. Again, referencing one of my largest concerns within the division (and possibly entire network) is the overall lack of standardization and consistency of controller training between each facility. Ensuring everyone is on the same page with things such as handoffs and controller coordination (and this really isn't rocket science, by any means - Jeff does an excellent job of breaking this down fairly simply in this article) will help to improve controller consistency/efficiency with handoffs and coordination not only within a facility, but also across facilities. this, in turn, should rub off on pilots making the check-in process a lot more efficient and consistent (during handoffs and non-radar situations for sure).

 

Anyways, thanks to Jeff Clark for writing this (wherever you may be). It's a great article. Maybe VATUSA can add this into their controller training docomeentation...

 

(Original Article found here: http://www.laartcc.org/old/training/understandinghandoffs.htm )

 

Training - Understanding Handoffs and Coordination (Part 1)

by Jeff Clark

 

Perhaps one of the most misunderstood concepts on the VATSIM system is the purpose and proper use of the handoff. During low traffic situations these misunderstandings usually result in little problem, but as traffic increases, a better knowledge of how these works is becoming more important. Also, with the upcoming release of new controller software, a clearer understanding of the rules surrounding handoffs will soon become essential. This docomeent explains not only the purpose of the handoff, but also 'best-practice' on how to use them, as well as procedures and practices to use both before and after a handoff has been accomplished.

 

It should be noted that the information contained here is written primarily from a U.S. FAA point of view - however the fundamental principles at play here are fairly universal, and other countries will have similar rules to those described here to address these issues.

 

The fundamental essence of the handoff:

 

The first thing you need to understand when considering the handoff is to understand exactly what you are doing. You have probably already determined that one part of a handoff involves telling an aircraft to contact the next controller along his route of flight. You may, however, be surprised to find out that this is in fact only a tiny part of a long string of events that should occur every time you perform a handoff.

 

There are two key goals you are accomplishing via a handoff that you need to always remember: You are transferring "identity" of an aircraft to another controller, and you are transferring "communications and control" of an aircraft. Both areas will be discussed in further detail later in this docomeent - but first we shall look at the history of the handoff.

 

Early air traffic controllers had it easy. Aircraft always flew along fixed routes, and altitude separation by direction of flight made it very easy to keep aircraft separate using non-radar procedures. At the first control center in New Jersey, controllers simply pushed little model airplanes along giant maps of the East Coast to keep track of where they were. When they got near the edge of their area, they'd tell the plane to call the next controller, who they'd given a 'heads-up' to via the telephone.

 

Things are a bit more complicated now. In the early days of radar, controllers worked in teams, gathered around a single radar display which was usually laid flat like a coffee table. The earliest transponders didn't have the ability to show many different codes, and the computers modern controllers use to show an aircraft's callsign and altitude didn't exist. Instead, this information was usually scribbled on a piece of gl[Mod - Happy Thoughts] that was placed over the blip, which came to be known as a 'shrimp boat'. As the blip moved around the scope, the piece of gl[Mod - Happy Thoughts] was moved along with it.

 

These early controllers divided their one big scope into smaller sectors, and because they were right next to each other, it was easy to co-ordinate with each other, asking for permission to clip each other's airspace. They could also p[Mod - Happy Thoughts] the 'shrimp boat' along with the blip from one controller to the next, as long as the next controller shared the same large screen - which brings us to the first thing you need to understand - "transfer of identification". But before we discuss this, we need to discuss the p[Mod - Happy Thoughts]ing of flight plans…

 

Step One: P[Mod - Happy Thoughts]ing the Flight Plan

 

You're probably already familiar with the fact that a pilot files a flight plan with a Flight Service Station prior to picking up his IFR clearance. What you may not know is that these flight plans are then entered into a computer system and p[Mod - Happy Thoughts]ed to a Center controller whose sky is -over- the departure airport. This controller is responsible for reviewing the flight plan route, and if the route is unacceptable, he will amend it in the computer before sending the computer sends the route on to the Tower Controller to be read to the pilot.

 

The Center's computer will then send a copy of the flight plan to the controller who will be handling the departure so he can also study it and be ready for it. Except for one or two controllers, everyone else along the route won't yet be aware of the flight. It is not until the flight actually departs that a 'departure message' is sent to the Center Computer, which then starts calculating 'estimated' times at which the flight will enter various sectors along it's route. The Center's computer then ensures that controllers receive a flight strip with route information for each controller along the way, approximately 15 minutes before the flight arrives.

 

Sometimes however, this information isn't p[Mod - Happy Thoughts]ed automatically. This can happen when a flight is a 'pop-up', or if the computers aren't working, which is common at night when they are being maintained. In these circomestances the controllers or their [Mod - Happy Thoughts]istants are responsible for p[Mod - Happy Thoughts]ing the pilot's flight plan information from one sector to the next well before the plane arrives. This ensures that each controller can study the route and make sure that it will be OK for him, allowing time to ask the controller sending him the aircraft to amend the route or altitude if necessary before the pilot enters his sky.

 

It is important to note here that when we say we are p[Mod - Happy Thoughts]ing the aircraft's "flight plan", what we are actually referring to is his current cleared route. Controllers do not need to know that the pilot had originally requested a DP which he was not [Mod - Happy Thoughts]igned. Similarly, the portion of the pilot's route that he has already flown is also not p[Mod - Happy Thoughts]ed. Only the route to be flown is sent, to ensure that if the pilot loses radio communications, the controllers along the route will know what the pilot was last [Mod - Happy Thoughts]igned and consequently must fly until communications are re-established.

 

It is standard practice amongst controllers that the receiving controller is advised of any route/altitude changes before a handoff is initiated so that the receiving controller is aware of this information before deciding whether or not he can accept the aircraft.

 

In addition to telling the receiving controller what route has been [Mod - Happy Thoughts]igned, another reason for p[Mod - Happy Thoughts]ing flight plan information is to give the receiving controller time to review the route that the aircraft will be flying inside his own sky. Many times particular routings will be unavailable, or not particularly good because of traffic or weather. This is why it is very important to p[Mod - Happy Thoughts] an aircraft's flight plan, and to initiate a handoff early enough so that any required re-route can be done by the initiating controller in time. For example, an aircraft may be currently routed to enter the next Center's airspace along J146 - however this airway may be unavailable. The initiating controller needs to find this out -before- the aircraft is 5 miles from the airspace boundary on J146 - in many cases the re-routes need to be issued hundreds of miles before the edge of your airspace boundary.

 

Once the aircraft's flight plan information, including currently [Mod - Happy Thoughts]igned routing has been p[Mod - Happy Thoughts]ed, the next stage of the handoff involves making sure that the receiving controller correctly understands which target belongs to the aircraft to be handed off - this is called Transfer of Identification.

 

Step Two: Transfer of Identification

 

When an aircraft first enters a radar environment (normally immediately after departure when contacting the departure controller), that controller uses one of several possible methods available to him to positively identify the blip that he -thinks- is in fact a particular aircraft. The reasons for doing this are very important indeed. It is not unheard of for a pilot to dial in a transponder code that was intended for someone else. For example, if there were radio problems with the Clearance Delivery frequency, it's possible for a pilot to think that -he- is being [Mod - Happy Thoughts]igned a transponder code which was actually being read to someone else. He'll depart on his normal flight plan, but the departure controller won't realise where he is because the blip will bear the name of another flight. If two aircraft make the same mistake, the wrong blip will make a turn intended for another aircraft potentially causing a mid-air.

 

For this reason, controllers MUST use what is called POSITIVE identification to ensure that the blip he -thinks- belongs to the aircraft is really him. Once this positive identification has been established other controllers at the same TRACON are permitted to [Mod - Happy Thoughts]ume that the computer has kept the right tag with the right plane, and they do not need to radar identify the aircraft simply because he has p[Mod - Happy Thoughts]ed from one sector to the next.

 

Step Three: Transferring Control:

 

The second goal of the handoff, after the transfer of radar identification, is the transfer of control. Because ATC is a very precise endeavor, there are very specific rules and guidelines for determining at what point an aircraft becomes the responsibility of one controller, and then becomes the responsibility of the next.

 

By using automated, or manual handoff procedures, the next step of the handoff process involves communicating your intention to handoff the aircraft to another controller. This is done either via using a computer command to initiate a handoff, or by calling the receiving controller on the landline and performing a handoff manually as described later in this section.

 

Once this action is started, the receiving controller will review his current traffic situation, and make a decision as to whether or not he will be able to allow the aircraft to enter his airspace. If he is able to do so, he will either enter a computer command to indicate his acceptance, or say 'radar contact' during a manual handoff. On certain occasions, he may implement conditions on the handoff, described later in this section. At this point, permission has been granted for the aircraft to cross the airspace boundary along the [Mod - Happy Thoughts]igned flight plan route, at the [Mod - Happy Thoughts]igned altitude. It is important to note that this process is best seen as 'asking for permission' to handoff the aircraft, and the aircraft is not yet actually handed off yet at this point.

 

When to initiate a handoff?

 

When a controller is handling an aircraft that is going to leave his airspace, he should almost immediately begin thinking about handing him off to the next sector. For reasons discussed elsewhere in this docomeent, this process is not something that can be put off until the last minute or serious problems may develop. There are two important conditions that need to be met before a handoff can be initiated - the first is that the aircraft has been positively radar identified, and the second is that the aircraft no longer has any obvious traffic conflicts. The period when an aircraft is 'between controllers' is one where you don't want any surprises, and a good controller will not accept a handoff if he does not understand exactly how any potential conflicts will be resolved.

 

For example if you were planning on handing off an aircraft that had visual separation with another aircraft immediately above him, you should advise the receiving controller that there was visual separation between the aircraft at the time you handoff the aircraft. This is because a receiving controller will rarely accept a handoff of an aircraft that appears to be in conflict alert. If there were to be an accident, the controller who currently had control of the aircraft will more usually be the one considered to be at fault, and you cannot expect to 'handoff' problems to another controller in hopes that they will fix something you weren't able to.

 

Similarly if you have just instructed an aircraft to speed up, slow down, expedite climbs, etc., to resolve a potential conflict, you may need to tell the next controller this information before they will be comfortable accepting a handoff.

 

Once all of these conflicts with your own aircraft have been resolved, or explained, you should at that point initiate handoff - even if the aircraft is many miles from the airspace boundary. (On VATSIM, there is sometimes a complication that occurs when the receiving controller's range is not set far enough out to see the aircraft. In these cases he will not know that you attempted to handoff the plane - in real life systems however, the aircraft remains in handoff status regardless of how far out they are, and when they appear on the receiving controllers scope edge, they will be in a flashing 'handoff' status.) Many controllers use the saying "take a handoff, make a handoff" to illustrate the common practice of initiating a handoff to the next sector almost immediately after you -accept- a handoff from the first sector. This practice has the advantage of helping to make sure you do not -forget- to handoff an aircraft, which is viewed as a serious infraction in a radar environment.

 

When an aircraft goes from one radar facility to the next, the computers -usually- are able to p[Mod - Happy Thoughts] information to each other about where a blip is, who he is, and where he is going, but not always. In these cases, or indeed when the computers aren't working properly, a "manual handoff" is initiated. In a manual handoff, a controller essentially calls a neighboring controller on the phone and says "Do you see this guy near Terre Haute on the 4203 code? He's AAL330…" The proper phraseology for this process follows the following format. First, the controller initiating the handoff calls the adjacent controller on the landline and identifies himself and why he is calling: "Albuquerque Center, Los Angeles Center handoff". The receiving controller then indicates he is ready by saying "Albuquerque Center, go ahead".

 

The initiating controller then starts the handoff by telling the receiving controller where on the scope to start looking. He does this by referring to an intersection/navaid that he knows is depicted on both of their scopes, and a position reference that fix - for example: "Thermal, 10 miles southeast", or "over Needles". While the receiving controller starts searching that area for targets, the initiating controller continues the process by reading the squawk code of the target (remember that the receiving controller won't always see a data tag containing the aircraft's id on it, especially if the computers have failed to correlate the aircraft's position between themselves). This allows the receiving controller to examine the codes of all aircraft in the vicinity of the location identified by the initiating controller until he finds the correct target. The initiating controller continues by p[Mod - Happy Thoughts]ing the aircraft id, and any other flight plan information if it hasn't yet been p[Mod - Happy Thoughts]ed. Otherwise, after p[Mod - Happy Thoughts]ing the aircraft ID, the receiving controller will then do one of several things.

 

If the receiving controller locates the aircraft, and can accept the aircraft, he will say "(aircraft ID) Radar Contact".

 

If for traffic reasons, he needs to place a condition on the handoff, he will do so at this time via one of several methods discussed later in this docomeent.

 

If the receiving controller cannot accept the aircraft for the time being, he will say "unable handoff", and if able, advise how long a delay the initiating controller can expect. At this point, the initiating controller must turn or hold the aircraft ensuring that he does not enter the airspace of the receiving controller.

 

Negotiating conditions for handoffs

 

There are many times when a receiving controller cannot accept an aircraft into his airspace without modifying some aspect of it's flight. There may be many aircraft in his sector, including many aircraft that the initiating controller may not necessarily be able to see on his radar scope, either due to different radar antenna locations, aircraft operating without transponders or faulty transponders

 

The receiving controller will place a 'condition' on a handoff by informing the initiating controller of the condition on the landline as follows:

 

He can ask for the aircraft to be given a speed restriction by saying, for example, "AAL370, speed 250 knots, radar contact".

 

He can ask for a route change: "AAL370 direct DAG, radar contact"

 

He can ask for the aircraft to be [Mod - Happy Thoughts]igned a heading, for example, for traffic, by saying "AAL370, heading 350, radar contact"

 

He can ask for an altitude change: "AAL370, descending to FL180 radar contact"

 

He can also ask for any combination of these. When he includes these instructions in his acceptance of the handoff, he is making this a -condition- of the handoff, and the initiating controller MUST instruct the aircraft to perform the required modification to it's route BEFORE sending the aircraft to the next controller.

 

If the initiating controller is unable to comply with the request because of traffic in his own airspace, the two controllers must negotiate an alternate plan of action before the aircraft can enter the next controller's airspace. It is important to note that should a situation develop where there is quite simply no where for the plane to safely go, it will be the initiating controller who will be legally responsible for having got into this situation, and therefore he should always have a 'way out' should the handoff not be accepted.

 

After the handoff, before the ship…

 

After you have obtained permission for the aircraft to enter the next controller's airspace, the next step is to transfer communications of the aircraft to the next controller. It is important to realize that in real-life, this process does not occur immediately after the handoff is accepted, and many VATSIM controllers believe it is best to de-couple the option which automatically tells the plane to contact the next controller.

 

There are many reasons why you may wish to hold on to an aircraft before 'shipping' him to the next controller. For example, you may still be monitoring a potential separation conflict with another aircraft to make sure it works out. You may also be monitoring spacing between aircraft or some other factor that needs to be taken care of before you finally are done with the aircraft. As discussed in the previous section, just because you still have work to do with the plane is no reason to not -initiate- the handoff. In those cases, you simply get permission to enter the next sector, and continue to work with the aircraft on your own frequency until you no longer need to talk with him.

 

After you have resolved any potential issues with your aircraft, and after the handoff has been accepted however, you can - and in many cases should - switch the aircraft to the next controller's frequency as soon as possible. There are many reasons for doing this earlier rather than later. Firstly, you should not worry about the aircraft not being on your frequency but in your sky - there are many rules which are set up to prevent problems with this, which will be discussed in the next section. Secondly, if the aircraft has not changed to the next controller's frequency before entering his airspace, technically you have committed an error which could lead to disciplinary action in a real-world facility. (Remember that it takes time to change radios, so always leave time for this). Finally, the sooner the next controller talks to the aircraft, the sooner he can start working with him, which is always advantageous.

 

After transfer of communications, but before he leaves your sky…

 

Until the aircraft has left your airspace there are certain rules that the receiving controller must observer to ensure that your separation is maintained.

 

Specifically - the receiving controller may not alter the aircraft's altitude, route, speed or transponder code while he is still in your airspace, (or even within 2.5 miles of the edge of it inside his own sky if at the Center).

 

Having this rule allows you to "count on" your aircraft leaving your sky on a certain route, altitude, etc., which will be useful if you have other aircraft near the boundary that he needs to miss. Because you can count on the next controller not to change any of these things, it frees you up to hand him off and leave him off your frequency as he approaches the boundary.

 

Negotiating changes after the handoff

 

There are certain times when the receiving controller may wish to move the aircraft after the aircraft has been handed off, but before he has left your airspace. In these cases he must ask your permission to make one of these changes through the use of an APREQ (Approval Request).

 

As an example, he may call you to ask:

 

"APREQ heading 350 AAL320" - which means that he is asking your permission to turn a plane stillin your airspace to a 320 heading.

 

"APREQ FL180 AAL320" - which is asking to change the aircraft's altitude

 

The controller may also APREQ more general permissions, such as a blanket permission to make many different turns, or a variety of descents.

 

To do this, a controller may ask for "control for turns", or "control for descent". If control for turns is granted, the receiving controller may make a series of turns provided none of those turns takes the aircraft -back into- the first controllers sector. "Control for descent" (or "climb") allows a variety of altitudes to be [Mod - Happy Thoughts]igned provided that the direction is not changed (in other words, if you are descending him, you can't then climb him).

 

A controller may ask for both turns and descent/climb by asking for "control on contact", which then grants permission to do both.

 

Finally, any of these can be granted by the initiating controller without actually being asked. Some controllers even coordinate a special arrangement where all aircraft that are handed off are [Mod - Happy Thoughts]umed to be 'control on contact' which means that the initiating controller will allow the receiving controller to alter all aircrafts course and altitude after transfer of communications. This however is more an exception than the rule.

 

Point Outs

 

There are occasions when you will hand an aircraft off to a controller who will only work the aircraft for a short period of time because the route of flight will only take him across a very tiny portion of his airspace. In these situations the receiving controller may tell you "Point Out Approved" when you thought you would hear "radar contact". In this situation the controller is telling you that he sees the aircraft, understands his route but doesn't want or need to speak with him. You should then normally hand the aircraft off to the next controller along the plane's route.

 

Other occasions when you may need to point out an aircraft involve times when an aircraft has strayed off his route, or you may not be certain if a plane is going to clip someone's airspace or not.

 

A controller always has the right to decline a pointout. He may do this by saying "radar contact" when you were initiating a point out - meaning that he still wants to talk to the aircraft. If he doesn't take the pointout or a handoff, you must ensure the aircraft remains clear of his airspace or an error will have occurred.

 

A controller who accepts a pointout may also place a condition on the pointout, in the same way he puts conditions on handoffs. He may say:

 

"heading 330 pointout approved" meaning that as long as the aircraft is on a 330 heading, you can "borrow" his airspace

 

"Fl180 pointout approved" meaning that as long as you change the altitude to FL180, then it's OK.

 

Also, he may show you an aircraft in his airspace that you must miss as a condition of the pointout. The way this is done is as follows - he will first tell you where to look on your scope, the transponder code of the aircraft to miss (or his ID if you are on the same radar system), and what he is doing. If you see the aircraft you would then say "AAL331 traffic observed". He would then say "reference that traffic, pointout approved", which means that you may enter his airspace provided that YOU take the necessary action to ensure separation with AAL331. If a separation conflict subsequently develops between these two aircraft in the other controller's airspace, it is now -your- legal responsibility and not his so it is important to understand what the other aircraft is doing before making this type of arrangement.

 

Summary:

 

The steps that must be taken as part of a handoff are summarized as follows where the initiating controller is "controller A", and the receiving controller is "controller B".:

 

1.) You must make sure that the flight plan route in the computer system matches the pilots' [Mod - Happy Thoughts]igned route. If it doesn't, you must either change the route in the computer, or tell Controller B.

 

2.) After you have established radar contact, and resolved any separation problems, you then initiate handoff, either via an automated system or via landline.

 

3.) If the aircraft doesn't have a tag, you must describe the location, code and route of the aircraft to controller B at the time of initiating handoff.

 

4.) Controller B may either decline the handoff, accept it, or accept it with conditions which must be issued by Controller A prior to transferring communications.

 

5.) After the handoff has been completed, Controller A keeps the aircraft on his frequency until all potential conflicts in his airspace have been resolved, but transfers communications to Controller B in plenty of time to ensure that the transfer is complete prior to the aircraft entering Controller B's airspace.

 

6.) After communications have been transferred, Controller B may not alter the route, altitude or code of the aircraft without first APREQ'ing it with Controller A.

 

7.) Control for turns, climb, descent or control on contact can be used to get around point 6.

 

8.) A controller may choose to accept a 'point out' if he doesn’t' want to talk to the aircraft, with or without conditions.

 

9.) An aircraft that has not been handed off or pointed out may NOT enter Controller B's airspace under any circomestances.

SEE PART 2 of Understanding Handoffs and Coordination

[Anthony Pavlak 1058071]

I especially like the part about starting hand offs early, as is appears to be a strong point of contention among some VATSIM controllers.

[Keith Smith]

That's one of those articles where every single sentence is of value....and it had a LOT of sentences.

 

Good post, AJ.

[Aaron Flodin 878523]

2 thumbs up...Nice article....

[Andrew Doubleday]

Recently I've been noticing how many pilots just have no idea how to check in from a non-radar situation (or, in many cases, even a radar handoff situation). For instance, you ping a mode C intruder with a contactme (as they haven't checked in with you yet as they are either unfamiliar with your airspace or don't know any better) and they call up on frequency without a position report or anything beneficial to help you quickly radar identify said aircraft. Now sure, some might make the argument of, "well, this is just VATSIM and I obviously know if I sent said target a contactme that that is obviously him," but for the sake of teaching this correctly (and again, this isn't rocket science) you should be obtaining either a correct position report from the aircraft or using another one of the 6 identification methods to positively radar identify said aircraft and hopefully teach the pilot that a position report (relative to a major VOR, airport along with a confirmation of altitude to verify mode C) is far more efficient and easier on everyone. Then you'll get those that check on with just the inevitable, "with you." It's like, thanks buddy, I knew as soon as you said your callsign that you would likely be "with me" but I own 240,000 square miles of airspace, where exactly are you "with me" within that general realm?

 

I heard a center controller radar identifying aircraft as they checked on with nothing more than a simple "with you" the other day - not even a mode C verification of altitude. This guy didn't have a care in the world for a valid position or altitude report (likely because he was never taught how to do this)... But does anyone see where this creates inconsistency on this network? Controllers observing said controller will be learning from this poor habit and pilots will be confused as to how exactly a controller is expecting them to check in. Pilots get a different experience from one facility to the next (and, in worse cases, from one controller to another within a facility) on how processes, such as the radar identification I speak of in this topic, are handled. Standardization in controller training on very basic topics such as this is critical towards fixing that lack of standardization across our division!

 

OK, hope that helps sum up why I'm posting this stuff... The people who really need to be paying attention to and reading this are training departments across VATUSA (since we're without a VATUSA3) and who knows how many controllers on VATUSA actually regularly read these forums. My hope is that this will spread to each facility after being up here (I'm also posting this into the training forum of the VATUSA.net forums, hoping it reaches the controller training docomeentation eventually).

 

 

 

Anyways, digging into some of the sublinks of the training website this gold mine of an article was discovered on, I've found part 2 which would probably also be considered extremely useful (It breaks down the understanding of handoffs with regards to other sectors of airspace, including shelves) for the 2D-to-3D challenged.

 

Some of this was clearly in reference to old ZLA procedures/policies (some of which are no longer valid), but I especially like the second graphic here and coinciding description describing handoffs in relationship to "shelves" of airspace or to sectors below the sector you are working (not just lateral limitations). The part about aircraft being on the receiving controllers frequency prior to crossing the sector boundary is a fairly critical point as well. There's nothing more frustrating than working a small sector of airspace and receiving handoffs right on your boundary and not receiving communications on said handoffs until the aircraft is well into your sector or beyond a point where you needed to be speaking with them. Obviously slow check-ins from VATSIM pilots can contribute towards this problem, but you need to be vigilant as a controller in counter-acting that by handing off early and often. Making sure that a handoff and communications switch is completed prior to the aircraft crossing into the receiving sectors airspace is important towards maintaining positive control of a sector.

 

Not long ago, I was working an approach control position with a controller working a center sector above me that was having trouble understanding the concept of seeing the 3-dimensional picture of what airspace he owned in relationship to the airspace that I owned. In turn, he was regularly descending aircraft into my sector without prior coordination (he should have been stopping them 1,000 above my airspace but was regularly issuing descents through my sector). This was obviously dangerous considering any departures I was working out could have easily become a conflict climbing to the ceiling of my airspace while he was descending aircraft to the same altitude my departures were climbing to. This graphic that Jeff Clark makes should help to indicate why, as a center controller, you would not clear aircraft into a receiving controllers airspace descending from above, but would rather [Mod - Happy Thoughts]ign an altitude just above that approach control sector (or low center sector, shelf of another sector, etc) and allow the receiving controller to then issue further descent into his piece of the sky.

 

My radar instructors at school tried to relate this concept to having a string tied to a piece of wood from within a bucket. If you pulled on the string (sitting inside the bucket) to move the piece of wood closer, it would rest on top of the bucket and then eventually drop into it from above (relating this as you being the approach controller working an aircraft into your sky from above). You wouldn't have control for descent until the aircraft is on top of your airspace and within the lateral limits. So you would be able to pull the aircraft down and into your sector.

 

Obviously facility LOAs can and, in many cases, do allow for control of aircraft outside of the spectrum these articles cover, but this is a general, non-LOA concept that can be applied just about everywhere.

 

Anyways, hope this article helps as well.

 

Training - Understanding Handoffs and Coordination (Part 2)

by Jeff Clark

Handoffs and Coordination with Center:

Just like in real life, if a pilot is following his flight plan route, you do NOT need to do anything to coordinate a handoff with Center other than flash the plane on Center’s scope, and make sure that communications are switched prior to the plane entering Center’s airspace.

 

On the flip side, if the plane has been [Mod - Happy Thoughts]igned a route in Center’s airspace which is NOT shown on the flight plan, you MUST tell Center about the new route prior to handoff, to give Center the opportunity to modify the

route if necessary. This works both ways – Center MUST tell you about any arrivals which are on a routing NOT shown on the flight plan before handing the plane off to you.

 

Additionally, you are not allowed to clear a plane through your airspace ceiling, so any plane that is going to go higher than 13,000 cannot be issued anything higher by SOCAL than 13,000. Center will continue the climb when he takes the handoff and has communications with the aircraft. Similarly, Center will tell all arrivals which would enter your airspace through the ceiling to stop their descent at 14,000, and it will be up to you to continue the descent when it is safe. These procedures ensure that if a controller becomes too busy, aircraft will not continue to enter the busy sector when the controller is too busy to handle them. A sample graphic is below. See current ZLA Policies for updated sector vertical and horizontal climbs and descents.

 

 

Aircraft which will enter your airspace laterally (coming in from outside your boundaries at an altitude lower than 14,000) will be flashed on your scope by Center well in advance of reaching the boundary. Accepting the handoff implies that the plane can continue on the published routing and enter your airspace. Center MUST ensure the airplane is on SOCAL’s frequency prior to the plane reaching the airspace boundary.

 

[Ernesto Alvarez 818262]

good articles

 

kinda off topic from yours, but i personally would also like student controllers to learn how to actually descend an aircraft and not be too focused on PD's. some students get too focused on those that they either forget or never learn how to properly formulate a descent and either start you down too early or too late when they dont issue a PD, even have run into a C1 recently who had no idea what a PD is. i had the same C1 already giving me descent instructions while cruising at 21000ft still over 100nm from the field, did challenge the controller about it, didnt really seem to have a clue other then he wanted me at 5000ft in time, plenty of time at over 100nm after that he just waited til i let him know i was ready.

 

yes i know, not ATC's primary responsibility and it does play a roll in Andrews article above on making sure folks are at certain altitudes for the handoff, however if a controller is actually going to issue descent instructions, they should atleast know how to formulate when to do it, it seems to be becoming a lost art online as more and more forcus way too much on other stuff like PD's and profiled stars.

 

Bruce B's old training articles had some really good tutorials on exactly this

[Andrew Doubleday]

I'm trying to convince a friend to post a bit on the topic of "counting miles" and on "descent calculations" as well (with lots of experience on the subject) - I think those would also be useful topics for training departments.

 

I'm not sure what has jumped into me recently, but I feel like many of us serious guys on the network have kind of resolved ourselves towards feeling rather hopeless about quality and direction on the network recently (I know this as many of them congregate at Minnie's Bar & Late Nite Lounge from various facilities to discuss topics like this regularly - ask if you're interested in what that is). I felt now would be a good time to dig this stuff out and at least make an attempt to push the information...

 

Ernesto, I have a real concern with issuing pilot's discretion descents as of late... I'm finding fewer and fewer pilots actually understand how to properly calculate their own descent rate (which is pretty depressing) let alone understand the instruction. I'll regularly issue it to pilots, especially during our midnight operations at Minneapolis (in which pilots are direct destination airport with a PD to 10K) or even just issuing crossing restrictions on the arrivals, such as "cross TWINZ at 11,000." Many times there will be a brief pause followed by a readback of, "uhhh... rgr, descend and maintain 11,000... to cross TWINZ" or in some cases just a readback of the altitude, "11,000" which indicates to me that the pilot has basically no idea what I've just given him an instruction to do... Then you'll find that the guy has started down immediately and is level 70 miles outside of the place you were planning him to be level by - and guess what? You've got 4 guys behind him that he's now created a sequencing issue for (now generally when this happens I'll point it out to the pilot right away and end up working the other guys in over the top of and ahead of the one who decided to start down early - no point in ruining the experience for the others!). It's a shame as it can be a blessing of a tool to easing workload for a controller (and should be more efficient for the pilot) as long as the controller doesn't have to fly and calculate the descent for the pilot (which I find myself having to watch PD aircraft like a hawk now days) - that should be their job to work out as the pilot... But I digress ...

 

Anyways, those of you that are still here that remember how to work traffic (and actually care) - spend a few minutes to teach these guys (both pilots and controllers) what they need to be fixing. Those of us concerned with quality and direction of the network are somewhat of a dying breed these days.

Edited March 8, 2011 at 09:23 AM by Guest

[Nate Johns]

I gotta say... in all fairness to pilots.

 

If you as the controller aren't ready to let them start down yet, don't use PD as your tool to ensure separation, vertically or longitudinally.

 

It's PD for a reason. Even if they don't really grasp the meaning of PD, they can still start down whenever they please, and at a 100 FPM or a 8000 FPM descent rate too. If right now hurts, don't issue PD until it won't.

 

~Nate

 

PS - I'll think about the other stuff, but would you mind not just totally blasting my credentials out to the world?

[Andrew Doubleday]

PS - I'll think about the other stuff, but would you mind not just totally blasting my credentials out to the world?

 

 

Sorry!

[Keith Smith]

AJ,

 

What you're doing is noble, and some people will appreciate it, but for you own sanity, consider your wider audience (both on the controlling side and the pilot side). Actually, on the controller side, there's nothing wrong with sharing this info...as information is nothing but a good thing.

 

However, the toolbox that is available to real world controllers isn't always available to controllers here due to disparate skill/interest levels among pilots.

 

That, and Nate beat me to it...PD is digging your own grave for spacing here on VATSIM because there's no evidence to support the idea that pilots, in general, will follow a real world descent profile. I would suggest using absolute descents that mirror a typical descent profile with healthy speed restrictions to guarantee speed.

 

"Maintain present speed, descend and maintain FL230." That way, you step everyone down at the same point, and [Mod - Happy Thoughts]uming they are at a speed which will maintain spacing, then everything remains kosher through the descent.

 

"Cross SYMON at and maintain 12,000" can be used real world, in high traffic because Part 121/135 aircraft are going to calculate a reasonable TOD point, they're not going to blindly plummet and maintain. You just can't [Mod - Happy Thoughts]ume that here.

 

Try not to be too frustrated by it. Work with the tools that DO work (explicit descents, speed restrictions, etc) and you'll be a happier camper. I have learned this after working many, many, many events in the past, and doing an objective comparison of the techniques that worked, and those that did not.

[Andrew Doubleday]

Thanks for the information.

 

I had a chance to work Minneapolis Center during a recent event this weekend for a couple of hours and had a bit of sequencing work to do on one of our arrivals. I generally would obtain/issue speeds when I needed to worry about hitting gaps with people in a situation such as this. I did still make use of the PD stuff, but in moderation (as in issueing restrictions that would put aircraft over the top of the low center sectors had they been on) then seeing how that worked and issuing crossing restrictions or solid descents from there as needed. I found myself hitting 12-15 MIT in about every situation - so not too bad.

 

I'm starting to figure out what works and doesn't with enroute separation more so... I've always been more of an approach controller than an enroute controller by far but I think I can hold my own working center these days.

 

 

-AJ

[Steve Bauman 1156360]

I am "with you" guys on this topic.

 

Just kidding. This is a great topic. I am one of those "with you" guys when getting handed off to another frequency.

 

I was all ready to argue this, because I swear in my training, if in a radar environment, they already know who you are and where you are, so "with you" was the only required communication.

 

After reading this, and doing some independent research (the FARs and AIM), I stand corrected; it would be preferable to just state "Cessna 3369A, level four thousand".

 

I also learned I've been saying something else that probably grinds the controller's gears; "Cessna 3369A is climbing through two-thousand five hundred for four". Huh? "for four"? Is he going to 44,000 or 4,000?

 

From what I've read, I need to change my habit to "Cessna 3369A is p[Mod - Happy Thoughts]ing two-thousand five hundred, climbing four thousand".

 

This has been a great read, because I learned more than one thing I've been doing wrong!

 

I know you guys (as controllers) don't have a lot of time to correct us; but I for one, if time permits, always appreciate being corrected. Sometimes my memory from training doesn't match up to reality. I don't take it personally or get insulted; I will verify what I've been told with the FARs and AIM, but if I'm doing something wrong, I love to hear about it!

 

I have given positive feedback to controllers who have taken the time to correct me (nicely, I might add!) when I've screwed up.

 

big thanks! great thread!

[Dan Arsenault 949706]

I am "with you" guys on this topic.

 

Just kidding. This is a great topic. I am one of those "with you" guys when getting handed off to another frequency.

 

I was all ready to argue this, because I swear in my training, if in a radar environment, they a

 

Steve,

 

If you are handed off from another controller, the "Toronto center, ACA198 With you FL360" works fine.

 

I believe the point was when you are in first contact with an ATC while in flight, IE Center pops on, you are at your cruise, and he sends that "contact me". Some pilots will just call in "Toronto Center ACA198 with you".

 

In the real world, which we try hard to mimic here on VATSIM, the controller would have no idea where you are. The proper way would be "Toronto Center, ACA198 is 20 miles east of XYZ fix, FL360". Then he scans his scope, sees a target, issues a new squawk code and upon your changing your code to the proper one, then he can identify you.

 

So the point here is if you are handed off, the way you were doing it was fine providing you had your callsign and altitude in there.

 

And this thread is quite interesting as well.

 

Dan

[Nate Johns]

 

I'm always slightly bemused, and sometimes make an off-freq comment before I key up when a pilot tells me they're "with me."

 

It's like... no you're not. If you were with me, you'd be in a secure government facility somewhere between 0 and 400' AGL with a smooth ride.

 

Do I know what you mean? Yes. Does it REALLY matter? No. Do hundreds of pilots a day who think they sound extra cool say it regularly? Yes.

 

 

Want a good phraseology lesson?

 

http://www.avweb.com/news/sayagain/192912-1.html

 

~Nate

[Dan Arsenault 949706]

Nate,

 

When I hear a female pilot say that she is "with me", my mind wanders off. Unfortunately, on Vatsim it does not happen often.

 

It's like the radio guy saying "This is Rockin' Johnny with you until midnight". He is just "with you" on freq. It does sound funny now that you mention it. Most of the pilots in rw but not all will check in "Moncton Center, ACA198 level FL360".

 

Either way, just as long as they are "with me" in a timely manner.

 

Dan

[Daniel Hawton]

In the real world, which we try hard to mimic here on VATSIM, the controller would have no idea where you are. The proper way would be "Toronto Center, ACA198 is 20 miles east of XYZ fix, FL360". Then he scans his scope, sees a target, issues a new squawk code and upon your changing your code to the proper one, then he can identify you.

 

Just to nitpick here... from my understanding of Canadian Radar Procedures the fact he gave his position is enough to establish radar identification. In the US, so long as he either A) reports his heading and it correlates along with the track at the position given as well or B) the track matches the route of flight for the track identified on that position then that is enough to establish radar contact through position correlation.

 

IE:

DAL747 reports in 20 miles southeast of AML at FL340.

 

We look at DAL747's route and it matches that track's route, then we have established radar identification.

 

-or-

N462AW reports in 3 miles south of RIC heading 340 at 4,500 VFR.

 

There's a target 3 miles south of RIC appearing to head 340... you have established radar identification.

 

This is, of course, [Mod - Happy Thoughts]uming that there are no other targets in that immediate area that could be "confused" with the track in question... in which case another method must be used.

 

If you have established radar identification through position correlation, using a squawk to establish radar identification is duplicating efforts. If you identified it, "Radar contact" is all that is needed. If you need to [Mod - Happy Thoughts]ign him a squawk, "Radar contact, squawk 1234." (US Phraseology). It absolutely bugs me when I report in, only aircraft in an area, and give all the information necessary and the controller issues a squawk code THEN radar identifies me. It's like I wasted my breathe giving them my location.l

[William Lewis]

It absolutely bugs me when I report in, only aircraft in an area, and give all the information necessary and the controller issues a squawk code THEN radar identifies me. It's like I wasted my breathe giving them my location.l

 

Makes you roll your eyes every time doesn't it? A new controller sure but it bugs me even more when Instructors or even a TA does it because i think that this is most likely being taught to students and it will continue for a long time.

[Dan Arsenault 949706]

It absolutely bugs me when I report in, only aircraft in an area, and give all the information necessary and the controller issues a squawk code THEN radar identifies me. It's like I wasted my breathe giving them my location.l

 

Makes you roll your eyes every time doesn't it? A new controller sure but it bugs me even more when Instructors or even a TA does it because i think that this is most likely being taught to students and it will continue for a long time.

 

Since 90% of my traffic in Gander is coming off oceanic, therefore they are squawking 2000 or 2200, then I have to issue a new squawk code, even if a) I sent him a contact me, and I know darn well it's him contacting me, b) my ATC client knows it's him because it can cheat versus real world systems and c) Servinfo knows it's him because I have been waiting for hours for him to enter my airspace and make my being online useful I even have an advantage over the real world, I have the pilot's name.

 

So while the above quote is true in some cases, in other cases a code change is necessary, even if you really know who the blip on the scope is.

 

I have even been asked by an adjoining FIR to issue a new code to an aircraft in my sector because it conflicts with a code that they have given to another aircraft.

 

Dan

[William Lewis]

We are not arguing that you need to issue as squawk.

 

What we hear that give us the :

 

"XXX Center, Jetlink 2774 25nm East of Grand Rapids VOR at flight level 290."

 

"Jetlink 2774 squawk 1234 and Ident"

 

after you do that and many times you have to call up again such as hey look at me i changed it and hit the ident button but you have not said anything.

 

"Jetlink 2774, radar contact 22nm east of grand rapids"

 

yeah that is us we just gave you that position when we first called up.

 

This is how it should be:

 

"XXX Center, Jetlink 2774 25nm East of Grand Rapids VOR at flight level 290."

 

Controller looks on his screen in that position and sees the target and by using the position correlation method of radar id rather than only issuing a code

 

"Jetlink 2774, Radar Contact squawk 1234."

 

There are 6 ways to ID a target and there are many controllers that just limit themselves to just one. There are many controllers who reissue a squawk code every time regardless if you have already been given one that is perfectly valid and is not in use by any other aircraft.

[Daniel Hawton]

You *do not* have to issue a squawk. This is a major misnomer... you can track an aircraft on anything. Heck, they can not be squawking at all and you can still provide radar services to them. Granted, you don't get a nifty little position identifier on them (STARS/ARTS) and can't initiate automated handoffs... but it's perfectly possible to provide service to pilots NOT squawking a discreet code and still hand them off to neighboring sectors.

[Anthony Pavlak 1058071]

My only hang up with that in VRC, is that V tags (guys squawking 1200) can't be "clicked" to get their ground speed. So in STARS mode, I end up giving all my pattern workers a discreet code so I can get a full datablock on them.

[Bryan Wollenberg 810243]

PD is digging your own grave for spacing here on VATSIM because there's no evidence to support the idea that pilots, in general, will follow a real world descent profile. I would suggest using absolute descents that mirror a typical descent profile with healthy speed restrictions to guarantee speed.

 

Completely agree. I can [Mod - Happy Thoughts]ure you that even real world, PD descents when you're trying to sequence is just asking for trouble. In fact, there is no "typical descent profile" at all...between airlines, types, or even within the same airline! Some are drastically different. You'll have two SKW CRJ-200's, for example, in-trail, same altitude, and each will do something completely different as far as speed, descent rate, and everything else is concerned. While you can get a general feel for what certain airlines and types might do more often than not, you can't bank your career on [Mod - Happy Thoughts]uming the pilots are going to do the same thing every time. That's when you start asking for trouble.

 

Furthermore, there are days when simply the winds between say FL360 and FL240 are 70-80kts difference. Maybe the direction of the winds is completely different. Lately in Socal, the upper-level winds are out of the SW, while the low-level winds are straight out of the west. You give two pilots PD descents, one starts down early, one doesn't, and all of the sudden, you have 120kt overtake. Then you might throw speed differences into the mix too. Southwest might be happily cruising along at Mach 0.78, and go to their 261kt econ descent when they start down. The AAL 767 behind them is still screaming along at FL380 loving life and now you find yourself with a huge overtake.

 

The main advantage is obviously speed control. You don't have to do any conversions, you can [Mod - Happy Thoughts]igned matched speeds, and generally speaking, it's going to work. That is, you descend 2 aircraft to FL300 and [Mod - Happy Thoughts]ign both 280kts, you can expect very similar ground speeds. You have one aircraft at FL300 [Mod - Happy Thoughts]igned 280kts and one at FL400 [Mod - Happy Thoughts]igned some mach number, 7-in-trail who knows what is going to happen?

 

Personally speaking, at a high altitude sector, I shoot to deliver 10-in-trail. That allows for compression in the low altitude sector and gives them some extra space to work with (so they can get their 6-10). I will always start down 2 aircraft and [Mod - Happy Thoughts]ign speeds if they are within about 12 miles of each other. Anything more than that, I'll use PD all day long, along with (usually) not [Mod - Happy Thoughts]igning speeds.

 

Same thing goes with [Mod - Happy Thoughts]igning codes and radar ID'ing, real world. I don't trust pilots. I don't trust them at all. I always [Mod - Happy Thoughts]ume that they're going to do something stupid, and that's how I stay safe. Accordingly, I will always [Mod - Happy Thoughts]ign a code, or at least get an IDENT, before I'll radar ID someone. Pilots have been wrong on their position or altitude more times than I can count. And when it comes down to it, it's my career and livelihood at risk if something goes wrong.

 

For a specific real world example, there was one day just a couple months ago when there was one VFR target in my airspace, squawking 1200, no primaries, everything was routine. It was 25 or so miles S/SW of DAG, indicating 9,500, on a SE-bound heading, just as you might expect from an aircraft heading southeast-bound toward TNP, to avoid Restricted Area 2501. A guy called up VFR 25 miles SW of DAG, 9,500, Eastbound, seeing a cloud layer up ahead, and looking to pick up an IFR clearance to HII.

 

Who the heck else could it possibly be? Everything correlates. Everything looks good. Everything makes sense. "NXXXXX, radar contact, cleared to HII via present position direct, c/m 11,000." Nope. I [Mod - Happy Thoughts]igned a squawk code, had him IDENT, and let the computer acquire the track. He was 35 miles SE of DAG, right in the middle of R-2501 (which was hot to FL260 and had multiple military aircraft and operations taking place). Had I simply radar ID'ed him based on his position, general track, altitude, issued his clearance, and climbed him to 11,000, can you imagine the end result had I climbed him through a military aircraft in 2501, say at 10k or 11k?

 

Sure, see and avoid. He shouldn't have been in 2501...it's NOTAMed in-use. When you're sitting in a court answering questions from the NTSB and the pilot's attorneys, in front of a jury that knows absolutely nothing about aviation, how well do you think, "Well...I [Mod - Happy Thoughts]umed it was the right aircraft" is going to play out, when you have a dead family, a dead military pilot, and millions of dollars worth of damage? And for what, because it isn't cool to [Mod - Happy Thoughts]ign a code and get an IDENT before radar ID'ing somebody? I'll be uncool and take the risk of annoying the pilot a little.

 

Of course on VATSIM, run them planes!! You don't have to be so cautious because nobody is going to die if something goes wrong. Have fun, do your best, and emulate the level of realism you want to emulate. If you want to radar ID someone based on the V that you know has to be the right aircraft, do it! Have a blast.

[Daniel Hawton]

PD is digging your own grave for spacing here on VATSIM because there's no evidence to support the idea that pilots, in general, will follow a real world descent profile. I would suggest using absolute descents that mirror a typical descent profile with healthy speed restrictions to guarantee speed.

For a specific real world example, there was one day just a couple months ago when there was one VFR target in my airspace, squawking 1200, no primaries, everything was routine. It was 25 or so miles S/SW of DAG, indicating 9,500, on a SE-bound heading, just as you might expect from an aircraft heading southeast-bound toward TNP, to avoid Restricted Area 2501. A guy called up VFR 25 miles SW of DAG, 9,500, Eastbound, seeing a cloud layer up ahead, and looking to pick up an IFR clearance to HII.

 

Who the heck else could it possibly be? Everything correlates. Everything looks good. Everything makes sense. "NXXXXX, radar contact, cleared to HII via present position direct, c/m 11,000." Nope. I [Mod - Happy Thoughts]igned a squawk code, had him IDENT, and let the computer acquire the track. He was 35 miles SE of DAG, right in the middle of R-2501 (which was hot to FL260 and had multiple military aircraft and operations taking place). Had I simply radar ID'ed him based on his position, general track, altitude, issued his clearance, and climbed him to 11,000, can you imagine the end result had I climbed him through a military aircraft in 2501, say at 10k or 11k?

 

Sure, see and avoid. He shouldn't have been in 2501...it's NOTAMed in-use. When you're sitting in a court answering questions from the NTSB and the pilot's attorneys, in front of a jury that knows absolutely nothing about aviation, how well do you think, "Well...I [Mod - Happy Thoughts]umed it was the right aircraft" is going to play out, when you have a dead family, a dead military pilot, and millions of dollars worth of damage? And for what, because it isn't cool to [Mod - Happy Thoughts]ign a code and get an IDENT before radar ID'ing somebody? I'll be uncool and take the risk of annoying the pilot a little.

 

Of course on VATSIM, run them planes!! You don't have to be so cautious because nobody is going to die if something goes wrong. Have fun, do your best, and emulate the level of realism you want to emulate. If you want to radar ID someone based on the V that you know has to be the right aircraft, do it! Have a blast.

 

See, technically by the book you established radar identification (which I am sure you know). So long as you follow the 7110.65, you're mostly safe from court. That's when you hop in a bus, throw her in gear, and point straight at the FAA.

 

I work with a warning area over the gulf and deal with stupid military pilots every day (I work a training sector!! hurray!) that go out and "play" while I got VFR guys that transition through, OMAHA and TEAL aircraft that like to work, and helos departing from oil rigs. More than half the time, I always tell center point out approved, and issue traffic calls to guys working in the airspace. But they're technically VFR at that point, so they should be looking anyway. But then I remember the phrase I heard all through Navy ATC School, "Pilots are stupid" and give it to them. It's funnier working a PAR approach and getting a guy who requests no gyro vectors on final and confuses his lefts and rights "Turn right" to watch the target track further left. "Your other right".

[Bryan Wollenberg 810243]

See, technically by the book you established radar identification (which I am sure you know). So long as you follow the 7110.65, you're mostly safe from court. That's when you hop in a bus, throw her in gear, and point straight at the FAA.

 

Well, I would have established radar identification on the wrong aircraft, based on every piece of information I had. I saw the target right where the pilot said he was, right at the altitude the pilot said he was at, and headed in the same direction the pilot said he was heading...all with not a single other VFR aircraft anywhere in my sky. My point being that it's far better to use every tool available and be safe, than to guess and hope for the best. If a pilot thinks it's uncool to have to get a discreet code and IDENT before being ID'ed, he can request flight following or IFR clearance from somebody else. Working less isn't going to hurt my feelings any.

 

Now since I would have given him a discreet code at some point anyway, for his IFR flight plan, I would have eventually seen that I was looking at the wrong target, but by that point it could have been too late. I know a lot of people who would have radar ID'ed him (the incorrect target) and then included the squawk code as part of the IFR clearance. To me, it's just unsafe. I always [Mod - Happy Thoughts]ign code, IDENT, start track, and then radar ID the a/c.

 

I work with a warning area over the gulf and deal with stupid military pilots every day (I work a training sector!! hurray!)

 

Pensacola, by chance? I've heard plenty of stories of what goes on down there. Sounds entertaining to say the least!

 

It's funnier working a PAR approach and getting a guy who requests no gyro vectors on final and confuses his lefts and rights "Turn right" to watch the target track further left. "Your other right".

 

ROFL!! It's like the controller trainees who mix up their traffic calls. "Traffic 9 o'clock, blah blah..." Pilot: "Don't see anything out there. Do you mean our 3 o'clock?" Doh!

[Daniel Hawton]

See, technically by the book you established radar identification (which I am sure you know). So long as you follow the 7110.65, you're mostly safe from court. That's when you hop in a bus, throw her in gear, and point straight at the FAA.

 

Well, I would have established radar identification on the wrong aircraft, based on every piece of information I had. I saw the target right where the pilot said he was, right at the altitude the pilot said he was at, and headed in the same direction the pilot said he was heading...all with not a single other VFR aircraft anywhere in my sky. My point being that it's far better to use every tool available and be safe, than to guess and hope for the best. If a pilot thinks it's uncool to have to get a discreet code and IDENT before being ID'ed, he can request flight following or IFR clearance from somebody else. Working less isn't going to hurt my feelings any.

 

No I understand. Was just saying the court couldn't do much as you were following the book. Trust me, safer is always better. But in this case, it would've been pilot error, not yours. Though that won't help you sleep at night if anything were to have happened.

 

Pensacola, by chance? I've heard plenty of stories of what goes on down there. Sounds entertaining to say the least!

 

Yup, NPA and working Seabreeze. What stories have you heard? Our latest was a C172 that thought he was landing at Fergueson landed on a quiet Saturday afternoon, on a runway that from the tower you'd have had your back to due to the active runway being about 120 degrees the other direction. He managed to land, cross the parallels and make it to the eastern ramp before anyone saw him. Parked himself next to the row of blue angel F18s. Then gets out and walks into the Blue Angel Hanger asking where he was. VFR pilot flying with only a GPS on board (aka, no charts), couldn't tell the difference between http://www.airnav.com/airport/KNPA and http://www.airnav.com/airport/82J. Since it was dead, no one was really paying much attention to that half of the field... and he entered the charlie squawking standby so radar didn't see him either (we're used to seeing primaries popping up randomly all over the place). Running joke for a while was the blue angels bought a Cessna and designated it VVBA10 (Blue Angel 10).

 

ROFL!! It's like the controller trainees who mix up their traffic calls. "Traffic 9 o'clock, blah blah..." Pilot: "Don't see anything out there. Do you mean our 3 o'clock?" Doh!

 

Our trainees don't really get that far half the time... it's like, they're absolutely afraid of traffic calls... so it's the instructor that gives them.