> 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'.
The only autopilot manual I have at hand (Century III) says:
"The Glideslope Deviation Indicator must be deflected upward for at least 20
seconds before the logic circuit of the Glideslope Coupler is armed. [..]
A 60% full scale deflection for 20 seconds will always accomplish arming."
So, for the A/P, there is no such thing like has-gs, the autopilot only needs
an upward deflection.
>
> 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.
The mentioned behaviour is best visible close to the station. If you move
further out, the movements of the gs-needle get slower and slower.
If you fly level and have your NAV tuned to an ILS station, you catch all the
side lobes - one after another - which causes your GS needle project the
sawtooth function that generates the lobes.
I think the model for the side lobes is to simple. Just generating them all
with the same strength at a 6 degrees period is not enough. However I am not
in the position to complain, because I don't have a better model at hand ;-)
But I can provide a fix for a potential division by zero bug: Some stations
don't have a range configured and bomb here:
double range_exceed_norm = loc_dist/effective_range_m;
Here is a fix for that, setting a range of 25
Index: navradio.cxx
===================================================================
RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/navradio.cxx,v
retrieving revision 1.44
diff -u -p -r1.44 navradio.cxx
--- navradio.cxx 11 Sep 2009 23:05:23 -0000 1.44
+++ navradio.cxx 14 Sep 2009 15:00:44 -0000
@@ -459,6 +459,9 @@ void FGNavRadio::updateReceiver(double d
= adjustNavRange( nav_elev, pos.getElevationM(),
_navaid->get_range() );
}
+ if( effective_range < SGLimitsd::min() )
+ effective_range = FG_NAV_DEFAULT_RANGE;
+
double effective_range_m = effective_range * SG_NM_TO_METER;
//////////////////////////////////////////////////////////
Torsten
------------------------------------------------------------------------------
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
