On 08/15/2008 01:30 PM, James Turner wrote:
> I encountered the following code, in the middle of
> FGNavList::findNavFromList:
[snip]
> Now, there's two bad things here: (I think)
> - in the DME case (type == 12 or 13), hdg is left 0.0
> - hdg, having been computed, isn't then used: I assume it should
> replace the 'station->get_multiuse' on this line:
> az1 = az1 - station->get_multiuse();
Good catch. Actually, there's more than two bad things here.
> It'd be great if someone who knows more about this code could comment
> on how 'important' it is, since it's only doing the right thing in the
> ILS/LOC case (the GS will be wrong because 'multiuse' contains other
> data, and DME because multiuse is empty)
Before we discuss the code in detail, we should try to figure out what
is the goal or purpose of this code. If the goal is realism, it will
be a very short discussion, because the concepts on which this code is
based are seriously unrealistic, even in the LOC case.
*) The "aiming" of localizer antennas does not work the way this code
assumes. Not even close.
*) This is well known and officially documented in e.g. the Aeronautical
Information Manual. Look under "Service Volume".
*) Pilots depend on the service volume behaving as documented.
-- This is particularly obvious in the case of "Back Course" approaches.
-- This is particularly obvious in the case of a Missed Approach where
the pilot follows the localizer course well past the antenna. One
of my maxims is
"If you're not prepared for the miss,
you're not prepared for the approach"
-- Et cetera. You get the idea.
> It feels like this ought to cause visible weirdness with nav-radios,
> but I don't have a strong understanding for how 'bad' this might be.
It's bad.
> Maybe we only actually encounter this code for ILS transmitters, so
> the bug is masked?
Even the ILS/LOC behavior is seriously unrealistic.
=============================
If you want to know how it works in the real world, consider e.g. the
paired transmitters for KJFK RWY 4L/22R.
-- ILS RWY 4L uses frequency 110.9, callsign I-HIQ
-- ILS RWY 22R uses frequency 110.9, callsign I-IWY
Now the trick is that in the real world, you never have both transmitters
active at the same time. There's a switch in the tower. It's just that
simple.
Funny story: This is one of the many reasons why pilots are
trained to always identify the navaid callsign. I once had
a student pull out the ILS RWY 4L approach plate and try to
follow it while the I-HWY transmitter was active. He got
rather spectacularly confused.
(Ever since then, he has been fastidious about IDENTing navaids.)
===========================================
Possibly constructive suggestions:
1) In the case of paired transmitters, turn on the one that serves the
runway _favored by the wind_. Do this regardless of the location of
the aircraft.
Remark: This works even in multiplayer situations.
Remark: Put a heavy low-pass filter on the choice of runway, so it
doesn't go nuts if the wind is variable. Maybe cooperate with the ATIS
code so that the "active" runway reported by ATIS is the runway with the
active transmitter.
2) Fix the many other bugs in the service-volume code. Note that there
is code in the Sport Model to handle false LOC courses, false GS paths,
extended LOC volumes, and other stuff you encounter in the real world.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
