Standard Operating Procedures and Letters of Agreement

Radar Client Procedures

Date	Code	Version	Contact
2011-05-06	SOP-020	2.10	Facility Advisory Board (FAB)

PURPOSE:

This Standard Operating Procedure (SOP) provides specific procedures to be used with the radar client software program. There are two alternative radar client programs used by most controllers, ASRC and VRC. The ZOA staff recommends that new students use the VRC client, since is easier to learn for most people, has some useful features that ASRC does not, and is more actively updated by the software's author.

The remaining content of this SOP will reference the general term "radar client." However there will be an assumption here that most students and new controllers will be using the VRC client. Some of the procedures and techniques will be described that are specific to VRC, so in using ASRC or another radar client, some of the features may not be available or may not work the same way.

ROLES AND RESPONSIBILITIES:

The Office of Primary Responsibility (OPR) for this SOP is the ZOA Facility Advisory Board. This SOP shall be maintained, revised, updated or cancelled by the ZOA Facility Advisory Board. Any suggestions for modification / amendment to this SOP should be sent to the FAB for review.

DISTRIBUTION:

This SOP is to be read and applied by all ZOA controllers using the radar client software.

BACKGROUND:

This SOP outlines procedures to ensure consistent use of the radar client to pass information between controllers.

PROCEDURES:
1. Target visibility range.
  
  Generally it is best to use the least amount of target visibility range required to work the ATC position being staffed.
  1. The following maximum target visibility ranges are permitted when connected to the VATSIM network as a controller:
    - Center (CTR) - 600 NM
    - Approach (APP) - 150 NM
    - Departure (DEP) - 150 NM
    - Tower (TWR) - 50 NM
    - Ground Control (GND) - 20 NM
    - Clearance Delivery (DEL) - 20 NM
  2. The following maximum target visibility ranges are permitted when connected to the VATSIM network as an Observer:
    - Observer (OBS) - 300 NM
2. Position File.
  
  Controllers will ensure that they have downloaded and installed the current radar client position file (".pof" file) for ZOA ARTCC as published on the ZOA ARTCC Web Site.
3. Beacon Code Assignment.
  1. Beacon codes will be assigned only by standard positions listed in (2) below. Valid beacon code ranges are defined by the position file. This will ensure beacon code ranges are chosen from the appropriate position when using the F9 function key (or the "Assign Squawk" button in the Flight Plan window) to assign a code.
  2. Standard positions encoded in the position file are all center, TRACON, and primary airport tower, ground, and delivery positions. Only these positions may assign unique beacon codes.
4. Temporary Altitude Field.
  1. The temporary altitude field shall be used by controllers to communicate altitude assignments for the following situations only. The temporary altitude is specified in hundreds of feet: e.g. "100" = 10,000 ft.
    - ALL aircraft descending for arrival to destination airport. Set the temporary altitude field to the descent LIMIT given to the pilot. Leave the temporary altitude setting in place for hand-off to the next approach controller, unless the aircraft has been cleared for the approach.
    - Any non-standard altitude assignment given during the climb: i.e., NOT the standard initial climb altitude, NOT the controller's airspace ceiling, and NOT the final cruise altitude. When an aircraft is climbing normally in accordance with SOP, the temporary altitude field shall not be used.
    - Any other temporary altitude assignments that deviate from the associated sector SOP for climb or cruise, such as for traffic separation.
  2. For arrivals, once an aircraft is cleared for the approach, the temporary altitude field shall be cleared prior to handoff to TWR, landing clearance, or termination of radar service.
  3. For all other aircraft, Once the aircraft is cleared to resume normal altitude, the temporary altitude field shall be cleared prior to hand-off.
5. Flight Plans and Amendments.
  1. The flight plan will be amended by the controller to reflect the initial cleared route, cruise altitude, and any amendments made thereafter.
  2. While the aircraft is enroute, controllers will amend flight plans as needed to reflect new routing based on SOP or flow control requirements, e.g., new clearance routing via STAR.
  3. Pilots will not be required by controllers to modify and re-send flight plans based on amended clearances or other changes.
6. Flight Strips.
  1. Use of flight strips and the "flight strip bay" in the radar client is generally optional. Some controllers may wish to use this feature, while others may not. However ZOA controllers are encouraged to assist other controllers by "pushing" the flight strips with all hand-offs, if they request it.
  2. Flight strip annotations (the nine small boxes on the right end of the strip) may be used by controllers to enter small bits of text as personal reminders, such as the assigned departure runway. Flight strip annotations should not be relied upon to communicate information to other controllers. See Scratch Pad Field below.
7. Communications Indicator.
  
  Controllers shall ensure aircraft are properly tagged with the appropriate communications indicator ("v", "r", "t") using the F9 function key, or by directly editing the flight plan remarks to include the string "/v/", "/r/", or "/t/".
8. Scratch Pad Field.
  
  The scratch pad field is used by the controller to note or communicate any additional information not already covered by the items above. The scratch pad field may sometimes be used as an optional place where the controller temporarily make his or her own notation. More often however the scratch pad field MUST be used to pass important information about the aircraft to the subsequent controller(s).
  1. Personal Messages. The scratch pad field may be used by controllers as a reminder to themselves of unique requests, routing or vectoring clearances. When used this way the field shall be cleared prior to hand-off.
  2. Standard Optional Messages. The scratch pad field may optionally be coded to indicate the following conditions to adjacent facilities. These messages shall be cleared prior to hand-off to another controller.
    - PTN = VFR aircraft is in closed traffic pattern.
    - GA = aircraft has declared go-around (will remain in pattern).
    - SUA = aircraft is operating within scheduled special use airspace.
  3. Required Coordinating Messages. The scratch pad field shall be coded during time of handoff to indicate the following inter-facility coordination messages. These messages are left in place for hand-off.
    - [VOR-ID] = aircraft is proceeding direct to [VOR] and requires further instructions / vectors on course.
    - [FIX-ID] = aircraft is proceeding direct to [FIX] and requires further instructions / vectors on course.
    - Hxx = aircraft is proceeding on heading xx0 (where xx = heading in 10x degrees, e.g. H34 = Heading 340).
    - ILS approach: aircraft is assigned / is expecting the ILS approach noted. Notation is "iRRR" where RRR is the runway id. For example, "i28R" or "i29".
    - Charted visual approach: aircraft is assigned / is expecting the charted visual approach procedure noted. For example, "qbr" or "tipp" for Quiet Bridge Visual, or Tipp Toe Visual.
    - Normal visual approach: aircraft is assigned / is expecting visual approach as noted. For airports with a single runway in use for landing, use "vis". For airports with parallel runways in use, use "left" or "rgt" to indicate the runway for visual approach. Optionally can use the notation "vRRR" such as "v28L".
    - Other instrument approaches. As appropriate, use abbreviations for other published IFR approaches such as "vorA", "LDA", etc.