Here are some friendly tips to make you a better controller on the network!

Brandon Barrett

  • VATUSA Staff
  • 140
    • View Profile
Some controllers create bad habits and don't even realize it! It could be phraseology or vectoring an aircraft and clearing them for an approach. I mean your not going to get the death penalty however for me I try to use  and simulate the real world procedures  as much as possible while also helping the pilot understand what I'm talking about.

Here are a couple tips I found typed up by a real world controller and his views on what he saw different with VATSIM ATC and real world ATC. Keep in mind we're not all perfect. I screw up the simplest procedures sometimes.
...................................................................


1:
Remember that a transponder is not required for radar identification. In the RW most towers provide a “roll check” that allows the departure controller to radar identify the aircraft as long as he is observed on the departure end of the appropriate runway, transponder or not. Meaning that if an aircraft checks on climbing, no need to make him level off just to turn his transponder on. Instead say “radar contact, climb and maintain… , squawk normal”. We may or may not be doing roll checks on the network, but we are simulating that we do them.

2:
The use of MARSA is not required between aircraft joining up as a flight, only concurrence from both aircraft.

3:
Coordination is minimized in the real-world. Traffic is so light on the network that it is difficult to establish routines or common traffic patterns, but I hear VATSIM controllers coordinating every airplane, or saying “coming to you”. He knows he’s coming because he took the handoff, and he knows the pilot is on his frequency when he checks on his frequency. If an aircraft doesn’t check on prior to entering your airspace simply call the sending controller, “Try switching that American again.” Bad habits of over-coordinating seem harmless until an event, then the workload for 5 airplanes gets overwhelming when the airspace could handle 25 airplanes. It reduces capacity and efficiency and snowballs into chaos as we have all seen.

4:
No need to tell an aircraft to hold short of the runway that he has been instructed to taxi to. RW aircraft switch to tower on their own. Also, no need to make an aircraft stop at the hold short line, clear him for takeoff before he gets there. RW turbojets are expected to be ready upon reaching the runway. They just get a “cleared for takeoff” without having to call the tower. If they’re not ready, then they’ll tell you.

5:
If an aircraft is conducting practice approaches and intending to make a planned missed approach always issue climb out instructions. “Climb out instructions, turn left heading 270, maintain 2K.” or “Climb out instructions are as published.” Don’t forget to coordinate that with the tower controller if online.

6:
VFR aircraft are not altitude restricted unless required for traffic. VFR departures are usually assigned altitudes by Clearance Delivery according to local procedures, but they usually coincide with the altitude assignments given to the IFR aircraft. “N123AB, cleared out of New Orleans Bravo airspace, maintain 4K, expect 8,500 10 minutes after departure…” This has to do with departure control knowing what airspace to protect for departures blasting off of the airport, IFR & VFR alike.

7:
When vectoring an aircraft to an instrument final approach course aim his base leg at 5 miles outside the FAF. I see 15 and 20-mile finals on VATSIM all the time. It is a disservice to the pilot, is unrealistic, and backs up the traffic. Again, a bad habit that reveals itself during busier periods.

8:
All Class B and Class C have radar separation requirements, therefore all VFR departures are assigned a squawk code and switched to departure, radar identified, then sent on their way. I recommend avoiding the question “are you requesting flight following?” because they must have it initially. If they wish to terminate at any time, they will advise, no need for the question. Class D can be different. “Cleared for takeoff” then “frequency change approved” is the minimum required. Likewise, a VFR aircraft entering a Class B or C should be radar identified and sequenced to the primary airport along with other aircraft. This means vectoring them if required. Just as IFR aircraft must be cleared for some type of approach, VFRs must be told “make straight-in RWY 13”, “enter right base RWY 13” etc by the radar controller, not the tower controller. Class D VFRs don’t require separation or sequencing by radar, this is accomplished by the tower controller. An airborne aircraft should not be cleared into a Class B airspace until radar identified, but I have heard this fudged both on the network and RW.

9:
If an aircraft calls the field in sight, he wants a visual approach, no need to ask. Also, vectors to a visual approach are overdone on the network. Just have the aircraft direct to the airport or the final approach fix. If on a vector then a slight vector to a 5-mile final is plenty. He can be cleared from anywhere, he does not need to be lined up with the runway.

10:
Coordination can accomplish anything. “Cross Runway 12L until advised” etc.

11:
Low and high center sectors are most commonly split FL230/240. The method used is for the high “descend and maintain FL240” or pilot’s discretion to FL240, hand off, then the lower crossing restriction is issued by the low sector. This does not apply to STARs with “descend via” clearances.

12:
Be friendly to newbies. They’re nervous and scared often times. A green newbie can very quickly turn into an avid and experienced FS user. We need all the pilots we can get on the network. Be friendly and offer assistance. I have personally seen this result in repeated future visits by that pilot. The welcoming attitude goes a long way to provide traffic in the future. As I type this I am working a VFR text-only newbie pilot into KGTU. He is obviously grateful for the friendly and patient service. He writes “Hope to be around often now that I’ve discovered this awesome vatsim world. Again, thanks for your help!”

13:
I hear overuse of “report midfield downwind” and other similar instructions to report. This should be used only on occasion if a controller thinks he’ll need a memory jogger for some reason. It is least needed if traffic is light. You “see” the airplane is on a downwind. We constantly train RW new controllers to look out of the window and retain control and situational awareness of where all of your airplanes are. It is bad form to not know. That being said, if you want the report or need the report, then by all means use it.
« Last Edit: February 19, 2014, 03:10:27 PM by Brandon Barrett »

Brad Littlejohn

  • Members
  • 154
    • View Profile
Here are some friendly tips to make you a better controller on the network!
« Reply #1 on: February 19, 2014, 05:31:14 PM »

Couple of nits to pick here.

#4: LUAW procedures, do to say, converging runway operations being in effect? For example, an aircraft may be ready at, say, runway 27 at KMCI, while simultaneous arrivals are happening on the 19s there. Just because the pilot is ready doesn't mean that the situation doesn't require better separation. If a pair of pilots are on a 3nm final for the 19s, you are either issuing LUAW to the pilot on 27, or issuing an immediate takeoff clearance for them to beat having a controller error. However, I will agree that telling them to hold short of their assigned departure runway is redundant when taxiing outbound for departure.

#9: The pilot may have the field in sight, but what if there is traffic to follow? For example, traffic off the downwind that they need to reduce their speed for to keep legal separation?

#7: Again, see traffic to follow. Sometimes having that 15 - 20 mile final helps to be able to slow traffic up to squeeze in a pilot coming off the downwind.

Most of these are fine, especially if traffic is light. But if traffic gets heavy, some of these may become a problem, especially when it comes to separation and traffic joining final.

BL.

Ryan Geckler

  • Mentors
  • 453
    • View Profile
Here are some friendly tips to make you a better controller on the network!
« Reply #2 on: February 20, 2014, 09:02:58 AM »
#1 - Still need to verify the altitude (provided the transponder is capable of it)... "radar contact, squawk normal, say altitude".

#4 - Brad's brought up most of the points I would have made. While in slow operations this practice is fine, put any sort of traffic into that and it really doesn't apply.

#5 - Phraseology is more like "Upon completion of the approach, xxxxxxx"

#7 - Make sure that you can still vector the aircraft onto the approach at least 2 miles outside the approach gate. (5-9-1)

#9 - For airports with parallel runways running multiple visual approaches, you need to vector the aircraft to join a visual final approach. (7-4)

#11 - I wish ours were. ZDC's got some really wack splits (SFC-FL270/FL280-FL300/FL310-FL600).

#13 - I do it so I don't forget. Not a horrible memory aid to have.

Marvin Palmer

  • Members
  • 23
    • View Profile
Here are some friendly tips to make you a better controller on the network!
« Reply #3 on: February 25, 2014, 12:13:20 PM »
Brandon, that is what seems to be the response from R/W controllers that compare real to virtual. Great post to have!

Most of the time, it's just good to communicate to the pilot/controller. You can also tell the level of experience (either pilot or controller) when you talk...so you can abbreviate as needed. But you always run into people still learning the trade, and so over-use or lack of...proper phraseiology will be prevailant.

Mark Taylor

  • Members
  • 4
    • View Profile
Here are some friendly tips to make you a better controller on the network!
« Reply #4 on: February 26, 2014, 10:51:11 AM »
Quote from: Ryan Geckler
#1 - Still need to verify the altitude (provided the transponder is capable of it)... "radar contact, squawk normal, say altitude".

This is one of my pet peeves. It is the responsibility of the controller to be sure that his display is accurately representing the actual altitude of the aircraft, but it is the pilots responsibility to report his altitude on his initial call. There should be no reason the controller needs to ask if the pilot checks in correctly.


Ryan Geckler

  • Mentors
  • 453
    • View Profile
Here are some friendly tips to make you a better controller on the network!
« Reply #5 on: February 27, 2014, 10:32:08 AM »
Quote from: Mark Taylor ZHU
This is one of my pet peeves. It is the responsibility of the controller to be sure that his display is accurately representing the actual altitude of the aircraft, but it is the pilots responsibility to report his altitude on his initial call. There should be no reason the controller needs to ask if the pilot checks in correctly.

Yes, its the pilot's responsibility, but its so uncommon on the network for it to happen when working a combined position.