Re: [Flightgear-devel] reversible ILS

[Alex P. <ale...@pa...>]

+1. Reversible approaches should be configured like any other ATC controlled ground system - such as runway lighting.  I have no objections to an automatic selector for which ILS end to enable, but it should be based on surface wind (for example) and not the aircraft position.



John Denker <js...@av...> wrote:

>Back in the 2nd week of September there was discussion of
>reversible ILSs.
>
>Maybe I missed something, but I thought there was rough
>consensus around the following ideas:
>
>a) FG behavior should be reasonably realistic.  We should 
> not make artificial assumptions that make approaches
> unflyable, when better alternatives are readily available.  
> Conversely, we should not require FG to implement features 
> that are not available in real life.
>
>b) An instrument approach procedure generally contains a 
> "missed approach segment".  There is a maxim that says 
> "If you are not prepared for the miss, you are not prepared 
> for the approach."  The FAA says that half the time, 
> a practice approach should include flying the missed
> approach segment.  Real-world pilots take this seriously.
> Lives are at stake.
>
>c) You cannot show up at a real-world airport and expect
> both ends of a reversible ILS to be active simultaneously.  
> The physics doesn't permit it.  The signals would interfere.  
> If runway 11 is active and you would prefer runway 29, 
> you can ask Tower to reverse the ILS.  They might or might 
> be able to grant your wish.
>
>d) For years, FG has attempted to divine which end of the 
> reversible ILS the pilot wants to use based on aircraft 
> position and/or heading.  This is both unrealistic (see 
> item c) and impossible.  There is no objective way to 
> determine whether an aircraft is flying the "upwind leg" 
> for runway 11 or the "downwind leg" for runway 29;  the
> only difference between the two is the pilot's intentions.
> You've heard of problems that are so hard that they are
> classified as NP-complete ... well, this problem is much 
> worse than that.  It is ESP-complete.
>
>e) The current code is even more broken than that.  At
> some airports, it gets the wrong answer 100% of the time,
> so that you cannot fly the inbound segments, never mind
> the missed approach segment.  Bug reports on this issue
> have been discarded without comment.
>
>f) Code to fix all these problems has been available since
> September.  It uses a "preferred-approach-deg" value
> in the property tree to decide which end of the ILS to
> activate.  If you prefer the other end, you can easily
> change this property.  All segments of the approach are
> flyable.  Everything is predictable and well behaved.
>
> The same words that described the ILS service volume
> apply here:  This is a significant departure from past
> FG behavior, but it is not wrong.  It is feature, not
> a bug.
>
> This code was not committed.  It was discarded without
> comment.
>
>===========
>
>I was recently told [off list] that there was a
>"requirement" within FG to permit simultaneous approaches
>to both ends of a reversible ILS.  This came as a surprise
>to me.  I do not recall anybody suggesting this, even as 
>a joke, much less any consensus in this direction.
>
>Let's be clear:  We all agree it is important for both
>ends of the ILS to be available without undue hassle, but 
>they don't need to be available at the same time.  And
>"without undue hassle" doesn't mean without any pilot 
>input at all, especially when the problem is ESP-complete.
>Most real-world instrument-rated pilots are content to 
>fly the approach that Tower says is the active approach;  
>they don't show up at an airport with inflexible pre-
>conceptions about which approach will be active.
>
>I was also informed [off list] that the code to make
>reversible ILSs usable had been "ignored" because it was 
>"not good enough".  That is not very informative, not
>very constructive.  No clarification has been forthcoming 
>as to what makes it "not good enough".
>
>Perhaps some folks on this list would be kind enough
>to look at the code and make constructive comments.  
>Take a look at
>  http://gitorious.org/~jsd/fg/sport-model/commits/sport
>in particular the item that speaks of "reversible ILS".
>
>If there are some requirements that I am not aware of, 
>requirements that make unflyable approaches preferable 
>to flyable approaches, please explain.
>
>------------------------------------------------------------------------------
>This SF.Net email is sponsored by the Verizon Developer Community
>Take advantage of Verizon's best-in-class app development support
>A streamlined, 14 day to market process makes app distribution fast and easy
>Join now and get one step closer to millions of Verizon customers
>http://p.sf.net/sfu/verizon-dev2dev 
>_______________________________________________
>Flightgear-devel mailing list
>Fli...@li...
>https://lists.sourceforge.net/lists/listinfo/flightgear-devel