On 09/14/09 02:38, James Turner wrote: > Two (unrelated) glideslope things: > > 1) I tested making the has-gs property be based upon the GS range > check (leaving aside any discussion of how GS reception range should > be calculated). This is good, because existing panels generally use > has-gs as a 'valid GS signal being received', to un-park / show the > needle/pointer. > > The catch is, most of the flightdirector / autopilot scripts have been > written assuming that when approach mode is *armed*, has-gs is already > true. I.e they don't arm GS holding, if no valid GS is being received > at that point. It feels like this is a genuine problem - depending on > how far out the localiser is captured, and given that you could be > intercepting the localiser from an angle, I *guess* the real-life > equipment wouldn't assume a valid GS signal was being received at that > time. > > What do the real world pilots say? The 'fix' would be to remove the > 'has-gs' flag checks from the various autopilot/flight-director Nasal > scripts, which I'm not exactly thrilled at the prospect of - but it > would make the GS needle/pointer behaviour more correct 'for free'.
Changing all the instruments overnight is indeed an unthrilling prospect. Fortunately there are better ways of fixing the problem. There is nothing real-world pilots can say about the has_gs property. Nothing good, anyway. For many many years, this property has been set according to whether the ground station had a GS transmitter installed, without regard to range, and without regard to the serviceability of the ground station or of the onboard GS receiver. This behavior was not, AFAICT, documented anywhere, except insofar as you could figure out the behavior by reading the code, which some people call crockumentation. This behavior is wildly unrealistic. In the real world, there is no way for onboard instrumentation to know whether the ground station has GS equipment installed, except/unless/until it receives a valid signal. Over the years, to overcome the lack of valid range information about DME and GS signals, instrument designers have been forced to assume that the range of the DME part of a localizer/DME was equal to the localizer range, and similarly to assume that the range of the GS, if installed, was equal to the localizer range. Both assumptions are wildly unrealistic, as has been pointed out several times over the years. I don't recommend changing the behavior of the has_gs property to include range or validity information. That would be a major departure from the crockumented behavior, and would break lots of things. The time-honored way out of situations like this is to leave the old property alone, and introduce a new property with good behavior and good documentation. Specifically, I recommend introducing dme_inrange and gs_inrange properties. The concept of "dme in range" and "gs in range" are meaningful to real world pilots. The concept of "has_gs" is not part of real world pilot vocabulary, and never will be. By bringing up the new properties without disrupting the old property, we avoid the need for a "flag day". Instruments that want to make use of the new inrange information can be taught to do so. They are taught one by one, on a convenient schedule, and in the meantime everything continues to work, no worse than before. The code I wrote in 2007 and rebased in January 2009 to this approach. > 2) Torsten noted the GS signal behaves very erratically below a > certain elevation (above the landing threshold) - on the order of > 100-150ft. I'm going to do some testing to establish the cause (aside > from the dreaded penaltyForNav / double-ended-ILS-runway mess), but I > have a suspicion the false lobes might be a factor. Would it be > reasonable to disable the false lobes below a certain distance to the > GS transmitter (at a guess, something like 1000m?). I know it's an > unpleasant rule to add, but the current GS behaviour makes CAT-III or > auto-land operation impossible, I think. > > I still need to verify that the false lobes are the cause, I don't > necessarily see why they should be. Ninety percent of this erratic behavior is realistic! The other ten percent is a small problem, explained by the fact that real-world GS receivers incorporate a rather heavy low-pass filter ... so if you fly through a region of rapidly-changing signals they mostly average out ... and navradio.cxx has not heretofore implemented such a filter. If you want to add a low-pass filter, that would be a Good Thing. It is going to be needed anyway, if/when we try to construct a decent model of fringe-area behavior. I guarantee you real-world autoland systems do not try to follow the GS signal all the way to the runway. Among other things, they rely on a fancy radar altimeter to judge height during the flare. If existing aircraft have been following the GS signal all the way to the runway, I'd say we have _two_ bugs (unrealistically good GS signal, and unrealistic autoland implementation). ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
