Riddle me this, pilots

"Chip Jones" wrote in message
...
A couple of years ago we had a guy flying through GRB approach airspace
always had bad Mode C. But it was only bad with GRB approach, no other
facility had a problem with it. He had it checked at an avionics shop
and
they found nothing wrong.

Yep, this kind of Mode C anomoly happens in ZTL airspace too. That's one
reason we always go with pilot reported altitude over Mode C readout.

First time I was called on an inaccurate Mode C by ATL, I took it to the
shop. They said it was OK and serviced it anyway. ATL called me on it
again but it's fine everywhere else, almost....

Anytime I fly from GSO towards CLT, GSO either can't see me, or gets an
incorrect mode C for a short period of time. Can't see why one or the
other. Can't see why there is an anomoly at all. On the other hand, I flew
RDU towards CLT practically every week for 3 or 4 years. GSO never had a
problem seeing me on that route. Just one of those things that awaits
migration to better technology.

"pilotjww" wrote in message
...
Nice thread.

A small nit: I fly a low-wing, and any ATC traffic alert inside of 4-5
miles
and below my altitude will be hard to see without some maneuvering to
remove
my airplane's nose or wing from line-of sight. I expect even a high-wing
will also have at least the problem of traffic under the nose. I get a lot
of these alerts, where the traffic is a thousand or more below me, often
unverified, and I find them useless.

You might want to think carefully about the potential impact of erroneous
mode C information. It happens. It has happened to me more than once (see
earlier posts). It has caused me to pay attention to those "low and close"
alerts by at least for a moment, pretending that it is at my altitude. At
least it gives you something to scan for. Maybe you'll see that glider
loitering at cloud base.

"Newps" wrote in message
news:9VQ0b.210033$Ho3.27525@sccrnsc03...


Chip Jones wrote:
Had I known that
these aircraft were going to get so apparently close in the end without
a
visual, I would have vectored the Baron early in the interests of air
safety
(regardless of what the 7110 dictates) to avoid the alert.

That is far and away the better procedure. I have had a few situations
like that and I will never let it get to a safety alert status. The IFR
guy will get vectored. It also saves time.


I totally agree, but it requires that you recognize the situation and have
time to deal with it. In my airspace I simply don't have the time to vector
every IFR around potential VFR traffic because I am too busy slinging IFR's
around IFR's or providing other IFR services. The avoidance of the alert to
begin with is indeed better for all concerned IMO, but it is not always
possible because of workload.

Chip, ZTL




----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! 100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

"Steven P. McNicoll" wrote:

wrote in message ...

That's the policy created by a bunch of inward thinking idiots at FAA
Headquarters (ATP).


You are not in a position to make that judgment..

That's your opinion.

Peter Duniho wrote:

wrote in message ...
[...] it
seems that the air traffic procedures folks are primarily fooling
themselves
(so, what's new? ;-) when they don't consider an unknown secondary target
returning Mode C data to be sufficiently radar identified for merging
target
safety action.

Keep in mind that if ATC is not in radio communications with the radar
target, they have no way to verify the Mode C readout. As such, it should
be considered unreliable. Since an ATC instruction could include an
altitude change instead of or in addition to a heading change, the rules
need to account for that.

That is exactly what a TCAS RA does, and it relies on "unverified" Mode C.
But, a merging target vector should not include an altitude change unless the
controller has the altitude available, and then only as a last resort to an
avoidance vector.



My personal opinion is that, generally speaking, the FAA folks who come up
with ATC procedures do have a clue, and the procedures mostly make sense.

Good thing TCAS isn't so strict about what it tags.

I guess that's a matter of debate. A faulty Mode C readout could cause a
TCAS unit to cause an accident, rather than avoid one.

Well, so far it has only prevented accidents. Had it been used properly on the
Swiss border, a lot of folks would still be alive today..

"Steven P. McNicoll" wrote:

"Newps" wrote in message
news:N3h0b.192923$Ho3.26290@sccrnsc03...

That was cool. I would tag up the "VFR" pilot and run him thru FSDO.
You have proof he was IMC.


You'd have proof that he was in IMC only if he had collided with the guy at
7000 in IMC.

How would that provide proof that the collision took place in IMC?

wrote:
"unverified" Mode C.

When a Mode C readout is wrong, where is the problem? Is the encoder
producing bad data? Is the data path between the encoder and the
xponder corrupting the data? Is the xpdonder corrupting the data? Is
the RF pulse from the xponder being corrupted? Is the receiver not
decoding it right?

Montblack wrote:

("Capt. Doug" wrote)

(pilots vs. controllers- what a softball game that would be!)

Man on 3rd base....You are not authorized to cross Home plate. Repeat...hold
short of Home plate!

Person holding short of 1st base, you may now taxi back to the dugout -
you're out.

Ahh, a double play in the making, on a ball hit over the centerfielder's
head.

--
Montblack



Dare I ask the classic A&C bit, to wit, 'who' is on first...'what' is on
second....and 'I don't know' is on third?

Doc Tony
;-)

[suddenly...]

George H. "Let's get serious [!] here, Doc! What we need are 'team'
names! In effect, what is the 'team' name for the the ATC controllers
and what is the 'team' name for the pilots? Something 'catchy' perhaps!"

Chip: "Well, how's this: 'Air Wizards' for the ATC folks [pauses...] and
'TINJOCKEYS" for the pilots?"

X: [JD/LL.B. type from one of the av groups!] "Objection! The name
'tinjockeys' is clearly an inequitable visual analogy when the other
team bears the otherwise superlative name of alleged 'air wizards'!"

Y: [quickly grabs the Black Robe from the chair nearest the KB and
assumes an ad hoc judicial posture.... !] "Objection over-ruled!"

X: "Exception!"

Y: "Noted!"

Doc Tony: "How about we take the acronym approach! What say ye to the
"DAMNED" [Descend And Maintain Normal Equated Distance] for the ATC
folks and the "CAVULARIOS" for the pilots?"

George H. "Nahhhh. Simply "AIRS" for 'us' that fly versus "SEATS" for
'them' that sits!"

Chip: [and duly noting George's comment.....] "Well, as an alternative,
what say to the "SCOPES" versus the "GROPES" !"

;-)


Ohhh, what harm.

[from the other thread...and STILL at it...throat well coarse now! ]

Jim Fisher: "SEND DOWN 50' OF ROPE.....fer cryin' out loud!"

great flick, that one!

[but to my utter surprise...talking about flicks...]

Montblack: [doing the commanding officer to Detective 'Popeye' Doyle
bit...] "You know your hunches have been wrong before, Doc, or have you
forgotten about that?"

;-)

Jim Fisher: [the man loves those old flicks! Reverts and gets very
serious....indeed angry!!] "Six weeks my partner and I worked this case
and WHO do we come up with...PETE DUNIHO fer cripes sake...now you
gotta' give us that warrant!" [*later for 'Joel Weinstock'..the actual
script line]

wrote in message ...
That is exactly what a TCAS RA does, and it relies on "unverified" Mode C.

As I mentioned, this is not as safe as people (i.e. you) would like to
think.

But, a merging target vector should not include an altitude change unless
the
controller has the altitude available, and then only as a last resort to
an
avoidance vector.

Your original question was regarding why vectoring is not part of the ATC
standard procedures for dealing with a VFR target. I'm simply answering
that. You are correct that one could limit the vector to no altitude
changes. But that's simply not how the handbook is written.

As far as I know, the language used in the controller's handbook allows
altitude changes any time a controller is supposed to vector an airplane.
It would be a significant change, and would add even more complexity to the
handbook, to call out this particular case as a situation where the
controller is permitted to providing heading guidance but not altitude.

I'm not interested in a debate, and I don't see why you seem to be itching
for one. If you really want to debate the matter, call up the FAA and
discuss it with them. They wrote the controller's handbook, not I.

I guess that's a matter of debate. A faulty Mode C readout could cause
a
TCAS unit to cause an accident, rather than avoid one.

Well, so far it has only prevented accidents. Had it been used properly
on the
Swiss border, a lot of folks would still be alive today..

I have a friend who would never wear a seatbelt, because she had a relative
who had been thrown from a car in an accident and walked away unscathed.
The logic she was using is similar to your use of a single example to
justify the use of TCAS.

I assure you that if controllers started using unverified Mode C returns to
provide altitude changes for traffic avoidance on a regular basis,
eventually someone would wind up at the same altitude of traffic that ATC
thought they were moving them away from.

The main reason that TCAS doesn't cause accidents today is that it's used in
a way that is unlikely to cause accidents. Airplanes that are in IMC are
being positively controlled by ATC, and the TCAS should only provide a
warning when ATC has made an egregious error. That doesn't happen very
often. Furthermore, the airplanes involved are both under radar control, so
even though the TCAS doesn't know it, the Mode C *has* been verified.
Airplanes that are in VMC, whether under positive control by ATC or not,
have the ability to use the TCAS to help them *spot traffic*, rather than
just blindly trust the TCAS to tell them what to do. The pilots can then
make a course adjustment as appropriate, based on *what they see*.

The controller rules are not written to allow things that are "mostly safe".
They are written to try to make sure that the controller's actions are 100%
safe in ALL situations. In cases where the controller is unable to know for
certain that they are able to separate traffic, the controller is simply not
allowed to attempt it. As such, an unconfirmed Mode C readout is simply not
a piece of information that a controller is allowed to use for positive
control of another aircraft.

It's sort of the Hippocratic Oath of air traffic control. Whatever else
they do, a controller should not make the situation worse.

Pete

"Maule Driver" wrote in message
om...

"pilotjww" wrote in message
...
Nice thread.

A small nit: I fly a low-wing, and any ATC traffic alert inside of 4-5
miles
and below my altitude will be hard to see without some maneuvering to
remove
my airplane's nose or wing from line-of sight. I expect even a high-wing
will also have at least the problem of traffic under the nose. I get a
lot
of these alerts, where the traffic is a thousand or more below me, often
unverified, and I find them useless.

You might want to think carefully about the potential impact of erroneous
mode C information. It happens. It has happened to me more than once
(see
earlier posts). It has caused me to pay attention to those "low and
close"
alerts by at least for a moment, pretending that it is at my altitude. At
least it gives you something to scan for. Maybe you'll see that glider
loitering at cloud base.


If ATC has you verified and another target unverified indicating a safely
separated altitude, is it SOP to call traffic just in case? Will the
controller make use of a previous report ("he's wa-a-ay below me") in
deciding whether to do so?

-- David Brooks