Riddle me this, pilots

"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

wrote in message ...
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?

Are you asking how the collision occuring in IMC would prove that the
collision took place in IMC?

Sounds like a "if a tree falls in the forest with no one near enough to hear
it" sort of question...

Chip Jones wrote:


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.

Lucky for me I've got nothing but time.

The problem is you spent $200 on an encoder 10 years ago and expect it
to work for a lifetime. You very rarely if ever see a bad mode C on an
airliner.

Roy Smith wrote:

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?

Peter Duniho wrote:


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.

A controller owns a chunk of airspace. As long as I meet the separation
standards I can do whatever I need to with you.



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

TCAS is most useful in class D type tower situations. These are where
you are most likely to have the spam cans flying around with unverified
mode C. If the TCAS gives an RA the airliner must take the action
suggested. Places like Orange County and Pontiac come to mind. Lots
and lots of VFR targets

wrote in message ...

That's your opinion.


That's my observation.

"Newps" wrote in message
news:cI91b.218085$Ho3.28456@sccrnsc03...

A controller owns a chunk of airspace. As long as I meet the separation
standards I can do whatever I need to with you.


The controller can do only what is consistent with FAAO 7110.65.