DUAT

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.

"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.

"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.

"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.

"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.

"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.

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

"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.

"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.