vZTL - Atlanta Center - Lesson 3

This session is estimated to take roughly 90 minutes. Probably closer to 2 hours if we're being real.

STANDARDS TO ACHIEVE / Introduction to En-Route:

  1. Explain the role of an en-route controller - This item was covered in Lesson 2.
  2. Identify and ensure en-route separation - This item was covered in Lesson 2.
  3. Ensure positive separation is maintained - Guess what. Lol. → Lesson 2
  4. Transfer communication in a timely manner using prescribed phraseology - ROFLCOPTER Lesson 2
  5. Issue hazardous weather information utilizing prescribed phraseology

Holy shit… finally, something NEW! Weather. It's a phenomenon that we always experience, even when its as “boring” as CAVOK 1).
Weather presents a variety of challenges in the en-route environment for a variety of reasons. First and foremost, for all the advances that we've made in the field of meteorology 2), weather is still a highly volatile and unpredictable field. Airplanes will request to deviate around absolutely nothing, because they see something you can't/don't/wont! Weather radar provides only one glimpse into the atmospheric conditions 3), but it doesn’t always tell us what the fluid of air that makes up our atmosphere is doing.

You gotta learn your clouds, son, doesn’t just make for good TV - it’s good practical practice, as well. What clouds are doing is an excellent indicator of the conditions of a parcel 4) in live time. Towering Cumulonimbus clouds are a warning sign of bumpy atmospheric conditions now and potentially devastating weather impacts later.



The Pilot's Handbook of Aeronautical Knowledge gives excellent insight into what the cross section of what Towering Cumulonimbus clouds tend to build up to.

Note the red arrows indicating the movement of air upwards5) and the blue arrows denoting the movement of air downwards6).

I wrote a whole bunch of shit but it got deleted. I have this video still in my browser, though…


7)

So, from scratch we go: The 2nd and 3rd panels of the image above denote what would be displayed on your radar. Unfortunately, there is a significant delay between the event happening & it being depicted on your radar, as the process of scanning the atmosphere (both horizontally AND vertically), and compiling all the layers of data, takes a significant amount of time (upwards of 10-ish minutes). Airborne wx radar8) is usually faster at compiling weather radar, but is not as powerful and is also susceptible to errors.

Here's what the weather should look like on your end:

The left poster depicts precipitation in the Standard Terminal Automation Replacement System. On the right, although slightly obscured, is the weather depiction on the En-Route Automation Modernization program.

For VATSIM purposes, the STARS weather radar display is out of service. I don't know why the vERAM weather is different but here's what vERAM depicts:

IN ORDER: MODERATE .. HEAVY .. EXTREME..

Let's take a look at calling weather to aircraft. It's similar to calling traffic:
First and foremost, the most important aspect of any transmission, is to ensure that the message is understood. For that purpose, we start with prescribed phraseology, and then may use plain-speech English or other methods of elaborating on the content.
The .65 states that you9) must issue “pertinent information on observed/reported weather”.
Let's start with the prescribed phraseology that should be somewhat familiar to you… weather in the form of a “traffic” call.
Area of <intensity> precipitation, between <left> o'clock and <right> o'clock, <distance> miles, moving <direction> at <number> knots, tops <altitude>. Area is <number> of miles in diameter.
You can omit stuff you don't know. I have never, ever, issued the “direction and velocity” of a storm cell. So really, when you water it down10), you'll end up with something like:
Area of <intensity> precipitation, between <left> o'clock and <right> o'clock, <distance> miles. Area is <number> of miles in diameter.11)
Usually useful for describing single cells. Great. Uno problemo.

  Hazardous Weather doesn't always present itself as a single cell. Hell I'ma do then?

Well, you can also describe the weather terms of the general width of the area/area of coverage in terms of fixes or distance and direction of fixes. It'll sound something like
Weather area from <fix/number of miles & direction from fix> to <fix/number of miles & direction from fix>. You'll also find the term “along your route of flight” to be a very, very useful phrase when it comes to disseminating weather to aircrews flying ALONG a fucking squall line.

Example:

N7835U, Area of Heavy to Extreme Precipitation, from your one o'clock to your four o'clock,

UAL1972, areas of moderate to heavy precipitation, along your route of flight from your present position until the Charlotte Airport.
You'll notice in that second image, the scratchpad includes some funky shit. I guess there's no time like the present.

Airplanes (real world: never, network: sometimes don't) want to fly through areas of moderate (or heavier) precipitation. Sometimes, you'll be able to issue a heading (or a weather avoidance route) to avoid most storm problems. Othertimes, it'll be easier to let flight crews find holes through the system on their own.

Weather deviations can be initiated by you (the controller), or the pilot.
UAL1972, Deviations right of course approved, when able, proceed direct JONZE. or, perhaps,
UAL1972, deviation south approved, when able, fly heading 070, vector to rejoin the arrival, and advise.
The deviation can be watered down, as simple as, deviation approved, and built on from there. The good book wants us to have aircraft advise clear of weather whenever we can't issue an instruction to rejoin the route12). If you don't want to give a pilot the deviation they requested, you can alternatively say something along the lines of unable requested deviation, fly heading <wutevaaa>, advise clear of weather.

Regardless, one integral rule of working center is that the datablock or flight plan needs to reflect what the airplane is doing. Heading? In the datablock. Speed? In the datablock. Assigned Altitude? In the datablock*13). Deviations, would naturally, need to be in the datablock.
So the fourth line entry for deviations start with D…….. and then, we go from there. I'm sure you can guess what the D is for.
After the D comes the restriction… if we're telling someone deviation north approved, we would append “N” after the D… so the 4th line on the datablock would read DN, meaning deviation north. D20R would indicate that the aircraft is Deviating 20 degrees Right.

  Well, in some of our previous examples, we gave the aircraft instructions to rejoin the route. 
  Sometimes, planes wont be able to rejoin the route. So... surely there must be a way to differentiate that, right?

Correct. The syntax for the entry gets longer the more time we talk on frequency. So D20L means the aircraft was only instructed to deviate 20 degrees to the left. That's it. No instructions to resume the filed route or go direct some waypoint down yonder.
Soooooooo D20R/JONZE would indicate that an aircraft is deviating 20R, and will go direct JONZE whenever they're clear of the weather. If they're going to return to the next waypoint in their filed route, we'd put /F.
Unfortunately, headings out of weather deviations have to be manually coordinated (as does anything else that doesn't fit in the 4th line). When manually coordinating, make sure you let the receiving guy know who requested what.
DAL1234 assigned heading 3-0-0 for wx avoidance.
N1674V, deviating west, pilot requested..

  Why tho.

Well, we don't really want to mess with pilot's that are self deviating for weather if we don't have to (if you're tryna be nice or whatever). We do want to correct controller issued headings that point aircraft into precip.

STANDARDS TO ACHIEVE / Altitude Changes:
1. Define and compute basic descent math to ensure aircraft meet crossing restrictions - We're back to this shit, eh? Lol. Done deal. ctr2

STANDARDS TO ACHIEVE / En-Route Control:
1. Utilize prescribed phraseology to alert crossing traffic of each other
Okay that's kinda adifferent… so this is getting at merging target procedures. Remember those from your S3 days?
The easy part is that if we have two targets that are going to be separated by only the minimum vertical separation14), we need to advise both targets with enough time that they can request a vector to “miss” the other airplane.
Instead of making two separate traffic calls, you can actually simplify it in some cases. For example,

OBJECTIVES TO ACHIEVE: For the session to be marked complete, the student must have successfully: Vectored and/or issued speed instructions to aircraft to meet Miles-In-Trail (MIT) requirements. Identified and ensured LOA items were followed and met. Issued a hazardous weather information call using prescribed phraseology Issued and terminated holding instructions

1)
Ceiling And Visibility OK, as ICAO calls it
2)
including Weather Surveillence Radar-1988Doppler and whatever other shit you can find
3)
primarily the movement of precipitation, in whatever form it may be - be it water/rain, snow, bugs/birds, or at some points, debris! The RADAR becomes more sensitive & thorough based on the “mode” that it is in
4)
that’s what we call a chunk of airspace that we’re evaluating
5)
updrafts
6)
downdrafts
7)
Click here for more resources about the PILOT side of weather avoidance.
8)
the shit that airliners use to draw weather displays
9)
not me
10)
pun intended
11)
LOL you MIGHT issue the diameter
12)
due to traffic, airspace, etc
13)
unless otherwise authorized by SOP/LOA
14)
i.e. horizontal is less than 5 miles, except where 3 miles is authorized…