Re: [Flightgear-devel] Glide slope (ILS) range

[Jari H. <ja...@fl...>]

Consulting my course material for passing the ATPL tests in Europe I 
read that the glide path is required to be usable up to a distance of 10 
NM (which I interpret from the touch down zone not the distance to an 
DME that may or may not be at destination). This distance should be 
valid +-8 degrees from the runway extended centre line in the horizontal 
plane. The vertical lower limit is 0.45 times the nominal glide path 
angle and the upper is 1.75 the nominal glide path angle.

The localizer is required to work up to 25 NM within +-10 degress, and 
up to 17 NM within +-35 degrees (angles in the horizontal plane against 
runway extended centre line). In vertically the signal should cover up 
to 7 degrees inclination within the stated distances. The lower bound in 
the vertical is harder to explain without a figure to support the text.

Furthermore, the literature states to never trust signals outside the 
above limits.

I agree with John that some randomness at the limits would be nice.


Cheers,

Jari


On 2009-12-17 21.19, John Denker wrote:
> On 12/17/2009 11:44 AM, Curtis Olson wrote:
>> I had a squawk here from a (real) King Air pilot because on an ILS approach,
>> our glideslope indicator doesn't become active/in-range until about 7-8
>> miles out.  Beyond this range the indicator just stays centered at zero.
>> With a standard 3 degree glide slope, 7 miles out equates to about 2000'
>> AGL, outside of this range the FlightGear glideslope does nothing.
>
> Tell him we need a more detailed bug report:
>   -- what airport, what approach procedure
>   -- what simulated aircraft
>   -- what version of FG
>
> The GS and LOC code was broken for years, but I think it
> got fixed recently.
>
>> I see our database lists the GS ranges at 10nm usually.
>
> As it should.
>
>> However, our code
>> seems to be clamping the range to something significantly less than that.
>> I've been poking around in navdb.cxx and navradio.cxx but haven't been able
>> to connect all the dots yet.
>
> The GS range calculation looks OK to me.  It's only a
> couple of lines.
>
>> I don't have personal knowledge of what is correct, but this change to
>> glideslope range impacts our ability to practice ILS approaches and I have a
>> current King Air pilot complaining about the behavior.  Pulling out some old
>> approach plates for KMSP here I see a 14nm distance and 5000' MSL entry
>> altitude (4000'+ AGL) referenced in the approach to 30R.
>
> That's not a correct interpretation of the chart.
> The _localizer_ can be intercepted 18.5 nm from
> the _localizer_ antenna, but that's got little to
> do with the glideslope.  The pilot needs to see
> the glideslope alive at least a little bit before
> JACKO intersection, which is 6.7nm from the DME
> station and therefore something like 5.7nm from
> the GS transmitter.  So there should be miles
> and miles of margin, even if the GS range is
> only 10nm.
>
> To be clear:  Standard procedure is to intercept
> the localizer and fly inbound for a few miles
> without reference to the glideslope until the
> glideslope starts working.  The approach plate
> has series of altitudes to use during this
> phase of the approach.
>
> THere are some approaches that require an ESV
> (expanded service volume) on the GS but there is
> no evidence that KMSP ILS RWY 30R is one of them.
> It does look like the localizer needs a slightly
> expanded service volume, but that's a separate
> issue.
>
>> Is 7-8 miles a
>> realistic range for the glide slope?
>
> No.
>
> The GS should be working at 10+ DME on this
> approach.
>
>> Is my King Air pilot contact smoking
>> something?
>
> The 10nm service volume is an FAA-guaranteed
> minimum.  Due to the nature of the beast, in
> practice the signal is "usually" usable much
> farther out than that ... depending on what
> model of receiver you are using, how clean
> your antenna is, et cetera.
>
> Having the GS suddenly spring to life at exactly
> 10nm from the antenna is not realistic ... but it
> is not tragic.  You could argue that it represents
> worst-case behavior, which has some advantages
> during training.  But it ought to have at least
> some randomness to it, so that wise-guy pilots
> don't treat it as a virtual DME indication.
> Still, this is pretty low down on the priority
> list.  There are dozens and dozens of more serious
> issues to worry about.
>
> ======
>
> Having the GS needle park at zero when the signal
> is out of range is not realistic for the type of
> equipment normally found in King Airs ... although
> it would be typical in older and less fancy equipment.
>
> This is fixable in the xml, but it is a lot easier
> with a little help from navradio.cxx.  I submitted
> a patch to implement proper parking over a year ago.
> It was discarded without explanation.
>
>
> ------------------------------------------------------------------------------
> 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