Like so many others, I've found the default FS autopilot to be inadequate in many areas and have written (most) of my own. The one part that I am having serious trouble with is localiser interception. The problem I have is that I don't seem to be able to calculate how get the aircraft to turn out on the centreline. I suspect that I'm missing a bit of Pythagoras i.e. the distance from the aircraft to the localiser centreline where a=unknown distance, b=the localiser centreline and c=the aircraft interception angle. It's obvious that a + airspeed + interception angle are going to determine the bank angle at any given time but how do I calculate a?Can anyone please help? -Dai

Hi,Quick guess,If you have DME to the station, present heading and localizer course, then you have 2 angles and one side.Now you can calculate the other sides and angles with sin- and cosinus rules.No DME, no solution(?); may be you can also make use of the cdi, full deflection is > 0.3 nm.example: HDG=060CRS=090DME=20Then x: x/sin 60=DME/sin 90 or x/1/2=DME/1 or x=DME/2=10Jan

Hi JanI think you've just turned on a very bright light. Does this make sense to you (taken from Ed Williams Aviation Formulary)? He's talking about spherical triangles which is what I think we're talking about here.

     c  B-----A  |    /  |a  /b  |  /  | /  |/  C Given {a,B,C}  // Two angles, included sideA=acos(-cos(B)*cos(C)+sin(B)*sin(C)*cos(a))b=atan2(sin(a)*sin(B)*sin(C),cos(B)+cos(C)*cos(A))c=atan2(sin(a)*sin(B)*sin(C),cos(C)+cos(A)*cos(B))

-Dai

Dai,You can use that great circle calcs, but that formulas are for big distances where you have to take in account for the form of our globe.For your goal probably Euclidian maths (example of sinus rule i gave) is enough.Jan

Hi,I agree with Jan, that if the localiser has a DME, it's rather trivial.If not, two other options are:1. If you can readout the coordinates of the Localiser, it's easy as well.Have several examples in XML how to calculate headings and distances given two sets of coordinates.2. If no Localiser coordinates available:You can create you own DME, by using change-in-CDI-value per timeunit, which of course depends on airspeed, intercept angle and distance from the Localiser. Less accurate though.Rob

Got it - so we're looking at the ASA method. One last question (again, in ignorance), given the expression 'B sin a' how is it evaluated? B * sin aB / sin aB - sin aB + sin a?Or something else entirely?-Dai

Dai,Think the first, B * sin a. Jan

Thanks Jan!!!-Dai

One thing to remember though is that not all localizer areas are the same size. So to use the change in offset and time with DME will not always result in the same distance away from centerline. From the Aeronautical Information Manual:"2.The localizer signal is transmitted at the far end of the runway. It is adjusted for a course width of (full scale fly-left to a full scale fly-right) of 700 feet at the runway threshold. "So simply put if you have a short runway you will have a wider beam area to get the 700 feet at the threshold. If it is longer then the beam area is more narrow.This triangle formula only works with VOR navigation where the beams are always the same size. ie. 1 NM wide at a distance of 60 NM from the VOR.

Just to add -- Not all localizers are centered, KOSH 36 for one ( In real life) , there are many more. Roman

Dai,Have you tried (A:GPS WP CROSSTRK, feet) ?I don't know if it works with an ILS track (that is, when aircraft navigation is controlled by NAV rather than GPS) or if it is really what you need, but in the xml world, I might give it a shot as it could turn out to be a simple way to get distance to localizer center line. If you're lucky, anyway.GPS WP CROSSTRK - distance the aircraft is from the desired flight path track, measured perpendicular to the desired flight path (I believe). A/C positions left of the desired flight path are positive Cross Track values and right of the desired flight path are negative. Is it an option to get into the gps database for distances? All the ILS's have Lat, Lon's in the gps database that can be used to calculate horizontal distance and if one of the airport altitudes is pulled, then slant line DME distance, too.Hope this helps,BobRegarding real world - from the small sample of fs9gps ILS's I've seen, all are indeed located beyond the far end of the approach runway. As Roman indicates, some may also be offset from runway center line. Beyond that, if it were me, I'd hesitate expecting too much real world behavior given the simulation and database capacity of FS without trial and error testing.

Assuming the SDK is correct, this panel variable should give the distance to the ILS:HSI DISTANCEThen it's trigonometry from there...Hope this helps,

Just to add -- Not all localizers are centered, KOSH 36 for one ( In real life) , there are many more. Roman

It's a good way to test if the students are cheating and peaking from under the hood. We have one here that is offset by about 10 degrees. You know the ones that are cheating because they keep trying to line up with the actual runway and not the localizer :( :(

@All who responded:I have no idea if FS models offset LOCs but I'm using the following to plug in to the calculation:-sideC = (A:NAV DME:1,nautical miles)beta = abs((A:NAV LOCALIZER:1,degrees)-(A:PLANE HEADING DEGREES TRUE,degrees))gamma is being ignored as sin 90 is always 1.-which, of course, now I come to look at it after a couple of days I realise is completely the wrong calculation. It assumes that the aircraft is heading directly for the DME when it isn't. It is headed for a point X somewhere on the localiser and the actual position of point X depends on the interception angle of the aircraft. Back to square one or rather, back to trying to figure out when to turn into the localiser based on how quickly the FS LOC data (-127 to 127) is counting down.I'm trying to avoid the use of any of the GPS vars but it may come to that. I'm still open to suggestions on how to best to solve this problem. If MS had programmed the LOC capture routine so that it didn't have that ridiculous tendancy to start a right turn when it should be turning left, none of us would be here :( -Dai

@All who responded:I have no idea if FS models offset LOCs but I'm using the following to plug in to the calculation:-sideC = (A:NAV DME:1,nautical miles)beta = abs((A:NAV LOCALIZER:1,degrees)-(A:PLANE HEADING DEGREES TRUE,degrees))gamma is being ignored as sin 90 is always 1.-which, of course, now I come to look at it after a couple of days I realise is completely the wrong calculation. It assumes that the aircraft is heading directly for the DME when it isn't. It is headed for a point X somewhere on the localiser and the actual position of point X depends on the interception angle of the aircraft. Back to square one or rather, back to trying to figure out when to turn into the localiser based on how quickly the FS LOC data (-127 to 127) is counting down.I'm trying to avoid the use of any of the GPS vars but it may come to that. I'm still open to suggestions on how to best to solve this problem. If MS had programmed the LOC capture routine so that it didn't have that ridiculous tendancy to start a right turn when it should be turning left, none of us would be here :( -Dai

EDIT: Oops, see next post ..