A aviation & planes forum. AviationBanter

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.

Go Back   Home » AviationBanter forum » rec.aviation newsgroups » Instrument Flight Rules
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

NAS and associated computer system



 
 
Thread Tools Display Modes
  #1  
Old August 8th 04, 03:54 PM
Newps
external usenet poster
 
Posts: n/a
Default NAS and associated computer system



Snowbird wrote:



What can happen -- what's happened to us -- is that the tower
controller doesn't worry his head about your flight plan.


Yes, but it has to be typed in and accpeted by the computer. At all the
class C airspaces all the controllers work all the positions at various
times thru the day. You don't drop a handwritten strip down the tube
and expect the radar controller to handle it.


He
figures the tracon's gonna vector you and the center's gonna
reroute you anyway so why should he sweat. He says "cleared
as filed".


The tower guy says cleared as filed if the strip tells him to say
cleared as filed.


Now you're handed off to Tracon, and he looks at
your flight plan and realizes he has no clue where you're going.


Have that happen a lot. And the location identifier book is all the way
over there. So you say resume own nav and see where he goes. If I want
to nail it down to 50% of the sky I'll look at the final altitude and
see which way he's going.


But he figures you'll be out of his airspace before he sorts
it out, so let the center controller sweat it. He queries,
"Grumman 12345, say on-course heading", you respond, and
that's sufficient for him. 10 minutes later, you're handed
off to Center.


Yep, do that too if you're a slow mover and there's traffic.



Well, the next Center isn't going to be fobbed off with
"on-course heading blahblahblah" on the handoff, so the buck
stops with the first Center guy (this is our experience, mind,
YMMV).


The center has the same route on his strip as I have on mine. He will
move you for traffic, not because he doesn't know where you're going.

So if Newps
(sorry
to pick on him) transposes two numbers and has you headed in the
opposite
direction than you intend to fly, no one will know until you take off
from a non-towered airport headed west with the controller having
carefully
arranged your separation believing you're headed eastbound.


No controller looks at a set of lat/lons and says to himself..."Flying
east today." A lat/lon is for the computers benefit, it has zero value
to a controller.

Ads
  #2  
Old August 9th 04, 10:43 PM
Stan Prevost
external usenet poster
 
Posts: n/a
Default


"Snowbird" wrote in message
m...
"Stan Prevost" wrote in message

...


I did not intend to assert that only H-class VORs are likely to be
recognized nationwide -- that's not true. It seems to vary from
center to center. Any VOR on an airway is a fairly good bet some
places.


big snip

OK, I see that I interpreted your comments about H-class VORs too broadly,
and I now understand your meaning better.



It would seem
logical to me (for whatever that has to do with anything) that any VOR

used
to *define* airways, low- or high-altitude, would be recognized by any
computer that has anything to do with flights on the airway structures

of
the National Airspace System.


My husband would say something like "Stan, this is the federal
government.
You're expecting it to be logical. There's your mistake. There's
where
you're going wrong". (since he rassles federal regs for a living, he
has a right to an opinion).


:-) Yep, but you will notice that my parenthetical remark disclaimed the
application of logic to a gov't system.


What I *think* is going on, though, is that the airway itself is
understood
by the computer, but the specific navaids which define it in, say,
ZKC airspace, might be unknown to the computers in Miami Center. So
if
you route by airways, you're gold, but if you pick a non-H class VOR
two centers away as one of the few waypoints defining a direct route,
it might not be recognized even if it's on an airway.

I await further enlightenment on this point.


Me too!

The first thing is to understand the controller's needs for route
definition, specifically for a direct flight for this discussion. One might
expect that the controller would be concerned only with the route through
his airspace, so he couldn't care less about the route definition way down
the line. Does he need to be able to make my course line appear on his
radar scope all the way through his airspace? Or does he just need a
short-term projection of my track using radar for present position,
direction, and speed? Probably one need is to be prepared to handle radar
failure. In nonradar procedures, I think they try to move us all onto
airways, and to do this, the panicked controller needs to know which airways
to move us onto that keep us going in the proper general direction and out
of his airspace (or maybe the computers suggest new airway routing). So how
does knowing one VOR-based fix in his airspace do that? Does he have his
computer draw a line on his scope from present position through the fix, so
that he can then pick airways that approximate that route?

The next thing is to understand what the ATC computers are capable of and
how much variation there is among them, in terms of storage/knowledge of
fixes.

But eventually, no matter how well we understand those things, we will come
back to the old oft-debated issue of no matter what you file, you will get
something different or will get major reroutes, so you might as well file
direct airport to airport. I am sure this is more true in some areas than
others, based on my own experience, and for frequently-flown routes, one can
eventually learn reliable routing. Up through the northeast corridor, I
always get reroutes. In the east-central US, I can file from Alabama to
northern Lower Michigan airport-to-airport direct and always get cleared as
filed with no reroutes. I do this frequently. Many times, flying to other
destinations, I have tried to tweak my route to include some major VORs,
only to get an in-flight clearance direct to destination airport.

3. Newps said that his FDIO won't accept intersections that are not in

his
center's airspace, but that filing through DUAT/S and AFSS does not have
that limitation. I would expect that virtually all general aviation IFR
flight plans are entered via DUAT/S or FSS, excluding local clearances

to
punch through a layer or for instrument practice. And back to Sydney's
comment quoted above, I don't know what she means by the "originating

ATC
facility".


I apologize for being unclear. I wasn't talking about filing a flight
plan. As you say, that's usually through FSS or DUATS. DUATS will
accept
a flight plan direct from an obscure intersection in CA to an obscure
intersection in FL. So will FSS as far as I know (I haven't tried).
Duats will insert one lat-long per center. FSS doesn't seem to.


When I file through DUAT, it doesn't do one lat/long per center, it only
does the final fix.


What I mean by the "originating ATC facility" is the ATC facility you
talk to after you leave the ground, or the first Center you talk to.


Thanks, I understand your reference now

Or maybe she means the center through which the
flight plan is routed for processing after it is filed, and I really

don't
know what happens there.


That's what I mean. I really don't know what happens there, I
just know what happens to me .

Now if you've filed airway routing, I'm told an unrecognized
intersection or waypoint at the end of the route is no big deal.
The flight plan gets processed to the unrecognized point. The first
controller will know which way you're going, and by the time it
matters, the ATC computer will recognize it. Which is why Don Brown
and some others favor airway routing, and I have to say I'm
coming around to that viewpoint myself.

It's mostly an issue if, like many pilots these days, you file
GPS direct but feel you're making the skies safer or your karma
cleaner or something by adding the IAF from which you plan to shoot
an approach to your route. Or, let's say you've read the AIM and
you virtuously add a waypoint defining your route within 200 nm
of each center boundry. Let's say it's a VOR.


big snip

I don't see any difference between filing airport-IAF-airport vs
airport-airport, in terms of fix recognition and controllers knowing your
route. If the IAF (or other nearby fix) is there, it likely won't be
recognized by a distant computer (another center's airspace). But neither
will the airport. Maybe some airports are in all computers, but going into
Podunksville Muni, forget it. "N8158Y, say on-course heading." (Having
lat/long in the flight plan for the final enroute fix or for the destination
doesn't seem to change getting the heading request.) In either case, at the
originating end and along the way, the controllers will be in the dark about
your route, but the situation resolves itself as the flight nears its
destination.


What can happen -- what's happened to us -- is that the tower
controller doesn't worry his head about your flight plan. He
figures the tracon's gonna vector you and the center's gonna
reroute you anyway so why should he sweat. He says "cleared
as filed". Now you're handed off to Tracon, and he looks at
your flight plan and realizes he has no clue where you're going.
But he figures you'll be out of his airspace before he sorts
it out, so let the center controller sweat it. He queries,
"Grumman 12345, say on-course heading", you respond, and
that's sufficient for him. 10 minutes later, you're handed
off to Center.

Well, the next Center isn't going to be fobbed off with
"on-course heading blahblahblah" on the handoff, so the buck
stops with the first Center guy (this is our experience, mind,
YMMV).

This is when we, as pilots, get to learn by trial and error
which waypoints and airports aren't recognized by different
Center ATC computers as the controller says "um, Grumman 12345,
can you give me the lat-long for India One-Twelve, or a VOR near
it? No, I don't have that one...can you give me a VOR on
your route of flight, within my airspace?" Needless to say,
if ATC is busy, this totally lacks amusement value for them.
If ATC isn't busy but the wx is challenging, it lacks amusement
value for us.


One would think that the DUAT/S systems
were designed to only transmit flight plans to centers that would be
acceptable to centers, in terms of recognizability of waypoints.


There you go, expecting the federal government to be logical
again. That's where you're going wrong. That's your mistake.


Yeah, there's that logic thing again. But, joking aside, I really do expect
that the DUAT/S contractors operated to an interface specification of some
kind in designing their systems, and do not output data that will not be
understood by the receiving computers.

It seems to me that a US pilot filing domestic IFR through DUAT/S or FSS

is
safe using any valid identifiers s/he wishes, in terms of having the

flight
plan accepted and properly processed by the NAS computers.


What do you mean by "safe", Stan? (see above)

If you mean, ATC will understand which direction you're going and
how your route is defined provided you use any valid identifiers
accepted by FSS or DUATS, IME that's just not so.


Perhaps a poor term, but I meant it as I said, that the flight plan will be
accepted and properly processed by the NAS computers. To clarify my
meaning, I understand that the flight plan is routed from DUAT/S or FSS to
the center computer having jurisdiction over the departure point. That
machine looks at the proposed route, applies some secret algorithms and
decides whether to accept the route or to discard it and generate a new
route, maybe a preferred route. I meant that a flight plan accepted by
DUAT/S or FSS will not be rejected by the center computer because of an
unrecognized waypoint.

It may be the case that this computer that processes proposed flight plans
is completely unrelated to those that assist (?) controllers move airplanes.
It may be the case that the former has a complete database and the latter do
not.

I'm obviously doing a lot of guessing here, but we ought to be able to
reconcile things. FSS and DUAT/S plans do not get rejected because of
unrecognized waypoints, but all of us have experienced that enroute
controllers do not have access to a complete database. That suggests two
separate systems.

Stan



  #3  
Old August 9th 04, 10:43 PM
Stan Prevost
external usenet poster
 
Posts: n/a
Default

I'm replying to my own thread rather than starting a new one on the same
topic.

I went back to the "Must File To An IAF" thread and excerpted some
statements that are relevant to the issue I am trying to clarify through
discussion here. I'm not picking on or challenging anyone and I am not
debating filing to an IAF. I am trying to understand the more general issue
of how are fixes/airports/navaids/waypoints handled in various computers
associated with flight in the US National Airspace System, and how pilots
can file flight plans that suit their needs as well as the needs of ATC,
while understanding why.

First I will present the excerpts and then present my questions.

Sydney:
Fact: filing a flight plan to a fix not in the computer database of
the originating facility will cause the computer to stop processing
the flight plan. then the controller has to sort it out. This is
particularly a problem if the pilot has filed "direct" and ignored
the AIM suggestions about including navaids in each center's airspace
on their direct routing.

Newps:
There's no sorting out. If the flight plan comes out of my strip printer
then the computer won't have a problem with it.

McNicoll:
Unless the IAF is also part of the enroute structure it is unlikely to be
stored in the flight data processing computer. Filing one will cause your
flight plan to be rejected at some point, until someone corrects it by
removing the filed IAF!

Sydney:
If the IAF is not an H-class VOR, it's not likely to be in the ATC
database of the originating ATC facility if you're making a trip of
any duration, so filing to an IAF only bolixes the works.

McNicoll:
The IAF is probably an LOM that is not stored in the computer so filing it
will cause the flight plan to stop processing at the last good fix.


Sydney:
But it's still not necessarily a good idea to file to an IAF, since the ATC
facility where the flight originates may not have said IAF in their
database.


McNicoll:
In most cases where the IAF is not part of the enroute system the flight
data processing computer will not accept it anyway.


Sydney:
If you're not filing via airways, and your flight originates outside
the ATC facility who "owns" that IAF, the harm is that the ATC computer
will very likely not recognize that IAF and will stop processing your
flight plan at that point. So if you insist on putting an IAF in
block 8, make sure there are several more nationally-known waypoints
defining your route of flight.


Some general themes running through the above comments and other
discussions:

1. A flight plan may contain fixes that are valid but may not be recognized
by the computers at various ATC facilities along the route of flight.

2. A flight plan containing any valid fixes can be successfully filed
through FSS or DUAT/S but not necessarily by a controller, whose computer
may not recognize some of the fixes.

I believe it to be the case that a flight plan filed through FSS or DUAT/S
is routed to a center computer, which processes the flight proposal using
secret algorithms and decides whether to accept the plan or to generate a
new route (such as a preferred route), and then sends the flight plan to the
ATC facility responsible for the point of origin of the plan, where a flight
proposal strip is printed. This strip will have the information to be given
to the pilot in his/her clearance, and whether it is "as filed" or "full
route clearance". The clearance will include all fixes in the route,
whether or not they are stored in the computer of the initial ATC facility.
Once the controller at the initial facility "departs" the flight, flight
progress strips are then printed out down the line along the route of flight
at the facilities to which the aircraft will be handed off to. Those strips
also include the route, or at least the route information is accessible to
the controller in the computer, whether it is "understood" by the computer
or not. I hope this is correct so far.

Another theme running through the previous comments is that the computer at
each ATC facility along the route does some kind of processing on the flight
plan, but upon encountering a fix that is not in its database, will "stop
processing" at the last recognized fix. This supposedly results in somehow
bollixing up the works. I think it is being said that the controller will
be unable to determine the route of flight through his/her airspace, and
some examples of actual experience were given to illustrate that. Steven
even said the flight plan will be "rejected at some point" until someone
removes the offending fix (which is valid but unrecognized). Newps said
that if it prints on his printer, the computer won't have any problem with
it. I'm not sure how to reconcile those two statements, they could suggest
that an unrecognized fix will cause a flight progress strip to not print
out.

Well, I really don't understand. First, I don't know what kind of
"processing" is performed by the ATC computers, and I don't know what is
meant by "stops processing" or "rejected". When the computer *successfully*
processes the plan, what is different from what happens when it "stops
processing" at some point? Does something different show up on the radar
scope, does an error message occur, are F-16s launched against the offending
aircraft, or what?

Further, I don't understand why, in the previous thread, the emphasis was
placed on enroute fixes (in particular, an IAF) not being recognized by
computers along the way. If the fix were omitted, then wouldn't the same
problem arise with the destination airport? Why is it not the same
situation with just GPS airport-to-airport direct, with no enroute fixes?
Do all the computers store all the airports? I know that when I file direct
to Podunksville Muni several centers away, nobody along the route seems to
have any idea where that airport is, but nothing is bollixed up. Maybe that
is because I generally file through DUAT, and DUAT includes the lat/long of
the airport and the computers can process that. If I include an arrival
fix, DUAT puts in the lat/long of that fix rather than the airport. I don't
know if FSS inserts lat/long like DUAT does.

I performed an experiment with DUAT. I filed (and deleted) several flight
plans, from an airport in Memphis Center airspace to an airport in
Minneapolis Center airspace, with Indianapolis and Chicago center airspace
in between. This is a flight I commonly take, usually GPS
airport-to-airport direct, with no problems (that I know about).

a. Airport (ZME airspace) direct airport (ZMP airspace). DUAT inserted
lat/long of destination airport in route.
b. Airport, VOR in Minneapolis Center airspace, airport. DUAT inserted
lat/long of the VOR.
c. Airport, VOR in Indy Center airspace, airport. DUAT inserted lat/long of
the VOR.
d. Airport, VOR in Indy Center airspace, VOR in Minneapolis Center
airspace, airport. DUAT inserted lat/long of the VOR in Indy Center
airspace.
e. Airport, VOR in Memphis Center airspace, VOR in Indy Center airspace,
VOR in Minneapolis Center airspace, airport. DUAT inserted lat/long of the
VOR in Indy Center airspace.

Assume that any of the ATC computers along the route can process a lat/long,
and that ATC computers store only fixes within their center's airspace. Then
any of these flight plans would have been fine for Memphis Center (and
presumably approach control facilities delegated Memphis Center airspace).
I say that because the computers in Memphis Center airspace would have a
recognized waypoint (lat/long) farther along the route to allow computation
of the route through Memphis Center airspace. I'm not so sure about
subsequent facilities. For example, in Chicago Center airspace, the
adjacent airspace areas are Indy Center and Minneapolis Center. In Cases c,
d, and e, there would be no recognized waypoint or lat/long in Chicago
Center airspace or beyond it. This one experiment suggests that DUAT
generates flight plans that favor the ARTCC in whose airspace the flight
plan originates.

So I reversed the route and reran the experiment.

f. Airport (ZMP airspace) direct Airport (ZME airspace). DUAT inserted
lat/long of destination airport in route.
g. Airport, VOR in ZMP airspace, Airport. DUAT inserted lat/long of
destination airport in route.
h. Airport, VOR in ZMP airspace, VOR in ZID airspace, VOR in ZME airspace,
airport. DUAT inserted lat/long of VOR in ZID airspace.

This supports that the DUAT plans favor the originating ARTCC.

I repeated the experiment on DUATS. For Case a, the result was identical.
For Case e, DUATS did not insert ANY lat/longs. That's all I ran.

(Another difference noted is that DUAT would not let me have more than one
flight plan on file using the same A/C, airports, and times. DUATS had no
problem with it.)

It would be useful to know more about the capability of center and approach
control computers in terms of their databases of fixes. Do they all store
some subset of the total database, and is the way the local database is
constructed uniform across facilities, or is it variable because of
equipment, or local policy, or what? What will work for all of them,
besides lat/long? Have to be careful about putting too many lat/long or FRD
fixes to define the route, because Newps says they "fix" those kind of
flight plans when they see them, or not enough because Steven says that
offending fixes (IAFs at least) are removed.

What I would conclude from my experiment is that whenever going from Fix A
to Fix B crosses one or more center boundaries, including the lat/long of
Fix B will always work, no matter how many center airspaces it crosses.
This might be somewhat tedious to determine. The AIM recommendation to
include at least one waypoint in each center airspace would also seem to
work, although DUAT/S does not do that. I also wonder the reason behind the
AIM recommendation that a waypoint be no further than 200 nm from the center
boundary. Maybe that has something to do with the rules for selecting fixes
to be stored in a center's computers, that it stores fixes within its own
airspace plus 200 nm around it?

I can easily see that pilots might have different experiences depending on
what service they used to file their flight plans.

Any help in getting this sorted out and understood will be appreciated.

Regards,
Stan


  #4  
Old August 10th 04, 05:15 AM
Stan Prevost
external usenet poster
 
Posts: n/a
Default

Thanks for the great reply, right on target. I would like to inquire a bit
further.

"TJ Girl" wrote in message
om...
Hopefully this will clear a bit up...
The Center's computer contains a subset of fixes that includes all
within that center's boundaries, a lot of the adjacent center's fixes,
and the major fixes nationally.


Can you shed any light on the rules for including fixes from adjacent
centers? Is it everything within 200 nm of the center boundary? Or just
airway VORs?

However, any center's computer can
understand a latitude/longitude location.
In order to "process" a flight plan, the center must understand the
route up until the first fix outside the center. This is why a lot of
controllers will put in the flight plan "route..lat/long..fix at that
lat/long" - here the host (Center) computer only processes up to the
first lat/long and doesn't care what comes after it, so the unknown
fix can be included without a problem. Many controllers also just put
a nearby major airport as the destination and put the real destination
in the remarks, then a controller in the destination center, or maybe
one adjacent to it, can put in the correct destination.
As far as processing, this means that the computer "knows" where you
are going. The controller can display route lines. Your target will
flat track instead of free track - which means the computer predicts
your future position based on flight plan data, instead of just your
history. You can auto-hand to the next sector - which means the
computer will start the handoff at a specified distance from the
sector boundary if the controller has not already initiated it. It
means things like conflict alert will be more accurate, because the
computer knows where you are expected to go and is not just guessing
based on where you have been. Basically, it just comes down to
meaning the computer (and therefore the controller) know what you are
going to do.


What does the computer do if it cannot process fixes to determine the route?


Do all the computers store all the airports?


They don't store all, but will store all the major ones, so it really
just depends where your destination is.


Is there a simple rule for what constitutes a major airport for this
purpose?


Do they all store
some subset of the total database, and is the way the local database is
constructed uniform across facilities, or is it variable because of
equipment, or local policy, or what?


They store a subset, as mentioned above. The theory is space
limitation. The new URET system stores the entire Jeppesen database,
so you should start to see this problem go away (and new ones arise).


What is the extent of deployment and use of URET?



  #5  
Old August 10th 04, 02:14 PM
TJ Girl
external usenet poster
 
Posts: n/a
Default

Can you shed any light on the rules for including fixes from adjacent
centers? Is it everything within 200 nm of the center boundary? Or just
airway VORs?


Unfortunately, I do not know the exact rules they use for determining
what fixes to include. Something like ORD is in everyone's computer.
Something like 7Y7 is only known by Minneapolis' computers. As far as
anything in between, well, I could only guess....


What does the computer do if it cannot process fixes to determine the route?


It free tracks, which means it'll predict your future position based
only on your history. This makes route lines not work, auto-handoffs
disabled, conflict alert inaccurate, etc. You won't find an aircraft
get into that state, though. The controller will fix it at least to
one fix outside his center so you will always stay in flat track: or
predicting your future based on your history AND your flight plan
informaiton.


What is the extent of deployment and use of URET?


I don't have a map offhand, but they showed it to us when we went
through the training, so I'm going on my memory. Most of the eastern
centers have it now. Atlanta has not gotten it for political issues.
Chicago has it but they set so many rules about its use that the
controllers are ignoring it.
I know definitely Boston, Cleveland, Minneapolis, Kansas City, and
Denver have it. Some of the others do, too, but again, I don't have a
map here. The controllers at these ceters for the most part love it.
It's slowly working its way west. Denver got it this summer, not sure
about Houston or Dallas. Salt Lake is next in line, but I think they
are delayed until after DRVSM (domestic reduced vertical separation
minimum) is deployed nationwide in January.

TJ Girl
  #6  
Old August 10th 04, 04:38 PM
Newps
external usenet poster
 
Posts: n/a
Default



Stan Prevost wrote:


The first thing is to understand the controller's needs for route
definition, specifically for a direct flight for this discussion. One might
expect that the controller would be concerned only with the route through
his airspace, so he couldn't care less about the route definition way down
the line. Does he need to be able to make my course line appear on his
radar scope all the way through his airspace?


Course line? What course line?



Or does he just need a
short-term projection of my track using radar for present position,
direction, and speed?


Ain't got that either.


Probably one need is to be prepared to handle radar
failure.


Yeah, right. If the radar fails completely at a busy terminal airspace
you're screwed. We all are. The controller will attempt to knock the
cobwebs off his long unused nonradar procedures but the reality is
traffic comes to a grinding halt.


In nonradar procedures, I think they try to move us all onto
airways, and to do this, the panicked controller needs to know which airways
to move us onto that keep us going in the proper general direction and out
of his airspace (or maybe the computers suggest new airway routing).


In a suprise nonradar situation I would call the center to see if a
flight on a direct clearance is in radar contact. If so then he can
stay on his direct route. But this being Salt Lake Center they don't
much care if an aircraft is in radar contact so the aircraft would most
likely stay on his direct route.


So how
does knowing one VOR-based fix in his airspace do that?


I have a map.


Does he have his
computer draw a line on his scope from present position through the fix, so
that he can then pick airways that approximate that route?


You don't go making up airways. In this situation you would give a guy
a heading to join an airway and reclear him via that airway. Separation
would instantly go 100% vertical, it's the easiest one to apply.




But eventually, no matter how well we understand those things, we will come
back to the old oft-debated issue of no matter what you file, you will get
something different or will get major reroutes, so you might as well file
direct airport to airport.



99.9% of IFR flights out of Billings are as filed, so this is going to
depend on where you are.



I am sure this is more true in some areas than
others, based on my own experience, and for frequently-flown routes, one can
eventually learn reliable routing. Up through the northeast corridor, I
always get reroutes. In the east-central US, I can file from Alabama to
northern Lower Michigan airport-to-airport direct and always get cleared as
filed with no reroutes. I do this frequently. Many times, flying to other
destinations, I have tried to tweak my route to include some major VORs,
only to get an in-flight clearance direct to destination airport.


Minneapoils and Salt Lake give a lot of direct and vector to direct
clearances.



Now if you've filed airway routing, I'm told an unrecognized
intersection or waypoint at the end of the route is no big deal.
The flight plan gets processed to the unrecognized point. The first
controller will know which way you're going, and by the time it
matters, the ATC computer will recognize it. Which is why Don Brown
and some others favor airway routing, and I have to say I'm
coming around to that viewpoint myself.


Airway routing is necessary in really busy airspace because right now we
have no better, more efficient way of doing things. Get out into the
other 75% of the country and direct routings are the norm.



I don't see any difference between filing airport-IAF-airport vs
airport-airport, in terms of fix recognition and controllers knowing your
route. If the IAF (or other nearby fix) is there, it likely won't be
recognized by a distant computer (another center's airspace). But neither
will the airport. Maybe some airports are in all computers, but going into
Podunksville Muni, forget it. "N8158Y, say on-course heading." (Having
lat/long in the flight plan for the final enroute fix or for the destination
doesn't seem to change getting the heading request.) In either case, at the
originating end and along the way, the controllers will be in the dark about
your route, but the situation resolves itself as the flight nears its
destination.


You also need to understand what I see as an approach controller. The
strip that prints out of your arriving flight does not have your cleared
route on it. All it has is the destination airport and the time you
will be there. I don't need to know or even care what you filed or were
cleared for. You're landing here and you will be vectored as such.


  #7  
Old August 10th 04, 04:55 PM
Newps
external usenet poster
 
Posts: n/a
Default



Stan Prevost wrote:



Another theme running through the previous comments is that the computer at
each ATC facility along the route does some kind of processing on the flight
plan, but upon encountering a fix that is not in its database, will "stop
processing" at the last recognized fix. This supposedly results in somehow
bollixing up the works.


No such thing happens. If the strip prints out of the computer it will
work for the entire route. There is never a point where the computer
throws up its arms and says screw it, where some action is required by
the controller to keep the flight active.


I think it is being said that the controller will
be unable to determine the route of flight through his/her airspace,


That can happen if you file direct and the controller doesn't recognize
the destination airport. However the only controller that may really be
in the dark is the first one because in all subsequent sectors the plane
is on a straight line to his destination. You may not know where that
is but you know about where it is because he is going directly there.



Well, I really don't understand. First, I don't know what kind of
"processing" is performed by the ATC computers, and I don't know what is
meant by "stops processing" or "rejected".


It means nothing because it doesn't happen on an active flight plan. If
I try to make an ammendment and the computer doesn't recognize the fix
then it will just reject the ammendment but the original active flight
plan remains in effect.


When the computer *successfully*
processes the plan, what is different from what happens when it "stops
processing" at some point?


It doesn't, don't worry about it.




Why is it not the same
situation with just GPS airport-to-airport direct, with no enroute fixes?
Do all the computers store all the airports?


No. My computer stores the airports in my center and some big airports
in the other centers.


I know that when I file direct
to Podunksville Muni several centers away, nobody along the route seems to
have any idea where that airport is, but nothing is bollixed up.


Exactly. If your flight plan was originally accepted by AFSS or DUATS
then it will work along your entire route.




It would be useful to know more about the capability of center and approach
control computers in terms of their databases of fixes.


The approach controls don't have their own computer databases of fixes.
Everything runs by modem thru the center computer.

because Newps says they "fix" those kind of
flight plans when they see them,


We offer to get rid of the garbage in the flight plan. Sometimes they
want to keep it in there for training but most of the time they are
happy to just go direct airport to airport.




Any help in getting this sorted out and understood will be appreciated.


Now, go to your nearest TRACON and get a tour. Then ask the controller
to file some flight plans thru his FDIO and you will get a better
understanding and you will see the computer accept some routings and
reject others.

  #8  
Old August 12th 04, 04:52 AM
Steven P. McNicoll
external usenet poster
 
Posts: n/a
Default


"Newps" wrote in message
...

If the computer doesn't recognize a fix it won't accept it.


True only if the fix is within the processing center or the first fix
outside.



To make matters even more confusing you can call AFSS and get a
plan into the computer that my computer will not take.


No, he can't.



And my computer will print that flight plan and it will work normally.


No, it won't.



For example when I fly back
to the Minneapolis area I always land at Anoka County, ANE. You can
call Great Falls AFSS(or use DUATS) and file your flight plan to ANE and
it will print out in front of me. I, however, cannot type in the same
flight plan because my computer does not recognize ANE.


Wrong. What the computer accepts or rejects does not vary with the source
of the flight plan.


  #9  
Old August 12th 04, 05:12 AM
Steven P. McNicoll
external usenet poster
 
Posts: n/a
Default


"Stan Prevost" wrote in message
...

OK, so all the concerns about an IAF or other waypoint not being

recognized
by ATC computers will not result in the pilot being surprised by a

clearance
that does not include the waypoint. The biggest surprise would be to a
pilot air-filing and the controller, like you, reporting back that the
computer does not recognize one waypoint on the route attempting to be
filed. Then Plan B would have to be formulated, but this is still early

in
the game.


Easily remedied. Just include a good fix outside the originating Center on
or near the desired route. If you can provide the coordinates of the
offending fix they can be entered just prior to it. The flight plan will
then process just fine and no alteration of your route is needed at all.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 01:21 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright 2004-2020 AviationBanter.
The comments are property of their posters.