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 |
#41
|
|||
|
|||
Stan Prevost wrote: I don't understand. Your prior discussion was in the context of a terminal controller and center approach control, I thought. That's why I was trying to clarify that it applied to a towered field using center approach control. It's affects any computer not located at a center. It does not matter what service a center provides or doesn't provide. Can the terminal controller suspend auto-acquire? Yes but this isn't ever done because I don't know when you are going to make your request. It might be 20 miles after takeoff. |
#42
|
|||
|
|||
"Newps" wrote in message ... Stan Prevost wrote: Yes, I know, but when I have been given an instruction to advise of altitude changes, and then when I advise of an altitude change and am told to remain at my present altitude and he will give me lower in a few miles, my choices are limited. My first choice will be to then ask why or play chicken on the air and say "I'm descending to maintain VFR." He can't deny that. Assuming you're not real close to a terminal area and sequencing becomes an issue the controller shouldn't be stopping you from changing altitudes. I was approaching the terminal area, IND, from the north. |
#43
|
|||
|
|||
"Stan Prevost" wrote in message ... I don't understand. Your prior discussion was in the context of a terminal controller and center approach control, I thought. That's why I was trying to clarify that it applied to a towered field using center approach control. I believe you're thinking of terminal controllers as strictly tower controllers. Terminal controllers are those working in control towers and approach control facilities. What exactly were you asking when you wrote, "So this becomes an issue only at a towered field using center approach control services?" I took it to mean the auto-acquire of tracks by ARTCCs. Tracks auto-acquire wherever they happen to be if they're observed by center secondary radar when beginning their flight. Can the terminal controller suspend auto-acquire? Can the terminal controller suspend the auto-acquire of targets by the center? No, of course not. If there is not a terminal controller, does center suspend auto-acquire? No, there'd be no reason to in that case. Is suspending auto-acquire done on a per-acft basis? No, it's done center-wide. |
#44
|
|||
|
|||
"Newps" wrote in message ... No it's an issue for any TRACON. No, it's only an issue for TRACONs hosted by centers that use auto-acquire. |
#45
|
|||
|
|||
"Steven P. McNicoll" wrote in message link.net... "Stan Prevost" wrote in message ... I don't understand. Your prior discussion was in the context of a terminal controller and center approach control, I thought. That's why I was trying to clarify that it applied to a towered field using center approach control. I believe you're thinking of terminal controllers as strictly tower controllers. Terminal controllers are those working in control towers and approach control facilities. That's how I normally think of terminal controllers. But I thought you had excluded the approach control facilities when you used the context of fields using center approach control. Do you call center controllers "terminal controllers" when they are working approach control? That could be what I missed. What exactly were you asking when you wrote, "So this becomes an issue only at a towered field using center approach control services?" I took it to mean the auto-acquire of tracks by ARTCCs. Tracks auto-acquire wherever they happen to be if they're observed by center secondary radar when beginning their flight. I no longer think I understand anything about this discussion of under what circumstances a controller can change a flight plan. I need to find a new starting point, or just abandon it. It seems to be an obscure issue for pilots, I was just curious when it came up. Thanks. |
#46
|
|||
|
|||
"Stan Prevost" wrote in message ... That's how I normally think of terminal controllers. But I thought you had excluded the approach control facilities when you used the context of fields using center approach control. I didn't use that context. This has nothing to do with flights that originate in center airspace. The problem is with flights that originate in approach airspace where center gets an auto-acquire on the aircraft. When center gets the auto-acquire approach is locked out of any further flight data processing on that flight. Do you call center controllers "terminal controllers" when they are working approach control? That could be what I missed. No. |
#47
|
|||
|
|||
Steve,
I thought that for /G there still needed to be a vor or other nav fix in the route. I generally draw a line between the start AP and the destination and then add a vor in the middle that doesn't increase the distance by much. Gices me two nav checks for redundancy, too. Are you saying that /g can be diredt between APs over several hundred miles with no other fixs? Chuck |
#48
|
|||
|
|||
"Chuck" wrote in message oups.com... I thought that for /G there still needed to be a vor or other nav fix in the route. I generally draw a line between the start AP and the destination and then add a vor in the middle that doesn't increase the distance by much. Gices me two nav checks for redundancy, too. Are you saying that /g can be diredt between APs over several hundred miles with no other fixs? You don't even have to be /G. IFR flight off-airways and beyond normal navaid distance/altitude limits just requires radar monitoring by ATC. Now, if you're going to a rather small airport hundreds of miles away there may be a flight data processing problem. The NAS computer serving the departure airport may not know where the destination airport is. You can get around that by filing a few waypoints based on H-class VORs that fall on your route, that will also help ATC visualize the route. Or you can just file the destination coordinates as an intermediate fix. |
#49
|
|||
|
|||
"Steven P. McNicoll" wrote in message =
link.net... =20 "Chuck" wrote in message oups.com... I thought that for /G there still needed to be a vor or other nav fix in the route. I generally draw a line between the start AP and the destination and then add a vor in the middle that doesn't increase = the distance by much. Gices me two nav checks for redundancy, too. Are you saying that /g can be diredt between APs over several hundred = miles with no other fixs? =20 You don't even have to be /G. IFR flight off-airways and beyond = normal=20 navaid distance/altitude limits just requires radar monitoring by ATC. = Now,=20 if you're going to a rather small airport hundreds of miles away there = may=20 be a flight data processing problem. The NAS computer serving the = departure=20 airport may not know where the destination airport is. You can get = around=20 that by filing a few waypoints based on H-class VORs that fall on your = route, that will also help ATC visualize the route. Or you can just = file=20 the destination coordinates as an intermediate fix.=20 Sometimes, but not always, when I file direct to a distant point, even an H-class VOR, I'll be cleared first to a nearby fix, then as = filed. I usually make a note of that nearby fix, and include it in subsequent = trips. I figure the departure controllers prefer that, and it's OK by me. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Duat Graphics | Slick | Piloting | 0 | January 23rd 05 01:35 PM |
NAS and associated computer system | Newps | Instrument Flight Rules | 8 | August 12th 04 05:12 AM |
DTC DUAT | Matt Whiting | Instrument Flight Rules | 0 | June 5th 04 03:23 PM |
Picking Optimal Altitudes | O. Sami Saydjari | Instrument Flight Rules | 20 | January 8th 04 02:59 PM |