Just wanted to add that, although the VRC program defaults to include the phrase "winds", it should only be pronounced in the singular form as "wind" when stating it on frequency/cutting an ATIS.

Also, the phrase "sky conditions" should be omitted while cutting an ATIS (I notice a lot of people tend to include this when I listen in).

In the example METAR Matthew posted, it should be cut as follows on the ATIS: "Memphis International Airport information ECHO, two-two-five-four zulu, wind variable zero-seven-zero to one-four-zero at eight (knots is implied), visibility one-zero (omit statute miles as it's implied when discussing visibility distances), few clouds at four-thousand, ceiling two-five thousand broken... <continue on with recording>"

That's a good one as well, Harold. Radar identification is an entirely different animal than Mode C verification. You don't radar identify aircraft *at* an altitude - just via a given position.

What should be said is, "radar contact, altitude indicates FL340, please verify?" or something to that tune should the pilot fail to report an altitude when checking in. Mode C is considered valid if the observed altitude is within 300 feet of the pilot reported altitude (either above/below reported altitude). Otherwise you'd want to start taking steps to ensure the pilot is on the correct altimeter setting for his/her area.

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 documentation...

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

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE [/div][div class=\\\'quotemain\\\'][!--quotec--]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 document 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 document - 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 glass 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 glass 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 pass 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 passing of flight plans…

Step One:  Passing 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 passed 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 passed 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 circumstances the controllers or their assistants are responsible for passing 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 passing 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 assigned.  Similarly, the portion of the pilot's route that he has already flown is also not passed.  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 assigned 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 assigned, another reason for passing 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 pass 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 assigned routing has been passed, 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 assigned 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 assume 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 passed 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 assigned flight plan route, at the assigned 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 document, 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 pass 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 passing the aircraft id, and any other flight plan information if it hasn't yet been passed.  Otherwise, after passing 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 document.

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 assigned 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 assigned 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 assumed 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' assigned 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 circumstances.
SEE PART 2 of Understanding Handoffs and Coordination[/quote]

This began last Thursday afternoon (the 13th) as just another afternoon controlling session at ZMP that has turned into a rather impressive challenge to see how long we can keep this going. We've been open for nearly 6 days straight thus far (7 of us or so have been alternating shifts regularly). Just figured I'd throw it out there that we're pushing for a "perfect week" (100% staffing) this week at ZMP.

This may very well be a network record setter already with consecutive time on a single position, but our goal is to stay staffed through Sunday at 2359Z at the very least to wrap up this week's Iron Mic totals (putting us at roughly 10 days or 240 hours straight ATC coverage).

Thanks to everyone who has been participating regularly so far (controllers and pilots), it's been a fun week and the feedback has been great received regarding this so far (or so I've seen). Would be nice to see even more pilots come out and fly with us. We offer a variety of under-utilized and fun airports (especially with the weather conditions the region sees this time of year) over a massive sector with arguably some of the best services within VATUSA between the realistic operating procedures to the knowledgeable controller roster (most with a good amount of real world aviation experience in some form or fashion).

This is by far one of the best crews I've ever operated with during my years on the network. You'll like the service you'll get - trust me on that! We'll be here all week (day or night)... literally.


Regards,

Alex, thanks for your words... I thought somewhere along the line someone stated that network management was working towards improvement of transparency... I think it's fairly apparent that has been lost. Richard Jenkins was the first one (in the VATSIM forum) to actually state that things were actually being looked at... Why couldn't someone within the Founders or current BoG say just that 10-15 pages ago in that thread... lol.

The quote I took from Kyle was posted within the VATSIM forum, page 6 I believe of the thread I mention frequently here. He didn't delete it. If the intent of this was misinterpreted, then I feel that it should have been worded differently from the start because I surely wasn't the only one who took it this way. I'm in agreement that not all of the BoG or Founders are supportive of this push for simplification, knowing a member or two myself. I just wish they'd speak up a bit more.


-AJ

AJ,

What you've said is essentially what everyone else who controls regularly is saying, specifically in regards to pilot quality. It's a very disheartening trend to see how many pilots have no clue whatsoever as to what is going on in the most remote sense. While pilots used to model the habits of FS9/FSX Default ATC, I don't even see THAT anymore; it's turned into a conglomeration of confusion all over the scope. There are posts in the VATSIM Forums about it just about every couple of weeks. Though, instead of focusing on pilot training, it seems we're now focusing on controller de-training, if that's even a word. I just don't get it.

Well said... I'm at the point where, more often than not, I feel like I'm unable to be an effective controller with the declining level of competence. It's very difficult to get into a "groove" where you can feel the momentum built up on frequency with everything under control and everyone enjoying the professionalism of the environment (that "high" Gary speaks of). Again, it's been so long since I've last experienced that... I feel like I'm hopelessly hunting for it when I get on these days. Like an addict unable to get his/her fix...

I don't know about many of you, but I signed up to control on VATSIM, not to be babysitter having to hand-hold everyone that visits our sectors because they don't know how to fly. Did anyone ever consider this being a critical reason towards a number of people not wanting to become controllers here? This virtual job has become one more suited for a professional teacher now...

At the same time, I must re-iterate what I said in the VATSIM Forums that much of what we've heard thus far is hearsay. I see no point in mass-resignations unless there is hard evidence, like a notice of a policy change or something, that VATSIM staff will make major changes to the way ARTCCs and divisions are operated. Sure, I too take offense that some higher-ups have degraded the work we've done in improving our areas of VATUSA, but I'm sure they've had those feelings for quite a long time. Whether or not they will act on them is something I look forward to seeing. Usually what I've seen in the forums are discussions on various idealistic situations, most if not all of which never come to fruition. I wouldn't think this one is really any different.

Allow me to direct you to a recent quote from David Klain (VATSIM President) regarding off-peak certification removal:

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE [/div][div class=\\\'quotemain\\\'][!--quotec--]The VATSIM leadership totally agree with the idea that controllers should be able to work major airports faster. Bottom line is that off-peak solos are not authorized. Not part of GRP and they violate the intent of GRP and the network. GRP is a binary thing – you are either qualified or not. If qualified, you are qualified to work the airspace at any time. If not qualified, then you should not be working it at any time. Several ARTCCs/FIRS/VACCs in various divisions had brought in this “off peak” solo as a way of giving a student a “temporary permission” to control a major airport at “off peak” times (whatever the heck they are). There were (and are) a number of problems with this idea:

(1) when is off peak? Local times? Zulu times? Where published? Different for every airport around?
(2) Where is the list of who is authorized to control “off peak”…as compared to endorsed to control that major airport at any time? How do supervisors enforce the policy?
(3) The whole point of GRP is that if a person has the requisite knowledge to work the airspace, he should be authorized to control it. GRP 2.0 originally had no major airports or designated airspace. It was added during the review as part of a compromise because a number of review participants were insistent the world would collapse if anyone worked that airport/airspace without specific training. The compromise was that for designated airspace and major airports there would be a requirement for an appropriately-rated controller to also get an endorsement signifying he/she was familiar with the nuances of that specific airport/airspace. If a person is familiar with that airsapace (the SOPs, nuances, etc.) and the instructor is willing to sign them off for “off peak” times, then by definition they are familiar with it and should be granted the endorsement and able to work it at any time…period. Reality is that a newly-endorsed controller will make some mistakes…but VATSIM is a learning environment that is not “zero fault” and those mistakes are not only expected and acceptable, they are part of the learning process and learning environment.

Bottom line: off peak endorsements are not permitted and that word should be filtering down to the various divisions and then the facilities in those divisions. At that point there any and all references and use of "off peak endorsements" should (and will) go away. Anyone who runs into a facility that is still imposing them should notify the appropriate staff (obviously starting at the division level and then escalating to the RD if necessary).

GRP is about INCREASING controller's access to airspace and getting more controllers online...off peak endorsements are actually a way of DELAYING a controller from doing just that out of some fear that the controller will make a mistake. Given the fact that VATSIM has ZERO risk to people or equipment, those mistakes are part of life and the facilities that don't get that need to get over it and get with the program as articulated by the Founders.

Dave[/quote]

I think this should definitely be evident enough that they've decided to do away with it.

Kyle Ramsey, another BoG member:

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE [/div][div class=\\\'quotemain\\\'][!--quotec--]The "quality uber alles" crowd are on a path not supported by the Founders or BoG. You can continue to rant in these forums about it, you can hold on, for now, to your staff positions. But know your agenda is not going to continue to influence VATSIM and your way is going away.[/quote]

The general feel I'm getting after reading posts like this is borderline militant... Either we get with the program articulated by the founders hiding in their ivory tower and their brilliant understanding of things at the facility-level... Or we get out. Coming directly from network management at that... Impressive, to say the least, no?

The recent resignations of ZLA staff should not be taken lightly with regards to this either. ZLA has been a powerhouse facility of VATUSA for a long time and the off peak certifications have been _critical_ towards the success of training in that facility due to the massive influx of students and limited training staff. Before you jump to the conclusion that the problem must be as simple as I just wrote it (referencing "limited training staff"), you should know more about the principles of ZLA. ZLA has built itself on the principles of training knowledgeable, well trained, professional controllers - this takes a while to achieve for many, but is an extremely rewarding experience once you get to that level. It gives many the motivation to work towards that level. Taking away that motivation by opening the proverbial "flood gates" will likely wreck what's been created there. Training off-peak was the motivating factor towards obtaining the full certification so you could control during busy periods/events. This system worked well towards fulfilling ZLA's needs with the extreme popularity. Did anyone bother to check with ZLA before making the decision to kill off-peak? I'd be surprised with the resignations that have just occurred...

After many discussions I've had with people from multiple facilities over the past few weeks regarding this topic and others, I'm quickly discovering there are plenty of us here fed up with the present status of VATSIM and network management. All of them feel that the network is capable of much more, yet being restricted from progress not only by politics that have developed here, but also from this attempt to simplify controller training. I'm speaking on behalf of many of them because I no longer have anything to lose (I already lost my staff position years ago, sorry Kyle). I've witnessed the political crap, I've dealt with backstabbing (one of the few things I can thank this network for now; teaching me at an early age how to protect myself from this in the real world) amongst other ridiculous things you'd expect to see in the White House (having managed a facility for 15 months, and been removed due to political reasons). I'm slowly realizing it's honestly not worth it to dump time into VATSIM anymore if it's going to continue down this road. And I hate to say this, but I've already begun to pursue alternatives to VATSIM along with a number of these others...

I could easily delve more into specifics on wonderful stories of the gruesome politics I've experienced here in many more posts. I'll reserve comment, for now, but will likely come back to this soon to discuss specifics on a certain facility I've witnessed, and used to be a proud member of, go down the tubes as I feel it applies to this topic and the present status of the network in many ways.



-AJ

Anthony,


C90 uses ACD real world. Just grab that color profile (I think it's in one of the posts above) and I'd recommend using that with STARS radar mode. Same is used in SoCal as far as I know.


-AJ