![]() |
If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#25
|
|||
|
|||
![]()
"LWG" wrote in message
... Okay, here's my question. When I get FF on a long trip, often I get handed off from centers, approaches, etc. to my destination. I have been put "in the system" along the way. How do controllers do that so the handoff happens? Does the original entry into the system generate P strips along the route like an IFR flight? If so, how do they do it so that the flight is not IFR? Do they "force" the VFR aspect like this thread has been discussing? Is the handoff automatic, or does it get coordinated by land line, or both? But if the VFR friend requested FF, it would be "opened" and the controllers would have the strip all along the route, right? Years ago, when radar was steam powered and the tower's light guns burned whale oil, there were two semi-separate "flightplan" systems: ARTS which generated the datablocks on the radar indicator and FDEP (later called FDIO) which generated the paper flight progress strips. Separate because there were two different keyboards to enter data and two different formats for entering that data. Each controller had an ARTS keyboard at his position but in terminal facilities there were usually only one or two FDEP keyboards. These were located at the Flight Data or Clearance Delivery positions away from working sector controllers. Semi-separate because while the FDEP not only generated the paper strip it also generated a datablock with a center transponder code and sent everything to every facility along the aircraft's proposed route, the ARTS did not. ARTS datablocks used local codes and remained solely within the facility generating them. They were also much easier to create requiring less info and fewer keystrokes. So now the stage is set for a couple scenarios: Scenario 1. Mister VFR aircraft files a VFR flightplan into the IFR system which generates the strip and center code datablock in the originating and subsequent facilities' airspace. He then calls CD, gets the center code, tags up on departure, is handed off to each facility along his route, and receives FF all during his flight. Everybody's happy unless or until: -One or more of the facilities has inhibited the processing of VFR flight data -One controller is too busy to provide FF, terminates radar service and drops the datablock which removes it from the FDEP and therefore all the remaining facilities along the route -The next controller is too busy to accept the handoff and the track gets dropped (see above) -For some reason the aircraft doesn't immediately tag up so on initial contact the controller thinks it's a pop-up and enters the data into the ARTS. This either generates a series of computer input error messages for "dupe ID" (bad) or a local datablock on a local code (not too bad). Depending on how the controller decides to sort all this out the aircraft may stay in the system or it may get dropped Scenario 2a. Mister VFR airplane pops up on freq and requests FF (either initially or because he got dropped somewhere along the route). The controller enters the simple data in ARTS format into his readily available ARTS keyboard, issues the local transponder code, gets an ARTS generated datablock (which is all he needs to keep track of the airplane), and workload permitting, provides FF within his airspace. Easy. Scenario 2b. Mister VFR aircraft calls and in addition to the ARTS entries, the controller gets on the intercom to CD/FD to have that controller enter the more detailed info into the FDEP or if CD/FD's not staffed, gets up, goes to the FDEP keyboard, enters the info into the FDEP, waits for the center computer to generate the strip and datablock with the center code, issues the new code to the aircraft, waits for the new datablock to tag up, then provides FF within his airspace. A PITA. In Scenario 2a when the aircraft nears the limit of his airspace the controller terminates radar, drops the local datablock, and he's done. In Scenario 2b, the controller can start the automated handoff to center, wait for center to accept or refuse, transfer communications if accepted or terminate radar if refused, and then he's done. That's how it worked in the past. Maybe in the last few years or so the FAA has actually integrated the systems, streamlined the procedures, and hired a whole bunch of controllers who really like to do a bunch of extra work for VFR aircraft. Sure they have. |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
AOPA Stall/Spin Study -- Stowell's Review (8,000 words) | Rich Stowell | Aerobatics | 28 | January 2nd 09 02:26 PM |
IFR use of handheld GPS | [email protected] | Instrument Flight Rules | 251 | May 19th 06 02:04 PM |
I want to build the most EVIL plane EVER !!! | Eliot Coweye | Home Built | 237 | February 13th 06 03:55 AM |
ramifications of new TSA rules on all non-US and US citizen pilots | paul k. sanchez | Piloting | 19 | September 27th 04 11:49 PM |
PC flight simulators | Bjørnar Bolsøy | Military Aviation | 178 | December 14th 03 12:14 PM |