Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Andrew Doubleday

Pages: [1]
1
Events / Super Bowl LII Minneapolis
« on: October 30, 2017, 11:31:00 AM »


Join us in the Bold North for Super Bowl LII! The stage is set as the Philadelphia Eagles battle the New England Patriots on February 4. Join us as we light up the Minneapolis airspace on Feb 3 from 1800-2200 CST (2359-0500z) to welcome everyone flying in for the big game! The stadium might be climate controlled, but the airport won't be! Come battle the challenging winter elements at Minneapolis Intl (MSP), or load up your high-profile clientele and carry them in style to one of the convenient satellite airports within Minneapolis, such as St. Paul Downtown (STP) or Flying Cloud (FCM)! No matter your destination or your cargo, ZMP controllers will be prepared to deliver you to your destination in time for kickoff!

2
Events / ZMP - Last Minute Shopping [2359-0400z]
« on: October 07, 2017, 04:51:17 PM »

ZMP knows you waited until the last minute. Don't worry, we won't tell!

Lucky for you, the world famous Mall of America is right across the street from Minneapolis/St. Paul International Airport!

ZMP will be providing full ATC service to KMSP on December 23 from 2359-0400z.

More than enough time for you to fly in, hit the malls, and fly out...before anyone else knows how long you waited!

3


Join us Friday, April 14th from 1800-2300 CDT for Friday Night Ops: Minneapolis, Featuring Minneapolis Intl Airport!

4


Dubbed the "greatest show on dirt", Omaha is proud to be host to the NCAA Mens' College World Series! Join us as we staff Omaha Eppley Airfield during the tournament!

Saturday June 24th 21600-2200PM CST (2100-0300z+1).

5


ZMP Presents our 11th Annual BYOB (Bring Your Own Bizjet) featuring Omaha-Eppley Airfield (OMA)!

Each year, Warren Buffet's Berkshire Hathaway Annual Shareholders Meeting is hosted in Omaha in which hundreds of the world's wealthiest will attend! Time to bust out your Business Jets and head to Omaha in style...

Join us on May 6th, 2017 for full staffing at OMA from 2100-0100z (4PM-8PM CT). See you there!

6



ZMP and ZKC ARTCCs Present... The Great Plains Tetralogy!

Join us on Saturday, March 4th from 5pm to 10pm CT as we staff up Lincoln, Omaha, Kansas City and St Louis for a four-way crossfire event. Whether you prefer to fly heavy metal or light GA, this event has an airfield for every preference. Five hours of solid staffing in the Heart of the Great Plains allows you time to experience all!

7
Events / [26NOV16 23:59-04:00z] ZMP Presents - Rochester Radio-Therapy
« on: October 17, 2016, 09:56:57 PM »


Mobilize your medevac flights to Rochester, Minnesota (Home of the World Renowned Mayo Clinic) as we host Rochester Radio-Therapy on Saturay, November 26th from 6-10PM CST (0000-0400z+1).

Rochester is located about 75 miles (65nm) South-Southeast of the Minneapolis area and is home to the world renowned Mayo Clinic. Many medical flights frequent the airport on a yearly basis from around the world to obtain the best medical care available. The airport even has it's own dedicated section of the terminal to accommodate patients travelling between the airport and clinic.

Feel free to fly your jets, props, or helicopters into and out of RST as we place focus on one of the lesser known gems of the Minneapolis ARTCC. This is a great opportunity to brush up on general aviation communications and procedures with some of the most professional and realistic ATC in the division. Air carrier service is also available to/from ORD, ATL and a hop, skip and a jump away from MSP for those that wish to fly commercial.

8
The Classroom (Controller Tips) / Hazardous Weather Information
« on: May 26, 2012, 02:24:19 PM »
Initial article written for/posted at ZMP, but have received requests to have it more publicly available for interested parties.



Since we're reaching the time of year where severe weather can significantly impact ZMP, I figured now would be a good time to include information on the dissemination of weather information to aircraft on frequency.


What Information Needs to be Provided?
How do we know what types of weather information need to be disseminated to pilots? Chapter 2, Section 6 of the 7110 explains this:

Quote
Controllers must advise pilots of hazardous weather that may impact operations within 150 NM of their sector or area of jurisdiction. Hazardous weather information contained in HIWAS broadcasts includes Airmen's Meteorological Information (AIRMET), Significant Meteorological Information (SIGMET), Convective SIGMET (WST), Urgent Pilot Weather Reports (UUA), and Center Weather Advisories (CWA). Facilities must review alert messages to determine the geographical area and operational impact for hazardous weather information broadcasts. The broadcast is not required if aircraft on your frequency(s) will not be affected.

Another note to keep in mind for those of you providing terminal approach control services or ATCT services:

Quote
c. Terminal facilities have the option to limit hazardous weather information broadcasts as follows: Tower cab and approach control facilities may opt to broadcast hazardous weather information alerts only when any part of the area described is within 50 NM of the airspace under their jurisdiction.


What is this Information?
Now that we know the types of weather information we need to be on the look-out for as controllers, What exactly does this information mean?

- AIRMETs (AIRman's METeorological Information) include information about widespread (3000 square miles or larger areas) weather phenomenon associated with IFR conditions, turbulence, and icing conditions that primarily may affect VFR aircraft and sometimes larger operators. They are broken down into three sub-categories listed below:
   
         • AIRMET Sierra (IFR):
              Ceilings less than 1000 feet and/or visibility less than 3 miles affecting over 50% of the area at one time.
              Extensive mountain obscuration

         • AIRMET Tango (Turbulence):
              Moderate turbulence
              Sustained surface winds of 30 knots or more at the surface

         • AIRMET Zulu (Icing):
              Moderate icing
              Freezing levels

- SIGMETs (SIGnificant METeorological information) advise of weather potentially hazadous to all aircraft other than convective activity. In the conterminous U.S., items covered are:

         • Severe icing severe icing below 8,000 feet • Severe or extreme turbulence severe turbulence between FL100 and FL240
         • Duststorms lowering visibilities to less than three (3) sm
         • Volcanic Ash

- WST - Convective SIGMETs (SIGnificant METeorological information) are issued in the conterminous U.S. for any of the following:

         • Severe thunderstorm due to:
            Surface winds greater than or equal to 50 knots
            Hail at the surface greater than or equal to 3/4 inches in diameter
            Tornadoes

         • Embedded thunderstorms
            Line of thunderstorms
            Thunderstorms greater than or equal to VIP level 4 affecting 40% or more of an area at least 3000 square miles

- UUA - Urgent PIREPs (Urgent PIlot weather REPorts) include information reported directly from the pilot concerning turbulence and icing information.

- CWAs (Center Weather Advisories) are an aviation weather warning for thunderstorms, icing, turbulence, and low cloud ceilings and visibilities.


So now that we know the types of weather information we need to be on the look out for as controllers, where do we find this information?


AIRMETs/SIGMETs
AIRMET and SIGMET information can be found from sources such as ADDS (Aviation Digital Data Services) found at this link http://aviationweather.gov/adds/airmets/. On this page, you'll note a section labeled "Text AIRMETs/SIGMETs: Check at least one in each column:" followed by a series of check-boxes beneath that allow you to specify the types of weather information you are seeking and specific areas/area for that information with a map below that indicating which states fall within the given areas. See the below image for a visual:

[img]http://dl.dropbox.com/u/16162462/HWI/1.jpg\\\" border=\\\"0\\\" class=\\\"linked-image\\\" /]

You'll note that the ZMP falls within the Chicago area according to the map, so we'll want to specify that area when seeking hazardous weather information. Although AIRMETs (IFR, turbulence, icing information, primarily) are certainly important to pay attention to, they are generally not read as often on frequency as SIGMET/Convective SIGMET information/UUAs/CWAs. To pull up the SIGMET/CONVECTIVE SIGMET information, you'll want to check the following boxes for our area and then click the "Retrieve" button. See the below image for a visual:

[img]http://dl.dropbox.com/u/16162462/HWI/2.jpg\\\" border=\\\"0\\\" class=\\\"linked-image\\\" /]

Now a textual list of all current SIGMET information will display in a new window. See the below image for a visual:

[img]http://dl.dropbox.com/u/16162462/HWI/3.jpg\\\" border=\\\"0\\\" class=\\\"linked-image\\\" /]

Now that we have the textual list, we need to understand how to decode the information and read it on frequency to inform the pilots.

Convective SIGMETs are issues for the Western (W), Eastern (E) and Central © parts of the United States.  Each SIGMET report will begin with the place of issuance followed by the date and ZULU time in the very first line. They are generally issued at 55 minutes past each hour but can be issued at any time in between. The second line will show SIGW, SIGC or SIGE depending on the region it is for. The third line will read "CONVECTIVE SIGMET XXW/C/E" with the "XX" being a number (1 through 99) and the W/C/E following to indicate the affected region of the United States. The fourth line will indicate the time the SIGMET is valid till (2 hours from the time of issuance). The fifth line will indicate the affected States/areas. The sixth line will indicate the VORs, DME distances and directions for the affected geographic area (which makes it relatively easier for pilots/controllers to plot). The last line (which sometimes may be the seventh or eighth depending on the size of the previous section) then indicates the type of thunderstorms, size of the system, direction/speed of movement and cloud tops of the storms. Following the initial SIGMET report will be OUTLOOK information in which we should probably expect to see further SIGMETs issued for those specific geographic areas.

Something to keep in mind - I've noticed that the list will occasionally display SIGMET information for areas outside of the region we initially selected (you'll note this from the very first SIGMET in this list as it is an Eastern SIGMET for North Carolina, South Carolina and Coastal Waters). You'll have to browse down through the list to find the specific SIGMETs that concern the ZMP area (keeping in mind that it should be within 150nm of our sector). Pay attention to the affected States/water bodies as some of them will be for the South-Central U.S. outside of our coverage area.

[img]http://dl.dropbox.com/u/16162462/HWI/4.jpg\\\" border=\\\"0\\\" class=\\\"linked-image\\\" /]

Now that we understand how to decode the SIGMETs, we need to know how to read these on frequency. Below is the phraseology from the 7110 for reading the SIGMETs on frequency:

Quote
a. Controllers within commissioned HIWAS areas must broadcast a HIWAS alert on all frequencies, except emergency frequency, upon receipt of hazardous weather information. Controllers are required to disseminate data based on the operational impact on the sector or area of control jurisdiction.

NOTE-
The inclusion of the type and number of weather advisory responsible for the HIWAS advisory is optional.

PHRASEOLOGY-
ATTENTION ALL AIRCRAFT. HAZARDOUS WEATHER INFORMATION (SIGMET, Convective SIGMET, AIRMET, Urgent Pilot Weather Report (UUA), or Center Weather Advisory (CWA), Number or Numbers) FOR (geographical area) AVAILABLE ON HIWAS, FLIGHT WATCH, OR FLIGHT SERVICE FREQUENCIES.

So we'll take the example from our above textual list which indicates a SIGMET is out affecting the state of Iowa. Using the above phraseology, we would read that SIGMET on frequency as follows:

"Attention all aircraft, hazardous weather information, CONVECTIVE SIGMET Three-One Central out valid until two-one-five-five zulu for Iowa available on HIWAS, Flight Watch, or Flight Service Frequencies."

Since we are on VATSIM and those frequencies (HIWAS, Flight Watch, Flight Service Frequencies) are not readily available for use by most pilots not using some sort of addon weather programs, we are adding to the "realistic experience" we can provide to pilots on the network by stating this. To assist with this issue, I also like to add and additional phrase after the HIWAS, FlightWatch, Flight Service Frequencies line that would read on frequency as follows:

"Attention all aircraft, hazardous weather information, CONVECTIVE SIGMET Three-One Central is out valid until two-one-five-five zulu for Iowa available on HIWAS, Flight Watch, Flight Service Frequencies, or from air traffic control upon pilot request" which then indicates to the pilot that they can obtain a detailed reading of the SIGMET from us on frequency upon request. In this case, you would simply read the SIGMET in full detail (keeping in mind that you should work your traffic first and provide this information as second priority to that).

A full reading of the example report we are using would read as follows:

"CONVECTIVE SIGMET Three-One Central, out valid until two-one-five-five zulu, affecting Iowa, From 5-0 North-Northeast of Des Moines to 2-0 North-Northwest of Iowa City to 1-0 West-Northwest of Iowa City to 1-0 Southeast of Des Moines to 5-0 North-Northeast of Des Moines, an area of embedded thunderstorms moving from 2-3-0 at 3-0 knots. Tops to Flight Level 3-5-0."

There are, of course, other shortened words that you may see in the reports that need to be decoded but most are relatively simple to unlock using common sense as most of the vowels are simply removed to shorten the length of the report.

Keep in mind that there may be multiple SIGMETs out for our area, especially with the sheer size of ZMP's coverage area. You can read those off using the following phraseology:

"Attention all aircraft, hazardous weather information, CONVECTIVE SIGMETs Three-One Central, three-two central, and three-three central out valid until two-one-five-five zulu for Iowa, Nebraska, Kansas, North Dakota, South Dakota and Minnesota, available on HIWAS, Flight Watch, Flight Service Frequencies, or from Air Traffic Control upon pilot request."


UUAs
Urgent PIREPs can be obtained from multiple online sources, but have no real applicability on VATSIM unless actually reported by a pilot flying on the network. Our IDS system will help you to keep track of that information and deliver this information to other pilots on frequency when/where applicable.

Some important information and phraseology from the 7110 should be noted for PIREPs:

Quote
Significant PIREP information includes reports of strong frontal activity, squall lines, thunderstorms, light to severe icing, wind shear and turbulence (including clear air turbulence) of moderate or greater intensity, volcanic eruptions and volcanic ash clouds, and other conditions pertinent to flight safety.

REFERENCE-
FAAO JO 7110.65, Para 3-1-8, Low Level Wind Shear/Microburst Advisories.
FAAO JO 7210.3, Para 6-3-1, Handling of SIGMETs, CWAs, and PIREPs.
AIM, Para 7-5-9, Flight Operations in Volcanic Ash.
FAAO JO 7210.3, Para 10-3-1, SIGMET and PIREP Handling.

a. Solicit PIREPs when requested or when one of the following conditions exists or is forecast for your area of jurisdiction:

1. Ceilings at or below 5,000 feet. These PIREPs must include cloud base/top reports when feasible.

TERMINAL. Ensure that at least one descent/climb-out PIREP, including cloud base/s, top/s, and other related phenomena, is obtained each hour.

EN ROUTE. When providing approach control services, the requirements stated in TERMINAL above apply.

2. Visibility (surface or aloft) at or less than 5 miles.

3. Thunderstorms and related phenomena.

4. Turbulence of moderate degree or greater.

5. Icing of light degree or greater.

6. Wind shear.

7. Volcanic ash clouds.

NOTE-
Pilots may forward PIREPs regarding volcanic activity using the format described in the Volcanic Activity Reporting Form (VAR) as depicted in the AIM, Appendix 2.

8. TERMINAL. Braking Action Advisories are in effect.

REFERENCE-
FAAO JO 7110.65, Para 3-3-5, Braking Action Advisories.
P/CG Term- Braking Action Advisories.

b. Record with the PIREPs:

1. Time.

2. Aircraft position.

3. Type aircraft.

4. Altitude.

5. When the PIREP involves icing include:

(a) Icing type and intensity.

( b ) Air temperature in which icing is occurring.

c. Obtain PIREPs directly from the pilot, or if the PIREP has been requested by another facility, you may instruct the pilot to deliver it directly to that facility.

PHRASEOLOGY-
REQUEST/SAY FLIGHT CONDITIONS.

Or if appropriate,

REQUEST/SAY (specific conditions; i.e., ride, cloud, visibility, etc.) CONDITIONS.

If necessary,

OVER (fix),

or

ALONG PRESENT ROUTE,

or

BETWEEN (fix) AND (fix).

d. Handle PIREPs as follows:

1. Relay pertinent PIREP information to concerned aircraft in a timely manner.

2. EN ROUTE. Relay all operationally significant PIREPs to the facility weather coordinator.

3. TERMINAL. Relay all operationally significant PIREPs to:

(a) The appropriate intrafacility positions.

( b ) The FSS serving the area in which the report was obtained.

NOTE-
The FSS is responsible for long line dissemination.

© Other concerned terminal or en route ATC facilities, including non-FAA facilities.

(d) Use the word gain and/or loss when describing to pilots the effects of wind shear on airspeed.

EXAMPLE-
“Delta Seven Twenty-one, a Boeing Seven Twenty-seven, previously reported wind shear, loss of Two Five knots at Four Hundred feet.”

“U.S. Air Seventy-six, a D-C Niner, previously reported wind shear, gain of Twenty-Five knots between Niner Hundred and Six Hundred feet, followed by a loss of Five Zero knots between Five Hundred feet and the surface.”

REFERENCE-
AIM, Para 7-1-24, Wind Shear PIREPs.

Much of this information that we, as controllers, need to obtain from pilots is provided to you in the PIREP form via IDS. All you will need to do is fill in the blanks and submit the PIREP to the system. Use the above prescribed phraseology when disseminating the PIREPs to other pilots on frequency when necessary.


CWAs
CWAs are read on frequency in a very similar fashion as the SIGMETs. What exactly is a CWA?

CWAs are unscheduled in-flight, flow control, air traffic, and aircrew advisory. By nature of its
short lead-time, the CWA is not a flight-planning product. It is generally a nowcast for conditions
beginning within the next two hours. CWAs will be issued:

        • As supplement to an existing SIGMET, Convective SIGMET, AIRMET, or FA.

        • When an In-flight Advisory has not been issued, but observed or expected weather
           conditions meet SIGMET/AIRMET criteria based on current PIREPs and reinforced by other
           sources of information about existing meteorological conditions.

        • When observed or developing weather conditions do not meet SIGMET, Convective
           SIGMET, or AIRMET criteria; e.g., in terms of intensity or area of coverage, but current Pilot
           Weather Reports or other weather information sources indicate existing or anticipated
           meteorological phenomena will adversely affect the safe flow of air traffic within the Air Route
           Control Center (ARTCC) area of responsibility.

Where can CWAs be found? Click the following link: http://aviationweather.gov/products/cwsu/. This will bring you to a page with a map showing all of the ARTCC boundaries within the U.S. Mouse over the ZMP area (which should highlight in a reddish color) and click. A new, smaller window should open that should then display the current CWA and MIS (Meteorological Impact Statement) information. MIS are for ATC planning purposes only and NOT read over the frequency to pilots.

Here is an example of a CWA:

[img]http://dl.dropbox.com/u/16162462/HWI/5.jpg\\\" border=\\\"0\\\" class=\\\"linked-image\\\" /]

The above example is a CWA issued from the Kansas City, Missouri ARTCC. The "3" after ZKC indicates this CWA has been issued for the third weather phenomenon to occur for the day. The "301" in the second line denotes the phenomenon number again (3) and the issuance number, "01," for this phenomenon. The CWA was issued at 2140Z and is valid until 2340Z.

This would be read on frequency as:

"Attention all aircraft, hazardous weather information, Center Weather Advisory Three-Zero-One out valid until two-three-four-zero concerning an isolated thunderstorm over the KCOU airport available on HIWAS, Flight Watch, Flight Service Frequencies, or from Air Traffic Control upon pilot request"


Weather Deviations
Something else to keep in mind on this topic is pilot deviations for weather. I've heard many controllers throughout VATUSA get completely tripped up and turn to mush when a pilot makes a request such as, "Hey Center, N123AB, we need to turn about 30 left for build-up..."

Handling weather deviations is actually quite simple (phraseology-wise). The phraseology for this is as followed:

Quote
2. When a deviation cannot be approved as requested and the situation permits, suggest an alternative course of action.

PHRASEOLOGY-
UNABLE DEVIATION (state possible alternate course of action).

FLY HEADING (heading),

or

PROCEED DIRECT (name of NAVAID).

b. In areas of significant weather, plan ahead and be prepared to suggest, upon pilot request, the use of alternative routes/altitudes.

PHRASEOLOGY-
DEVIATION APPROVED, (restrictions if necessary), ADVISE WHEN ABLE TO:

RETURN TO COURSE,
or
RESUME OWN NAVIGATION,
or
FLY HEADING (heading),
or
PROCEED DIRECT (name of NAVAID).

It may not always be possible to approve a weather deviation due to traffic or other factors. Keep in mind, the pilot has ultimate authority in making these deviations, however. It's more or less a "weather emergency" in this case as flying directly through the convective weather could present a massive risk to the safety of the flight. As a controller, you'll need to find a way to work around these situations.

Another way that I regularly seem to hear deviations for weather approved by ATC:

"Deviations left of course/right of course approved, when able proceed direct [VOR/FIX/AIRPORT]."



This about covers the dissemination of hazardous weather information to pilots on frequency and should help many of you to provide a more professional and realistic service to pilots operating within our sector.

Further information on weather information can be found in Chapter 2, Section 6 of the 7110: http://www.faa.gov/air_traffic/publication...#atc0206.html.1.



Additions from other ZMP controllers:

MT: Good stuff AJ. I personally also add aviationweather.gov in my broadcasts. ie. "hazardous weather info ....... Available on HIWAS, flight service, aviationweather.gov or controller time permitting."


JM: I'll also add in the terminal setting, the hazardous weather information is usually disseminated on the ATIS as well.  The short broadcast, "Attention all aircraft, Hazardous weather information Convective Sigmet 22 Central for Wisconsin and Lake Michigan available on HIWAS, Flight Watch, and Flight Service frequencies" is usually sufficient.  If a pilot has a question about weather not in my area of jurisdiction, I will generally refer them to flight watch/flight service, but of course that is not possible on VATSIM.

Wouldn't it be cool if there was a Flight Service position that we could staff during certain times?


DK: For the sake of not confusing network pilots any more than some stuff already does, I usually drop the "HIWAS/FlighWatch/AFSS" bit and just say:

"Hazardous weather, Convective SIGMET XXC valid until XX55z for MN/IA/ND/SD, etc. available from Air Traffic Controller on request."

For you terminal guys, when you're recording the KMSP voice ATIS and a convective SIGMET or CWA coverage area falls within 50nm of KMSP, add the following into the voice ATIS immediately after approaches/runways in use:

"ATTN ALL ACFT: HAZARDOUS WX INFO FOR KMSP AREA AVAIL FROM ATC ON REQ" (Read as: "Attention all aircraft: Hazardous weather information for Minneapolis-St. Paul Airport Area available from Air Traffic Control on request.").

To each his/her own, though. I strongly encourage all the enroute guys to disseminate these advisories, workload permitting!




Other comments, contributions welcome! Hope this provides a bit of insight and assistance to the rest of VATUSA...

9
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]

10
General Discussion / ZMP's 168 Hour Push
« on: January 19, 2011, 09:06:13 AM »
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,

11
General Discussion / ACE Team Forum Access
« on: February 11, 2010, 12:03:45 AM »
I need to gain access to the ACE Team forum in order to view events that are posted. I know Matt (USA5) has been trying to help me with this issue, but it's still not displaying on my end. Any assistance appreciated.


Regards,

AJ

12
The Classroom (Controller Tips) / Recording ATIS
« on: January 12, 2010, 08:31:41 AM »
I seem to hear a lot of controllers throughout VATUSA record their ATIS' (ATII plural?  ) incorrectly and very little standardization seems to be implemented regarding what should be said and how it should be said. As a pilot, it kind of stings my ears (I guess you can call it a pet peeve) to hear some of the ways people say things and how much, what I would consider to be important information, they omit. I figured this would be a great place to post a guide I wrote for ZLA about 2 years ago to help standardize the way that these recordings should be made. The more standardized the recordings become, the easier it becomes for everyone (controllers and pilots) to learn from.

As a regular controller on VATSIM, I've noticed pilots, in general, fail to call with ATIS regularly and I believe that the inconsistency in these recordings throughout VATUSA and the failure of controllers emphasizing the importance of obtaining it, especially during large events and times when controllers are super busy, is contributing to this issue. Maybe this guide can be used in the VATUSA training material to help improve this in the future...

I've spent a lot of time listening to digital and manual recordings in my time as an air traffic CTI student and as a pilot, so I've tried to construct this guide keeping everything I've learned and studied in mind. This is a somewhat detailed article, but I try to walk you through it step by step in an easy to understand manner. Any additional information you guys discover or feel needs to be added, please do. My goal is for all of us to work together as a team to help... here's my input to get the ball rolling with it!

The direct link to this article can be found here: http://laartcc.org/article_page/28


[div align=\\\'center\\\']--------------------------------------------------------------------------------------------------------------------------[/div]


In an effort to assist those of you guys looking to record your ATIS with a bit of a more professional flavor, I'm going to include some tips for how to properly translate the METAR to voice format and make it sound a bit more realistic.

I had taken the time to write some detailed ATIS policies for airports in Chicago during my time there and have spent a considerable amount of time listening to actual ATIS recordings and reading up on how to properly record them.

This is just to help those of you guys out, like myself, who strive for that ultimate perfection while you control . I've tried to dumb this down a bit for VATSIM applicability - feel free to review the links I've posted to delve further in depth at your discretion!

Let's start by taking an example ATIS to work with:

KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003


First portion of the ATIS, a decoding of the METAR and how to pronounce the parts of the coding while recoding. I have broken this down into 12 parts to explain a bit about each.

   1. The beginning of your ATIS should begin with the official facility name of the airport you are working, followed by the current information code. KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003.

      For instance, with Los Angeles, it should read as follows:

      "Los Angeles International Airport information CHARLIE" - the full facility name can be found on the charts of the airport as well as in an airport facility directory or airnav.com (or some other airport information sites). Replace CHARLIE with the current ATIS code, whatever that may be, via stating the appropriate letter in the aviation phonetics format (ie: ALPHA, BRAVO, CHARLIE, DELTA, etc...). For the purpose of VATSIM, it does not make a difference what letter you begin on or when (when you log in to control) - just ensure you follow up with the next letter in alphabetical order for the next update.

   2. Include the time of the observation in zulu. KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003

      "one-seven-five-zero zulu" - 1750z - pronouncing each digit separately at the time of the observation. The date (in the example above 28 ) should not be recorded in the ATIS. A routine observation is the normal time the ATIS is updated (for LAX, this is 50 minutes after each hour). A special observation occurs during adverse weather conditions and may be updated a number of times between routine observations. This should be stated as such when applicable "XXXX zulu special".

   3. Wind direction comes next, gusts shall be reported after wind as “Gusts XX” when applicable (replacing XX with the gust in the METAR). KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003

      "wind two-three-zero at six" - Due to magnetic variation, here at ZLA we subtract ten degrees from the wind direction within the METAR to be more exact (as in this example). Note that there is only ONE wind. Stating "winds" is incorrect and a common mistake made by many. Gusts would be included right after the wind as "gusts XX" (not "gusting") replace XX with the Gust in the METAR where applicable (indicated by a G after the wind direction and speed).

   4. Visibility is next. KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003

      "Visibility one-zero" - Note this is ASSUMED to be in statute miles ALWAYS (SM) - no need to include "statute miles" in the recording itself. If visibility is listed as something like 1/4SM or 1 1/2SM it would be read, respectively as "visibility one-quarter" or "visibility one and one-half". If VVXXX (Vertical Visibility) is noted in the METAR, then “indefinite ceiling XXX” shall be included after the visibility is issued, replacing XXX with the height in feet. When the visibility is less than 7SM, included in the METAR will be the reason why (an obscuration) which should also be stated directly after the visibility in the ATIS (ie: "visibility five, mist"). There are many other factors for visibility beyond the scope of this discussion as well, but you can read up here on other types or reported visibility which can also be noted in the METAR here: http://www.met.tamu.edu/class/METAR/metar-pg7-vis.html

   5. Clouds are next. KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003

      "Two-five thousand scattered" - report as applicable beginning with the lowest cloud layer. Few cloud layers should be read as “few clouds at XXXX.” Scattered, broken, or overcast cloud layers should be read as “XXXX scattered/broken/overcast.” The lowest broken/overcast layer constitutes a ceiling and must be reported as such within the ATIS, “ceiling XXXX broken” or “ceiling XXXX overcast.” Replace XXXX with the altitude in thousands of feet (EX: three-thousand or six-thousand five-hundred). If CLR is noted within the METAR, then issue the cloud report as “Clear below 12,000” as this is the maximum height the weather equipment is considered to be valid at Los Angeles International Airport (this is noted by the type of weather reporting equipment at the end of the METAR).

   6. Temperature and dewpoint. KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003

      "Temperature three-three, Dewpoint Minus three" - Note, again, that the digits are pronounced individually, not as whole numbers. This is for the sake of clarity. If you note an M in front of something, that is pronounced as "Minus" such as in this example METAR report.

   7. Altimeter setting. KLAX 281750Z 24006KT 10SM SCT250 33/M03 A2995 RMK AO2 SLP141 T03281033 10339 20206 51003

      "Altimeter two-niner-niner-five" - As above, each number pronounced individually, without the decimal as it is a given.

   8. The next portion of the recording shall include the advertised instrument approach(s) in use at the airport. The following list is an example of how this may be recorded:

     "Simultaneous ILS approaches in progress to runways 25L and 24R"
      "ILS runway 9 approach in use"
      "Localizer and visual approach runway 27 in use"
      "V-O-R Alpha approach in use, circle to land runway 27"
      "RNAV runway 6R approach in use"


      Note that all runways shall be read out as individual numbers while recording (EX: 25L – Two-Five Left). Instrument approaches should always be listed prior to visual approaches in use - when applicable.

      Also, when applicable, LAHSO (Land and Hold Short Operations) shall be stated. "Land and hold short operations are in effect"

      Be sure to include the applicable LAHSO runways in use, stating the available landing distance for the LAHSO runway. (ie: "Runway 15 arrivals may be asked to hold short of runway 8 for landing traffic, available landing distance on runway 15 six-thousand, five-hundred feet"). The available landing distance is very important as the pilot needs to know the stopping distance he has and whether or not he/she can accept the restriction.

      Additionally - when applicable, include RVR (Runway Visibility Range - during low visibility operations - ie: fog/mist) and any braking action reports - although this should also be issued to the pilot from approach and the tower in the landing clearance.

   9. The departure and landing runways in use.

      "Departing runways 24L and 25R"
      "Landing and departing runway 27"


      Pretty self-explanatory - again, pronounce the runway numbers individually for clarity.

  10. NOTAMs (Noticed To AirMen) that may apply to your airport.

     "Notices to Airmen, runway 25L closed"
      "Airport closed to traffic pattern operations"
      "Parallel approaches in use between Los Angeles International Airport and Hawthorne Airport"

      Anything else you can think of that may apply to the airport you are working... these are just examples.

  11. The fifth section of the ATIS shall consist of the following to conclude the recording:

      "All departures contact [CURRENT CLEARANCE/DELIVERY POSITION AND FREQUENCY] prior to taxi" (or something to this tune so the pilot knows who to call for their clearance).

      "Read back all runway hold short instructions [and runway assignments]"

      "Advise controller on initial contact you have information [ATIS CODE]"
(or again, something close to this tune works fine).

      This way the pilot knows to call you with the information. (and gives you a reason to instruct the pilot to listen to the ATIS when they don't call with it).

  12. LASTLY (finally right?), and if you remember nothing else from this lengthy article, I ask you to PLEASE REMEMBER THIS PART!

      A pause must be included to clearly define the beginning and end of the ATIS for a period of three to five (3-5) seconds at the end of the recording to prevent an “endless recording” when pilots listen to the frequency (or what I like to refer to as the "endless ATIS recording of DEATH".


So, to sum up above, here is a typed version of what would be read for the ATIS recording on this METAR.

"Los Angeles International Airport information CHARLIE, one-seven-five-zero zulu observation, wind two-three-zero at six, visibility one-zero, two-five thousand scattered, temperature three-three, dew-point minus three, altimeter two-niner-niner-five, simultaneous I-L-S and visual approaches in progress to runways two-five left and two-four right, departing runways two-five right and two-four left, parallel approaches in use between Los Angeles International Airport and Hawthorne Airport, read back all runway hold short instructions and runway assignments, all departures contact Los Angeles Tower one-two-zero point niner-five prior to taxi, advise controller on initial contact you have information CHARLIE (pause for 3-5 seconds)”.

All can be read within a period of about 30-45 seconds on average!

I also took the liberty of creating an ATIS quick reference table:

ATIS QUICK REFERENCE TABLE

[OFFICIAL AIRPORT NAME] information [ATIS CODE]
(Time) - XXXXz observation/special
Wind - XXX@YY
Visibility - XX
(Sky Conditions) – XXX
Temperature – XX
Dewpoint – YY
Altimeter – XXXX
ILS/VIS runway XX approach in use [Simultaneous approaches/LAHSO operations] Departing runways YY.

[INSERT NOTAMS AS APPROPRIATE]
Read back all runway hold short instructions [and runway assignement]. All departures contact [CURRENT CLEARANC/DELIVERY POSITION AND FREQUENCY] prior to taxi.
Advise on initial contact you have information [ATIS CODE].



Keep in mind your ATIS must be in compliance with the VATSIM EC Global ATIS Policy in which it cannot exceed 1 minute in length (so, practice your recordings to get them done quickly!) and that the textual ATIS should still be in compliance with ZLA's policy found here: http://www.laartcc.org/operating_procedure...ontrollers+ATIS

I have received many wonderful comments from pilots on having a clean-cut and professional sounding ATIS and I wanted to provide this information that has helped me attain this to you all to help further advance the professionalism of ZLA.

Pages: [1]