Unnecessary verbiage or sensible redundancy?

"Peter Duniho" wrote in message
...
"Tony Cox" wrote in message
ink.net...
Oh I don't know about that. 100% compliance isn't necessary, since
the two methods of announcing intentions aren't contradictory and
no additional ambiguity is introduced.

For it to do any good, you need to be able to tell the difference between
a
complete communication and an incomplete one. Without 100% compliance and
without some sort of built-in error detection, you can't. Your proposal
provides neither.

I'm still missing your point, I'm afraid. In both cases you can tell
when the transmission is complete since it'll end with "xxx traffic".
If you think I'm proposing dispensing with the full call, I'm not.
I'm not actually proposing anything - just telling you that I personally
prefer to add a "zero" to the front of a runway with one numeral,
and judging by what others have said that seems to be the preference
of the majority, even here in the US (it is apparently proper phraseology
elsewhere in the world).

I'm also saying that in this case, prepending a "zero" improves
the quality of information transfer if the transmission is truncated.

The two objections to this (pardon me if I've missed others) are
1) it's additional bandwidth, and 2) pilots might accidentally transpose
numbers. Both are valid.


And *in this particular case* (and no doubt in other scenarios
too) safety would have been enhanced had he used the "zero two"
phraseology.

How do you know he wasn't?

Because he was calling "Cherokee blah-blah, downwind, runway two".


Pilot calls "..left base, two". Could be either 2 or 20 & you know there
is an error. But you're none the wiser as to where he is. Worse case you
assume he's just being lazy with the "Jean traffic" bit & think he's on
base for 2.

How do you know there is an error? Perhaps he's landing on 2 and that was
the end of his transmission.

I know there is an error because the transmission doesn't end with
"Left Jean Traffic" or "Zero Left Jean Traffic" (0L7 has two parallel
runways). The fact that you jumped to the conclusion that he was
landing on 2 is precisely the issue in hand. He wasn't.


Pilot calls "..left base, zero". Error detected, but a reasonable
assumption
is that he is heading for 2.

How do you know he's heading for 2? Perhaps he's at a different airport,
landing on 1, 3, 4, 5, 6, 7, 8, or 9. Or even 2.

I don't know for certain, of course. He may be dyslexic. But assuming
he isn't, he could only be heading for 2 since he'd only say "zero" if he
was about to follow it with "two". Jean has only 2 one-digit runways,
2L and 2R, and he prepended his entire call with "Jean Traffic".

BTW, how does ATC call vectors? Don't they say things like "Cherokee
blah-blah turn right heading zero-two-zero", rather than just "two-zero"
?
Been a while & I can't remember.

As Steven said, three digit headings. But that has nothing to do with
calling runways, and they use single digits for single digit runways.

I think it has everything to do with it. ATC call three numbers and
pilots expect to hear three. If they don't, they know immediately that
there is an error. If it makes sense for headings, then why not for this?


It's not detecting conflicts. It's making use of degraded information.
Think of it as equivalent to a cyclic redundancy check, rather than
a parity check.

I'm afraid you need to read up on CRCs. They are simply a more reliable
error detection than a single bit parity check. They don't help you
reconstruct degraded information.

You really don't need to take my word for it. Go see what NIST
has to say. http://www.nist.gov/dads/HTML/cyclic...ancyCheck.html
CRC's *can* correct some limited types of transmission errors, whereas
parity checking can't. CRC's aren't very good at it, but that's another
matter. Just like adding that spare "zero"- it allows you to correct certain
limited types of transmission error.

Now if we could only get pilots to calculate a CRC in their
heads and append it to each transmission.......!

"Tony Cox" wrote in message
nk.net...

I'm still missing your point, I'm afraid. In both cases you can tell
when the transmission is complete since it'll end with "xxx traffic".
If you think I'm proposing dispensing with the full call, I'm not.
I'm not actually proposing anything - just telling you that I personally
prefer to add a "zero" to the front of a runway with one numeral,
and judging by what others have said that seems to be the preference
of the majority, even here in the US (it is apparently proper phraseology
elsewhere in the world).


Adding a leading zero accomplishes nothing when proper phraseology is used.



I'm also saying that in this case, prepending a "zero" improves
the quality of information transfer if the transmission is truncated.


So don't truncate transmissions.

"Steven P. McNicoll" wrote in message
k.net...

"Tony Cox" wrote in message
nk.net...

I'm still missing your point, I'm afraid. In both cases you can tell
when the transmission is complete since it'll end with "xxx traffic".
If you think I'm proposing dispensing with the full call, I'm not.
I'm not actually proposing anything - just telling you that I personally
prefer to add a "zero" to the front of a runway with one numeral,
and judging by what others have said that seems to be the preference
of the majority, even here in the US (it is apparently proper
phraseology
elsewhere in the world).


Adding a leading zero accomplishes nothing when proper phraseology is
used.

Did I say otherwise?




I'm also saying that in this case, prepending a "zero" improves
the quality of information transfer if the transmission is truncated.


So don't truncate transmissions.

Sometimes they are truncated by the actions of others. Sometimes
they are truncated accidentally. Sometimes the frequency is so
crowded that there is no bandwidth to request and receive a
retransmission. And sometimes you're best off not distracting
a student pilot who might have his/her hands full just landing a plane.

"Tony Cox" wrote in message
.net...

Did I say otherwise?


Did I say you did?



Sometimes they are truncated by the actions of others.


Because they are stepped on? Does it matter what you say when that happens?



Sometimes they are truncated accidentally.


How so?



Sometimes the frequency is so
crowded that there is no bandwidth to request and receive a
retransmission.


Then anything which reduces bandwith, such as dropping the completely
useless leading zero, is good.



And sometimes you're best off not distracting
a student pilot who might have his/her hands full just landing a plane.


So it's best if some blocked transmissions not be repeated? Seems to me
such a transmission need not have been made at all.

"Tony Cox" wrote in message
nk.net...
I'm still missing your point, I'm afraid.

Your original claim was that by including the zero on single-digit runway
names, one can reconstruct the communication if it is truncated. My point
is that that's not true.

Not sure how much more simply I can state it than that.

In both cases you can tell
when the transmission is complete since it'll end with "xxx traffic".

Not when it's truncated, it won't.

If you think I'm proposing dispensing with the full call, I'm not.
I'm not actually proposing anything - just telling you that I personally
prefer to add a "zero" to the front of a runway with one numeral,
and judging by what others have said that seems to be the preference
of the majority, even here in the US (it is apparently proper phraseology
elsewhere in the world).

I prefer to as well, as I said in the original post, to which you started
disagreeing. How can you disagree with my post, and yet claim to have the
same preference that I have?

I'm also saying that in this case, prepending a "zero" improves
the quality of information transfer if the transmission is truncated.

Yes, I know you're saying that. It's still not true.

The two objections to this (pardon me if I've missed others) are
1) it's additional bandwidth, and 2) pilots might accidentally transpose
numbers. Both are valid.

I'm not objecting to it at all. I'm simply pointing out that there's no
added value in adding a leading zero.

And *in this particular case* (and no doubt in other scenarios
too) safety would have been enhanced had he used the "zero two"
phraseology.

How do you know he wasn't?

Because he was calling "Cherokee blah-blah, downwind, runway two".

Which you said really was a truncated version of "Cherokee blah-blah,
downwind, runway two zero". There's nothing about that transmission that
tells you he wasn't using the "use a leading zero for single-digit runway
names" procedure.

Pilot calls "..left base, two". Could be either 2 or 20 & you know
there
is an error. But you're none the wiser as to where he is. Worse case
you
assume he's just being lazy with the "Jean traffic" bit & think he's
on
base for 2.

How do you know there is an error? Perhaps he's landing on 2 and that
was
the end of his transmission.

I know there is an error because the transmission doesn't end with
"Left Jean Traffic" or "Zero Left Jean Traffic" (0L7 has two parallel
runways). The fact that you jumped to the conclusion that he was
landing on 2 is precisely the issue in hand. He wasn't.

You have an odd definition of "know". Nothing about the pilot's
transmission allows you to differentiate between landing on "runway two" and
on "runway two zero". The fact that there's no "left Jean traffic" or "zero
left Jean traffic" at the end tells you nothing. For all you know, the
pilot simply didn't bother to say one or the other. And whether the pilot
chose to not say either intentionally, or did so accidently, that
information is still missing and still could have been either one.

Pilot calls "..left base, zero". Error detected, but a reasonable
assumption
is that he is heading for 2.

How do you know he's heading for 2? Perhaps he's at a different
airport,
landing on 1, 3, 4, 5, 6, 7, 8, or 9. Or even 2.

I don't know for certain, of course. He may be dyslexic. But assuming
he isn't, he could only be heading for 2 since he'd only say "zero" if he
was about to follow it with "two". Jean has only 2 one-digit runways,
2L and 2R, and he prepended his entire call with "Jean Traffic".

You never said anything about him prepending his entire call with "Jean
traffic". And if you're relying on that, why not just suggest to use "Jean
traffic" at the end, like everyone else does? Why insist on the use of a
leading "zero"?

As Steven said, three digit headings. But that has nothing to do with
calling runways, and they use single digits for single digit runways.

I think it has everything to do with it. ATC call three numbers and
pilots expect to hear three. If they don't, they know immediately that
there is an error. If it makes sense for headings, then why not for this?

In the case of vectors, three digits is used specifically to differentiate
from a relative turn (e.g. "turn left 30 degrees"). There's no similar need
with respect to runway names.

In other words (in case you missed it in the above paragraph), it makes
sense for vectors for an entirely different, and an entirely irrelevant
reason (irrelevant to runway names, that is).

You really don't need to take my word for it. Go see what NIST
has to say. http://www.nist.gov/dads/HTML/cyclic...ancyCheck.html

I saw what NIST has to say. So?

CRC's *can* correct some limited types of transmission errors

For example?

whereas parity checking can't.

Show me an example of a transmission error correctable with a CRC but not
with parity checking. The only difference between the two is the number of
bits applied to the error *detection*. Knowing the CRC does not allow you
to determine what the original data is.

The best parity checking *or* CRCs can do is tell you what the data was NOT.
You still need some other form of redundancy in order to tell you exactly
what the data IS, after you've used parity checking or a CRC to detect the
error.

In every use of a CRC for error detection I'm familiar with, once the error
is detected, the data is simply retrieved again (whether that be
retransmitting, user entering again, reading from media again, etc.)

CRC's aren't very good at it, but that's another matter.

They aren't "very good at it" because they aren't useful at all for it.

Just like adding that spare "zero"- it allows you to correct certain
limited types of transmission error.

The only example you've come up with is when you hear a zero and nothing
else. So, let's consider that for a moment:

* For it to work, the pilot MUST provide the *correct* name of the
airport, and the airport must NOT have more than one runway with a single
digit name.
* In the scenario where it works, the pilot could just as easily have
said the single *correct* digit, and provided just as much information.
* For seven out of nine airports with single digit runway names, there
is NO benefit whatsoever to including the leading zero.

I stand by my original statement: the correct solution is for pilots to not
truncate their transmissions.

Now if we could only get pilots to calculate a CRC in their
heads and append it to each transmission.......!

What good would that do?

Pete

Of course the [remembered to hit the ptt] re aren't any pilots who chop off
the front of their transmissions. And isn't it wonderful that interference
only affects the end of a phrase, it never chops off the front of one.






"Peter Duniho" wrote in message
...
"Tony Cox" wrote in message
nk.net...
I'm still missing your point, I'm afraid.

Your original claim was that by including the zero on single-digit runway
names, one can reconstruct the communication if it is truncated. My point
is that that's not true.

Not sure how much more simply I can state it than that.

In both cases you can tell
when the transmission is complete since it'll end with "xxx traffic".

Not when it's truncated, it won't.

If you think I'm proposing dispensing with the full call, I'm not.
I'm not actually proposing anything - just telling you that I personally
prefer to add a "zero" to the front of a runway with one numeral,
and judging by what others have said that seems to be the preference
of the majority, even here in the US (it is apparently proper
phraseology
elsewhere in the world).

I prefer to as well, as I said in the original post, to which you started
disagreeing. How can you disagree with my post, and yet claim to have the
same preference that I have?

I'm also saying that in this case, prepending a "zero" improves
the quality of information transfer if the transmission is truncated.

Yes, I know you're saying that. It's still not true.

The two objections to this (pardon me if I've missed others) are
1) it's additional bandwidth, and 2) pilots might accidentally transpose
numbers. Both are valid.

I'm not objecting to it at all. I'm simply pointing out that there's no
added value in adding a leading zero.

And *in this particular case* (and no doubt in other scenarios
too) safety would have been enhanced had he used the "zero two"
phraseology.

How do you know he wasn't?

Because he was calling "Cherokee blah-blah, downwind, runway two".

Which you said really was a truncated version of "Cherokee blah-blah,
downwind, runway two zero". There's nothing about that transmission that
tells you he wasn't using the "use a leading zero for single-digit runway
names" procedure.

Pilot calls "..left base, two". Could be either 2 or 20 & you know
there
is an error. But you're none the wiser as to where he is. Worse case
you
assume he's just being lazy with the "Jean traffic" bit & think he's
on
base for 2.

How do you know there is an error? Perhaps he's landing on 2 and that
was
the end of his transmission.

I know there is an error because the transmission doesn't end with
"Left Jean Traffic" or "Zero Left Jean Traffic" (0L7 has two parallel
runways). The fact that you jumped to the conclusion that he was
landing on 2 is precisely the issue in hand. He wasn't.

You have an odd definition of "know". Nothing about the pilot's
transmission allows you to differentiate between landing on "runway two"
and
on "runway two zero". The fact that there's no "left Jean traffic" or
"zero
left Jean traffic" at the end tells you nothing. For all you know, the
pilot simply didn't bother to say one or the other. And whether the pilot
chose to not say either intentionally, or did so accidently, that
information is still missing and still could have been either one.

Pilot calls "..left base, zero". Error detected, but a reasonable
assumption
is that he is heading for 2.

How do you know he's heading for 2? Perhaps he's at a different
airport,
landing on 1, 3, 4, 5, 6, 7, 8, or 9. Or even 2.

I don't know for certain, of course. He may be dyslexic. But assuming
he isn't, he could only be heading for 2 since he'd only say "zero" if
he
was about to follow it with "two". Jean has only 2 one-digit runways,
2L and 2R, and he prepended his entire call with "Jean Traffic".

You never said anything about him prepending his entire call with "Jean
traffic". And if you're relying on that, why not just suggest to use
"Jean
traffic" at the end, like everyone else does? Why insist on the use of a
leading "zero"?

As Steven said, three digit headings. But that has nothing to do with
calling runways, and they use single digits for single digit runways.

I think it has everything to do with it. ATC call three numbers and
pilots expect to hear three. If they don't, they know immediately that
there is an error. If it makes sense for headings, then why not for
this?

In the case of vectors, three digits is used specifically to differentiate
from a relative turn (e.g. "turn left 30 degrees"). There's no similar
need
with respect to runway names.

In other words (in case you missed it in the above paragraph), it makes
sense for vectors for an entirely different, and an entirely irrelevant
reason (irrelevant to runway names, that is).

You really don't need to take my word for it. Go see what NIST
has to say. http://www.nist.gov/dads/HTML/cyclic...ancyCheck.html

I saw what NIST has to say. So?

CRC's *can* correct some limited types of transmission errors

For example?

whereas parity checking can't.

Show me an example of a transmission error correctable with a CRC but not
with parity checking. The only difference between the two is the number
of
bits applied to the error *detection*. Knowing the CRC does not allow you
to determine what the original data is.

The best parity checking *or* CRCs can do is tell you what the data was
NOT.
You still need some other form of redundancy in order to tell you exactly
what the data IS, after you've used parity checking or a CRC to detect the
error.

In every use of a CRC for error detection I'm familiar with, once the
error
is detected, the data is simply retrieved again (whether that be
retransmitting, user entering again, reading from media again, etc.)

CRC's aren't very good at it, but that's another matter.

They aren't "very good at it" because they aren't useful at all for it.

Just like adding that spare "zero"- it allows you to correct certain
limited types of transmission error.

The only example you've come up with is when you hear a zero and nothing
else. So, let's consider that for a moment:

* For it to work, the pilot MUST provide the *correct* name of the
airport, and the airport must NOT have more than one runway with a single
digit name.
* In the scenario where it works, the pilot could just as easily have
said the single *correct* digit, and provided just as much information.
* For seven out of nine airports with single digit runway names, there
is NO benefit whatsoever to including the leading zero.

I stand by my original statement: the correct solution is for pilots to
not
truncate their transmissions.

Now if we could only get pilots to calculate a CRC in their
heads and append it to each transmission.......!

What good would that do?

Pete

"Peter Duniho" wrote in message
...
"Tony Cox" wrote in message
nk.net...
I'm still missing your point, I'm afraid.

Your original claim was that by including the zero on single-digit runway
names, one can reconstruct the communication if it is truncated. My point
is that that's not true.

Not sure how much more simply I can state it than that.

There doesn't seem much point in continuing this. I've given you
an example and walked you through it. If you can't see that someone
vocalizing "zero", necessarily followed by another digit which you
can reliably guess if you don't hear it, resolves a potentially dangerous
redundancy then I'm at a loss. I'm sorry I've not been able to help you
understand.


You really don't need to take my word for it. Go see what NIST
has to say. http://www.nist.gov/dads/HTML/cyclic...ancyCheck.html

I saw what NIST has to say. So?

Then you'll have noticed the statement "Many transmission errors
may be detected, and some corrected" in their description of the
algorithm, right?


CRC's *can* correct some limited types of transmission errors

For example?

It's been years since I've done this, and it is clearly off topic, but
as I remember the theory, it runs as follows. Since the CRC is a
polynomial which you can choose arbitrarily, it is possible to choose
an expression which generates CRC bits which 'oversample' certain
parts of the block you're trying to protect. In this way, you can -
given certain statistical noise properties - generally reconstruct certain
critical areas of the block from your redundant CRC bits (and even
if the CRC bits themselves have been corrupted).


whereas parity checking can't.

Show me an example of a transmission error correctable with a CRC but not
with parity checking. The only difference between the two is the number
of
bits applied to the error *detection*. Knowing the CRC does not allow you
to determine what the original data is.

Well, here's a tutorial which claims (I've not followed their proof) to
show how to use CRC's to correct burst transmission errors. Burst
transmission errors are those that begin with a bit error (which you
can detect and then reconstruct from the CRC) together with subsequent
bits which may or may not have errors in them (which you can detect, but
not correct). http://www.cs.niu.edu/~sjchung/c463/network.htm. Is that
sufficient to convince you?


In every use of a CRC for error detection I'm familiar with, once the
error
is detected, the data is simply retrieved again (whether that be
retransmitting, user entering again, reading from media again, etc.)

That's because CRC's aren't suitable for error correction when
the errors are distributed evenly through a block you're trying to
protect, and I'd wager that that is the only usage of CRC's that
you've come across. Not enough information content, you see,
but I'm sure you knew that. Anyway, as I hope I've explained to you
more clearly than I did with the runway phraseology, you *can*
use them for more than just error detection if you know where
you expect to find the error in the first place.

"Tony Cox" wrote in message
.net...

There doesn't seem much point in continuing this. I've given you
an example and walked you through it. If you can't see that someone
vocalizing "zero", necessarily followed by another digit which you
can reliably guess if you don't hear it, resolves a potentially dangerous
redundancy then I'm at a loss. I'm sorry I've not been able to help you
understand.


I'm sure that everyone could see that if you would explain why that's so.
But you have not done that.

"Tony Cox" wrote in message
.net...
There doesn't seem much point in continuing this. I've given you
an example and walked you through it. If you can't see that someone
vocalizing "zero", necessarily followed by another digit which you
can reliably guess if you don't hear it, resolves a potentially dangerous
redundancy then I'm at a loss.

"Potentially dangerous redundancy"? Now you're claiming that *redundancy*
is dangerous? Uh, okay.

You are right about one thing: there's no point in continuing, since you've
failed to even come close to showing how adding "zero" is a practice that
would improve communications.

You really don't need to take my word for it. Go see what NIST
has to say. http://www.nist.gov/dads/HTML/cyclic...ancyCheck.html

I saw what NIST has to say. So?

Then you'll have noticed the statement "Many transmission errors
may be detected, and some corrected" in their description of the
algorithm, right?

Just because someone wrote it, that doesn't make it true.

Well, here's a tutorial which claims (I've not followed their proof) to
show how to use CRC's to correct burst transmission errors.

Did you read the tutorial? I was unable to read it completely, because all
of the embedded items are of a type that doesn't display on my computer.
However, they only have one example of CRC error checking, and they
specifically state at the end of that example "However, there is no
sufficient information for the receiving TCP to correct the error(s)".

In spite of the promise at the beginning of the tutorial, it contains no
demonstration of the use of a CRC to *correct* an error.

Burst
transmission errors are those that begin with a bit error (which you
can detect and then reconstruct from the CRC) together with subsequent
bits which may or may not have errors in them (which you can detect, but
not correct). http://www.cs.niu.edu/~sjchung/c463/network.htm. Is that
sufficient to convince you?

I don't know what you think is contained in that tutorial that ought to
convince me. But no, it does not convince me. Maybe you could quote the
party that's supposed to convince me.

For a CRC to be useful in *correcting* erroneous data, it needs to contain
as much information as was lost in the first place. In the example you're
talking about, where the error is limited to a certain area of the data,
you'll find that the CRC itself contains essentially the same information
that was lost.

CRCs do NOT inherently provide error correction. They are only different
from a parity check with respect to the accuracy. For a CRC to provide
error correction, it needs to be large enough to basically be a redundant
component of the communication. And in that case, it's not the "CRC-ness"
of the CRC that's providing the error correction; it's the "redundantness"
of the CRC that's providing the error correction.

Perhaps your inability to understand that parity checks and CRCs are
basically the same thing, with only a difference of magnitude between them,
suggests an explanation as to your inability to see why adding "zero" to
your runway names isn't going to help things.

Pete

On Wed, 1 Sep 2004 11:27:19 +0100, "Paul Sengupta"
wrote:

So the "zero" has been replaced with "runway" when spoken.

I will try this, more for my own benefit than for others

all the best -- Dan Ford
email: (put Cubdriver in subject line)

The Warbird's Forum www.warbirdforum.com
Expedition sailboat charters www.expeditionsail.com