Hi Dai,Here' some other formula's:A few definitions:'a': half the beam-width of the Localizer; i.e. where the LOC-value changes from 0 to 127 (or 0 - -127). Normally this is 1.7 degrees. (I just measured that with my XML distance calculator gauge on several runways in FSX.'b: the value of the FS LOC variable (for simplicity: I only use the pos. part 0 - 127 here)'c': the current angle of intercept between aircraft heading and LOC centerline heading; so 0 means aircraft is on centerline heading (on or parallel to centerline (for simplicity, I assume between 0 and 90 degrees).'x': the shortest distance between the aircraft and the LOC centerline; i.e. via a line from current aircraft position 90 degrees on centerline.''y': DME'z': the distance to the centerline, on the current aircraft heading.'w': the DME value at intercept point, at current aircraft heading.So:-- 'x' = 'b' / 127 * 'y' * sin('a')-- 'z' = 'x' / cos('c')-- 'w' = Sqrt ( 'y'(2) - 'x'(2) ) - Sqrt ( 'z'(2) - 'x'(2) )So given position, airspeed and desired bankangle, it just lacks a formula at which 'x' you should initiate the turn to intercept the centerline with nearly 0 'c'; because that's what you want, right ?I would make this formula adaptive anyway (based on change speed of 'x'), since you also have to take changing winddirection (relative to the aircraft heading) into account.A few sidenotes:Although the formula's above are correct, there are a few shortcuts that will influence it.- DME also includes an altitude component; but at sufficient distance from the runway and normal approach altitude this is negligable.- On most runways I've seen in FS, the DME (if any) isn't located at the Localiser (on or beyond end-of-runway) but at Glideslope position (start-of-runway). But again, at sufficient distance this is negligable.- As said above, not all Localisers are on the runway centerline.- The value of 'a' may not always be 1.7 degrees. Maybe this depends on runway length IRL ?In short: making the perfect Localiser interceptor that works on any ILS, on any airport and for any aircraft isn't as simple as it looks :( In fact, I think one could make a much more accurate (without the shortcuts above) "runway centerline intercept function" based on GPS data for position/altitude of the touchdown point, and not based on the FS Localizer.Succes, Rob

Hi Dai,Here' some other formula's:A few definitions:'a': half the beam-width of the Localizer; i.e. where the LOC-value changes from 0 to 127 (or 0 - -127). Normally this is 1.7 degrees. (I just measured that with my XML distance calculator gauge on several runways in FSX.'b: the value of the FS LOC variable (for simplicity: I only use the pos. part 0 - 127 here)'c': the current angle of intercept between aircraft heading and LOC centerline heading; so 0 means aircraft is on centerline heading (on or parallel to centerline (for simplicity, I assume between 0 and 90 degrees).'x': the shortest distance between the aircraft and the LOC centerline; i.e. via a line from current aircraft position 90 degrees on centerline.''y': DME'z': the distance to the centerline, on the current aircraft heading.'w': the DME value at intercept point, at current aircraft heading.So:-- 'x' = 'b' / 127 * 'y' * sin('a')-- 'z' = 'x' / cos('c')-- 'w' = Sqrt ( 'y'(2) - 'x'(2) ) - Sqrt ( 'z'(2) - 'x'(2) )So given position, airspeed and desired bankangle, it just lacks a formula at which 'x' you should initiate the turn to intercept the centerline with nearly 0 'c'; because that's what you want, right ?I would make this formula adaptive anyway (based on change speed of 'x'), since you also have to take changing winddirection (relative to the aircraft heading) into account.A few sidenotes:Although the formula's above are correct, there are a few shortcuts that will influence it.- DME also includes an altitude component; but at sufficient distance from the runway and normal approach altitude this is negligable.- On most runways I've seen in FS, the DME (if any) isn't located at the Localiser (on or beyond end-of-runway) but at Glideslope position (start-of-runway). But again, at sufficient distance this is negligable.- As said above, not all Localisers are on the runway centerline.- The value of 'a' may not always be 1.7 degrees. Maybe this depends on runway length IRL ?In short: making the perfect Localiser interceptor that works on any ILS, on any airport and for any aircraft isn't as simple as it looks :Big Grin: In fact, I think one could make a much more accurate (without the shortcuts above) "runway centerline intercept function" based on GPS data for position/altitude of the touchdown point, and not based on the FS Localizer.Succes, Rob

I may have misunderstood, but it appears to me that the equations only apply if:a) the aircraft is within the localiser beam, and b) the aircraft is on a converging heading to the centre-line of the localiser beam.

On further thought I'm not sure about the meaning of z = x / cos( c ). Should it not be z = x /sin( c )?

On further thought I'm not sure about the meaning of z = x / cos( c ). Should it not be z = x /sin( c )?

Yep, you are absolute right :( I used the wrong corner .....

...the aircraft is within the localiser beam, and

Yes of course, otherwise the FS LOC variable isn't usefull.Another "limitation", although an automated turn (based on ILS) would normally not be initiated outside the beam; unless you're too close to the Localizer, but then there's something wrong with the approach :(

...the aircraft is on a converging heading to the centre-line of the localiser beam.

Yes; that's why I said "(for simplicity, I assume between 0 and 90 degrees)".Thanks for the correction....Rob

Yep, you are absolute right :( I used the wrong corner .....

We've all done it!

It looks like things are starting to make sense. When trying to figure this initially I completely missed the obvious thing of 'flipping the triangle' so that calculations are made on the 'opposite' side of the beam. I already know which way I have to turn to intercept the required heading based off the heading offset calculation: for anyone else that might find it useful this is it.

#define	RADIANS_TO_DEGREE_FACTOR	(180.0/PI)#define	RAD_TO_DEG(val)(val)*RADIANS_TO_DEGREE_FACTOR//**************************************************************************// Magnetic Heading//**************************************************************************double getHdgMag(){	double data=0;	execute_calculator_code("(A:PLANE HEADING DEGREES MAGNETIC,radians)",&data,NULL,NULL);	return RAD_TO_DEG(data);}//**************************************************************************// Direction of turn//**************************************************************************int ap_turn=0;				//Direction to turn when heading mode engagedint ap_delta=0;				//Closing angle on new heading - 'target' is the required headingint getAPDelta(int target){ 	int delta=0;	delta=target-(int)getHdgMag();	if(delta<-180)delta+=360;	if(delta>180)delta-=360;	if(delta<0)ap_turn=1;		// Left	else if(delta>0)ap_turn=2;	// Right        return abs(delta);}

I use ap_turn=0 to retrigger the calculation, so change the results to suit yourself.The irony is, I had the glideslope capture done and tested with head- and side- wind combinations that were way out of spec within a couple of days. The localiser has kept me occupied for weeks now....-Dai

Success at last (it looks like :(). I have made the assumption that localiser width is going to be 1.7 for every approach, so if you know different for some runways then you'll need to plug a variable in instead.-Dai

// -------------------------------------------------// CDI deflection (+/-127)double NAVCDI(int radio){	double nav_data=0;	if(radio==1)execute_calculator_code("(A:NAV CDI:1,number)",&nav_data,NULL,NULL);	if(radio==2)execute_calculator_code("(A:NAV CDI:2,number)",&nav_data,NULL,NULL);	return nav_data;} // -------------------------------------------------// DME distancedouble NAVDMEDist(int radio){	double nav_data=0;	if(radio==1)execute_calculator_code("(A:NAV DME:1,nautical miles)",&nav_data,NULL,NULL);	if(radio==2)execute_calculator_code("(A:NAV DME:2,nautical miles)",&nav_data,NULL,NULL);	return nav_data;} // --------------------------------------// Aircraft distance from localiser centrelinedouble ap_LocCentreDist=0;double getLocCentreDistance(int radio){	double loc_width=0;	double dme=0;	dme=NAVDMEDist(radio);	loc_width=fabs(NAVCDI(radio));	if(loc_width<127)ap_LocCentreDist=(loc_width/127)*dme*sin(1.7);	else ap_LocCentreDist=0;	return ap_LocCentreDist;}

According to the CompilingBGL SDK, the default beam width is 5 deg. ADE gives me values of 3.0 (EGLL), 3.7 (EGSS), and 4.0 (EGKK) for FSX.

Success at last (it looks like :(). I have made the assumption that localiser width is going to be 1.7 for every approach, so if you know different for some runways then you'll need to plug a variable in instead.-Dai

Hi Dai,Using value 1.7 in your formula, means the Localiser width (Beam width) is 3.4 degrees (double).Seems a good average, given mgh's values .. :( Though I still wonder why they are different for airports in FS (are they different IRL ?? )I got my value from EHAM, calculated from measuered distance to the centerline (that is: where the Loc variable indicates +/- 127) at any distance from the Localiser; from what I measured, appears to be lineair.Pitty though that the specific beam width isn't available as a variable.Rob

Pitty though that the specific beam width isn't available as a variable.Rob

Unless anyone knows how to read a BGL file, short of using something like FSUIPC? No, I thought not <sigh> :( -Dai

Airport Design Editor (ADE 9X) is an excellent free application that gives what you want - Just list the navaids and double-click on the ILS.I don't know where Microsoft got its beam widths from but they are not included in the UK AIP.According the the FSX SDK:VOR1_NEEDLE +127 relates to +2.5 deg if its a localiserHSI_VERTICAL_NEEDLE +1.0 also relates to +2.5 deg if its a localiser.so there should be no need for beam width?I'd also suggent changing the snippet to

if ((loc_width<127) && (loc_width > -127))...

A localizer beam is not something 'made up' or guessed at but rather set by rather specific guidelines. The beam is adjusted so that the width of a full scale deflection of the localizer needle is 700ft at the approach runway threshold. The angular width of the localizer varies between 3 and 6 degrees. The typical width of the full scale deflection is 5*, or 2.5* either side of the centerline. The width will be dictated by runway length since most ILS systems are located at the far end of the runway.

A localizer beam is not something 'made up' or guessed at but rather set by rather specific guidelines. The beam is adjusted so that the width of a full scale deflection of the localizer needle is 700ft at the approach runway threshold. The angular width of the localizer varies between 3 and 6 degrees. The typical width of the full scale deflection is 5*, or 2.5* either side of the centerline. The width will be dictated by runway length since most ILS systems are located at the far end of the runway.

This makes sense, and explains the differences we observe. (and checks out with my EHAM runway I measured).However, one thing puzzles me then.If the angular width of the Loc depends on runway length (or more accurate: the distance between threshold and localizer position), this means that the sensitivity of the algoritme that controls LocHold in an aircraft AP either varies a factor 2, or that algoritme has to know this distance in order to maintain equal sensitivity to Loc. deviations for all airports.Which is it ?Rob

To complicate the situation, the 700 ft width only applies at the threshold if the runway length is greater than 1200m. For shorter runways it applies at a distance of 1050 m ahead of the threshold.

Well, you're talking a 3900' runway... not very long, and I can't think of any in the U.S. that are that short with an ILS approach on it.