Re: [Flightgear-devel] Glide slope (ILS) range
On Thursday 17 Dec 2009, 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. I see our database lists the GS ranges at 10nm usually. 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. 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. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Thanks, Curt. I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) and most airliners, up to 747s and MD-11s, are lined up on the glideslope by about 7.5 nm out from the threshold. The occasional AN-124s I've seen come in seem to be already on the glideslope quite a bit further out though - I'd estimate they're on the glideslope by the time they're about 10 nm out (I checked the distances using Google Earth). Iirc, when I last simulated these two types of approach at EGSS I was between 2500-3000ft asl (over ground that's about 200ft asl) as I turned in above my home for the more typical airliner approach, and around 4000ft when I got on the glideslope for a straight in approach using the AN-225 to mimic the AN-124s. In view of what seems to happen at EGSS, I would say that the 14nm range 5000ft altitude seem about right. LeeE -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 12/18/2009 12:30 PM, leee wrote: I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) I assume that was supposed to say runway 04 at Stansted. ^^ and most airliners, up to 747s and MD-11s, are lined up on the glideslope by about 7.5 nm out from the threshold. Turn point? Lined up? I thought the topic of this thread was GS range. GS is not the same as LOC. Anecdotes about turning or lining up don't tell us much about the GS. In view of what seems to happen at EGSS, I would say that the 14nm range 5000ft altitude seem about right. According to the authoritative NATS charts, the final approach fix is at 6.6DME which is about 5.5nm from the touchdown zone, and occurs at an altitude of 2500 feet, no higher, no lower. For this approach, GS intercept should occur at the FAF, no earlier, no later. The turn onto the localizer, for a no-vector approach, is 3 or 4 nm farther out than that. The altitude should be 2500 although 3000 might arguably be tolerated. Radar-vector procedures will be somewhat more variable, but not wildly different. Bottom line: The standard 10nm GS service volume should be more than plenty for the EGSS RWY 04 approach. More generally: Limiting the GS service volume to 10nm or thereabouts is a significant departure (if you'll pardon the expression) from previous FGFS behavior, but it is not wrong. It is a feature, not a bug. References: http://www.nats-uk.ead-it.com/aip/current/ad/EGSS/EG_AD_2_EGSS_7-14_en.pdf http://www.nats-uk.ead-it.com/aip/current/ad/EGSS/EG_AD_2_EGSS_8-1_en.pdf = Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. From a user's point of view, and don't this wrong for I'm not sure of the long term goals, but if success includes attracting users and retaining them then the little details such as this will enhance that aspect more than some other things. Realistic flight performance, including operations within the airport radius are typically high in value to a user. This isn't to take the side of someone complaining about not getting the glideslope at full volume until 7 miles, he should be well on his way with a standard decent rate out of the turn point. I think the 10 mile minimum should work fine, until it gets enhanced to extend to a trickle out point, which is the ideal. (And often 20 miles) Is there a published list somewhere of the major issues that the developers contributors are striving to correct, enhance, add, etc? Thanks, Peter Peter Brown FG Farmboy -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 12/18/2009 02:53 PM, John Denker wrote: More generally: Limiting the GS service volume to 10nm or thereabouts is a significant departure (if you'll pardon the expression) from previous FGFS behavior, but it is not wrong. It is a feature, not a bug. Agreed. I often do the ILS rwy 33 approach into KFNL for real for currency maintenance. Often in the procedure turn, the GS flag will activate indicating no usable GS signal. The GS flag may stay until (sometimes after) I start the 45 deg turn to 328 deg inbound on the LOC. This pretty well matches the fgfs GS flag behavior for this approach. Dave P. -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Fri, Dec 18, 2009 at 4:33 PM, Peter Brown pe...@smoothwatersports.comwrote: Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. From a user's point of view, and don't this wrong for I'm not sure of the long term goals, but if success includes attracting users and retaining them then the little details such as this will enhance that aspect more than some other things. Realistic flight performance, including operations within the airport radius are typically high in value to a user. This isn't to take the side of someone complaining about not getting the glideslope at full volume until 7 miles, he should be well on his way with a standard decent rate out of the turn point. I think the 10 mile minimum should work fine, until it gets enhanced to extend to a trickle out point, which is the ideal. (And often 20 miles) Is there a published list somewhere of the major issues that the developers contributors are striving to correct, enhance, add, etc? In this particular case we are building a twin turbo prop simulator (Beech 1900) with a full cockpit, dual controls, and wrap around visual system (based largely on FlightGear.) Glide slope range is something the customer commented on, so that pushes it up my priority queue a bit. There are times when it makes sense to debate the customer's perceptions (gently show them why they are incorrect) but in this case I think 10nm is borderline, although upon further discussion, there were other aspects of what was going on that were indeed more important. So no, this isn't a drop dead issue, but at some point if we boost the default service volumes up by a few percent hopefully people won't get too bent out of shape? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Friday 18 Dec 2009, John Denker wrote: On 12/18/2009 12:30 PM, leee wrote: I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) I assume that was supposed to say runway 04 at Stansted. ^^ Just reporting the number that's painted on it. and most airliners, up to 747s and MD-11s, are lined up on the glideslope by about 7.5 nm out from the threshold. Turn point? Lined up? Pretty obvious, I thought, unless you really want to be pernickty, but you'll have to be pernickty on your own. Unlike you, I'm not trying to make any particular point or criticise anyone... I thought the topic of this thread was GS range. GS is not the same as LOC. Anecdotes about turning or lining up don't tell us much about the GS. ...I'm just offering observational data from real life. Funnily enough, I did so because I thought it might be of help. You just seem to be trying to get your kicks from belittling people though. Hmm... your problem, not mine. LeeE -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 12/18/2009 04:22 PM, leee wrote: I live beneath the turn-in point for clockwise approaches on 05 at Stanstead Airport (EGSS) I assume that was supposed to say runway 04 at Stansted. ^^ Just reporting the number that's painted on it. The number actually painted on it is 04. It's been that way for several months. I know the Google satellite photo says 05. The photo is out of date. I was reporting the correct information in the hope that it would be helpful. -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Glide slope (ILS) range
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. I see our database lists the GS ranges at 10nm usually. 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. 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. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On 17 Dec 2009, at 18:44, Curtis Olson wrote: 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. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Personally, I agree our ranges are very short, however, I *believe* the navradio code is respecting the range specified in nav.dat (often 10nm as you point out). If the code isn't respecting the published range, that's a bug, almost certainly mine, and I'll fix it ASAP. There is a separate issue about whether the GS receiver ought to receive a signal beyond the published range, eg a 20% or 30% margin above what is published. There are arguments against doing that, and arguments for it, and personally I'm not sure. When you look at many approach plates, the GS volume is often quite short. Regards, James -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Thu, Dec 17, 2009 at 1:25 PM, James Turner wrote: On 17 Dec 2009, at 18:44, Curtis Olson wrote: 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. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Personally, I agree our ranges are very short, however, I *believe* the navradio code is respecting the range specified in nav.dat (often 10nm as you point out). If the code isn't respecting the published range, that's a bug, almost certainly mine, and I'll fix it ASAP. There is a separate issue about whether the GS receiver ought to receive a signal beyond the published range, eg a 20% or 30% margin above what is published. There are arguments against doing that, and arguments for it, and personally I'm not sure. When you look at many approach plates, the GS volume is often quite short. Hi James (Hi John), I will try to get a more detailed bug report. As I've been looking more closely here, I am seeing the glide slope come alive right at 10nm on the two approaches I have tested, which would mean that the code appears to be doing what we ask of it, since most of the glide slope transmitters are marked as 10nm range. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
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
