ILS and Afcad

Afcad's a great program, but I noticed that after adding ILS to a runway, the tower still calls all approaches visual. The ILS systems are there, and you can use them, but the tower seems to ignore them.
I've tried changing the weather and time-of-day, but still no recognition.
I even decompiled the AF2 bgl to see if there was anything that needed adjustment (not that I'd know what I was looking for anyway), and the ILS systems are listed in the XML.
(BTW, when I decompiled the AF2, I couldn't recompile with BGLComp which seems a bit strange! I know it was listing errors, but they went by so fast I almost had a seizure. Good thing I always use a copy heh heh!)
No really big deal, but does anyone know how to get ATC to realize that there are ILS systems that the runways can use?

Rgds: Jeff

You need to program approaches as well for the runway and AFCAD does not allow you to do that. So you will have to do that with some handwritten XML code. I think there are some examples for this on the forum already.

Hi Arno:
I tried searching the forum, but no luck finding anything. Is there a tutorial or some such available that you know of?

Rgds: Jeff

Hi Jeff,

Must have been on AvSim then, can't always remember .

A quick search there resulted in this thread for example:

http://forums.avsim.net/dcboard.php...ic_id=23666&mesg_id=23666&listing_type=search

Hi Arno:
Thanks for the link, I followed it along and finally read the pertinent information in the BGLComp SDK, so that should be enough for me to get the job done.
Thanks again. You must be a superman to do everything that you do and still find some time to answer our posts!

Rgds: Jeff

Jeff,
Below is another example of writing an ILS-approach in XML with additional instructions. Jim Vile (a well known afcad-guru at the PAI-afcad forum) wrote it and I made a small change in the syntax of the xml-code, to get it working (with the approval of Jim). You can find the complete thread in which Jim published this example and more do's and dont's about afcad, approach and ILS with this address as a start: http://www.flightsimmer.com/forums/showthread.php?t=25733&highlight=bruin)

Hope this helps,
Bert

===================================

The example XML at the bottom is the minimum you need for ATC to understand and use a new ILS runway.

You can use it as a model and change all the pertinent info to write your own ILS-approach.

Use AFCAD to set up the ILS and name the Ident. You will need this for the XML.

You need a new outermarker (VEWES in the example) and will have to make one up. Use AFCAD to get the coords by placing a fictious outermarker symbol (4 to 5 miles) from your runway then read the coord and make that the waypoint info.

Do the same thing for the IAF which is CF26 in the example. Because I assume you are making this up and it is not a published plate set your IAF about 15 to 20 miles from the threshold of your runway (closer if you want the plane to turn in sooner).

Fiqure the rho from the end of the runway and not the threshold. Example

If your runway is 10,560ft. or 2 miles long and IAF is 15 miles from threshold that = 17 miles

17 / .00054 is equal to a rho of 31481.4810

theta is the recip of your runway.

Make sure you have 2 new waypoints (minimum) at the bottom of the XML when you are done.

Below is the minimum xml-code for an instrument-approach:

<?xml version="1.0"?>

<FSData version="9.0"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd">

<Airport ident="xxxx" // your airport-data , the same as in the afcad
region=""
country="xxxx"
state="xxxx"
city="xxxx"
name="xxxx"
lat="N19 43.21583" //your airport-lat
lon="W155 2.90817" //your airport-lon
alt="11.58M" //your airport-alt
magvar="349.50"> //your airport-magvar

<Approach type="ILS" runway="26" suffix="0" //your runway,, etc
gpsOverlay="FALSE"
designator="NONE"
fixType="TERMINAL_WAYPOINT"
fixRegion="PH"
fixIdent="VEWES"
altitude="1799.978F"
heading="270.05"
missedAltitude="2999.964F">

<ApproachLegs>
<Leg type="IF"
altitude1="1799.978F"
altitude2="1799.978F"
altitudeDescriptor="A"
theta="79.0000"
rho="29269.0859"
fixType="TERMINAL_WAYPOINT"
fixIdent="CF26"
fixRegion="PH"
recommendedType="LOCALIZER"
recommendedIdent="IITO" />
</ApproachLegs>

<MissedApproachLegs>
<Leg type="CA"
altitude1="449.995F"
altitudeDescriptor="+"
magneticCourse="259.00"
turnDirection="E" />
</MissedApproachLegs>
</Approach>


//Waypoints go here: Example

<Waypoint
lat="19.721300"
lon="-154.922619"
waypointType="NAMED"
magvar="-9.90"
waypointRegion="PH"
waypointIdent="VEWES" />

<Waypoint
lat="19.721180"
lon="-154.781633"
waypointType="UNNAMED"
magvar="-9.90"
waypointRegion="PH"
waypointIdent="CF26" />

</Airport>
</FSData>

Thank you Bert.
I followed your link to avsim and found an abundance of information, more than I can assimilate at one sitting but hopefully not more than I can learn over the course of time.
Didn't someone once say 'Realizing how much you DON'T know is the first step on the path to wisdom'!
Your example XML is certainly that first step that I need to understanding.
Just a couple of questions if you don't mind though. I can understand rho as an equation and I can understand theta as the recip. (eg: 180-360) of your runway heading, but I wondered if it might be more practical to actually add outer, middle, and inner marker beacons using Afcad and use them as waypoints. If they have to be redefined in the XML then I wouldn't bother, but if they can be read as waypoints by the <Approachx> coding then I might do it that way. Is this practical or not?
I also noticed that you put altitude variables in xxxxF(I presume this means feet), while the BGLComp SDK instructs you to use metres. Even though I have no trouble thinking metric (being Canadian), converting is a pain and since most of the time while working on a project for FS9 I use feet anyway, is it alright to use xxxxF as a valid variable in the XML coding?


Rgds: Jeff

Hi Jeff,
Yes it's a great amound of information I referred to. Take your time trying to understand it all. Someone else than your source once said that "a long voyage always begins with a first step". Bon voyage.

Using markers/waypoints from the afcad-file only:
I never tried it, but I don't think that will work, because Jim also found out that, when starting fs9, the program has to read the approach.bgl after reading the stock afcad and before reading your "home-made" afcad.
Only when reading the files in this order, ATC will recognize the approach-data.
So I assume that if your markers/waypoints are only defined in your home-made afcad (the third file to read), fs9 will recognize the approach.bgl (the second one to read) as "incomplete" and ignore the approach-data. I even wonder if bglcomp will accept the "incomplete" approach.xml while trying to compile it to the approach.bgl.

The proper way to make fs9 to read the files in the wanted order is to place the approach.bgl in the folder scenery/generic/scenery and the home-made afcad in the addon scenery-folder.
There are other ways to accomplish it, but I prefer the method above, because this method has the advantage that afcad221 don't recognize the approach.bgl as an afcad.file.

On the other hand, as Jim explained in his example, you can use the data from defined markers in the home-made afcad to define the needed waypoints in the approach.bgl.

Using Feet instead of Meters:
That's not a problem. Look for example at afcad221. In there you can even choose between working in feet or in meters.

Bert

Hi Bert:

Thanks again. I was under the impression that 'addon scenery' always superceded 'scenery/world/scenery' files, being on a higher 'chain of command' so to speak. Glad you straightened me out before I did something wrong!
As for altitude format, I'm still a bit confused. You're right of course, Afcad seems to be able to understand both feet and metres, but it handles metres as 'xxm' while feet are listed as a variable without an ident. letter eg. '12500'.
In your example the alt. listings are in feet with an 'F' identifier tacked onto the end.
I wouldn't want to get this part incorrect! FL 3000 here we go!

Rgds: Jeff

Jeff,
Just to make sure you got it right: I did not mention "scenery/world/scenery" as the place to put in the approach.bgl, but "scenery/generic /scenery.

Further:
I looked into several well-working bgl's, made by afcad, which I decompiled to xml to examine the source-code. I also looked into xml.files from Jim of which I know he wrote them in xml "by hand", without using afcad.
In all those xml.files the alt-identifiers are completed with "F" or "M".
In some cases I saw in the same xml.file some altitudes with "M" and others with "F".

Personally I find it convenient to see those ident-letters in my source files, so for me your question is not an issue.
But if it's important for you to know what happens when leaving out the alt.ident-letters of course you can experiment with it in your xml and see how bglcomp and/or FS handles that. That's part of learning to understand how things work and it helps you to find your own way of xml-programming.

Hope this helps

Bert

Hi Bert:
Oops, sorry about that. I don't know why my fingers typed 'world' instead of 'generic', but I won't make that mistake after compiling.
And thanks for taking the time to check things out for me, I don't have any other approach bgl's to decompile to see if the idents. are there or not, but I'll instead bow to your greater wisdom and use them in the code as required.

Thanks Again: Jeff

OK, still having problems with the ILS-ATC connection on this one. I compiled the following XML and placed it in the scenery/generic/scenery folder and everything seemed to work, kinda.
ILS is available as an approach option by the AI ATC, and says to expect vectors for landing ILS on 25R, but instead sends me cruising up the BC coastline in the general direction of the North Pole (or Alaska). I haven't actually flown the complete distance, becoming disgusted after being sent 150 mi. north of my original destination.
Anyone have any idea what's wrong?

<?xml version="1.0"?>

<FSData version="9.0"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd">

<Airport ident="CPAW"
region="North America"
country="Canada"
state="British Columbia"
city="Qualicum Beach"
name="CPAir West"
lat="N49.312402"
lon="W124.485846"
alt="83M"
magvar="0.00">

<Approach type="ILS" runway="25" suffix="0"
gpsOverlay="FALSE"
designator="RIGHT"
fixType="TERMINAL_WAYPOINT"
fixRegion="CY"
fixIdent="INNR"
altitude="1500.000F"
heading="250.00"
missedAltitude="2500.000F">

<ApproachLegs>
<Leg type="IF"
altitude1="1500.000F"
altitude2="1500.000 F"
altitudeDescriptor="A"
theta="70.0000"
rho="34814.814"
fixType="TERMINAL_WAYPOINT"
fixIdent="OUTR"
fixRegion="CY"
recommendedType="LOCALIZER"
recommendedIdent="IITO" />
</ApproachLegs>

<MissedApproachLegs>
<Leg type="CA"
altitude1="450.000F"
altitudeDescriptor="+"
magneticCourse="250.00"
turnDirection="N" />
</MissedApproachLegs>
</Approach>

<Waypoint
lat="49.188088"
lon="124.195670"
waypointType="FAF"
magvar="0.00"
waypointRegion="CY"
waypointIdent="INNR" />

<Waypoint
lat="49.193920"
lon="124.014701"
waypointType="IAF"
magvar="0.00"
waypointRegion="CY"
waypointIdent="OUTR" />

</Airport>
</FSData>

Hi Jeff,
Does that happen every time you tried it?

A max of 50nm before ATC talks you "in" on approach-course is normal.
What could have been the matter, is that there was too much AI-traffic trying to land on your ILS-runway at the same time.
Try the same approach with the traffic-slider to zero and see if you get the same results.
Another thing is that you should correctly follow the descend-orders ATC gives you. ATC evaluates your height at several points during approach-procedure. If you are too high at a point-of-evaluation, ATC "forgets" to talk you in and leaves you straigt out.

I had a quick look and the only strange thing I saw in your approach.bgl so far are the names of the waypoint-types (at the bottom of the xml). If the above-approach does not work you could try the type-names as placed in the example and see what happens.

If the result of that is also negative, you can send me the afcad.bgl and the approach.bgl you made, then I can have a closer look at "the whole picture".
bruin.b@home.nl


Bert
Bert

Hi Bert:
Yep, it happens every time! There's no conflict with AI traffic 'cause I haven't added it yet, and the ATC dosn't give me any descent orders at all. The AI ATC just keeps sending me north on course 300 deg. or thereabouts and keeps bouncing my altitude up and down to clear the mountains along the way, even though, as I said, it's told me to expect vectors for landing ILS. I left the example type names in the txt file originally but had the same problem. The only reason I changed them was to see if it would make a difference. Nope!

Rgds: Jeff

After looking at Jeff's approach.bgl and afcad I sent him following mail:

I found what caused the trouble. It's in both waypointlocations.
Firstly: to provide you from sleepless nights any further: always use "N" or "S" when defining lat and "E" of "W" when defining lon.
In your example the waypoint-lon's are defined as 124 11.74020 (innr) and 124 0.88206 (outr).
These lon-notations bglcomp reads as E124 etc, while you need W124.

Secondly: (when you have corrected the above in your approach-file), slew around CPAW with the GPS at 10nm, and you can see in the GPS-screen that the waypoints you defined are not in a straight line with the runway, but far to much to the left.

I've found some better locations for them using the afcad in which I temporarly made two outer markers for 25R, one at 4nm and one at 8nm from the threshold. The locations afcad made for them I used for defining the waypoint-locations in my xml. After that the outer markers are of no use anymore so I deleted them them from the afcad.
For testing I used the default Beechcraft-Baron in an IFR-flight from CBS8 to CPAW. With my waypoint-locations it worked properly (several times).

Here is the xml-code for the waypoints I tested and appeared to be oke:

<Waypoint waypointType="IAF"
waypointRegion="CY"
waypointIdent="OUTR"
lat="N49 18.80882"
lon="W124 12.19180"
magvar="0.00">
</Waypoint>

<Waypoint waypointType="FAF"
waypointRegion="CY"
waypointIdent="INNR"
lat="N49 18.80882"
lon="W124 12.37970"
magvar="0.00">
</Waypoint>

I did not recalculate the rho, but the approach works anyway with these waypoints. But If you want the rho to be correct: the distance of "INNR" to the threshold is 4nm.
If you find the turn to final approach is too far off the runway, you can fool around a bit by placing the "outr" somewhat closer to the "innr" and maybe even the "innr" to the threshold, but mind the descent-rate.

Thought I'd mention it here also to provide other readers of this thread.

Bert

Compilation Error

Hello. I continue to get

"ERROR: Compilation errors detected, compilation failed! Parse Completed."

in CMD everytime I tried to run bglcomp.exe. Initially thinking it was an XML symantix error, I reviewed my XML and couldn't find an error, or one that I know of anyhow. I even tried copying and pasting the code above into a test.xml to compile and get the same error. Any ideas?

Here is my xml... the ultimate file I'm trying to compile includes some xml from Airport Facilitator X but I have tried doing just the approach section with the same error:


<?xml version="1.0"?>

<FSData>

<Airport ident="KMWS"
region="K5"
country="UNITED STATES"
state="Illinois"
city="Sturgis"
name="Midwest Regional"
lat="N37.6077793166041"
lon="W87.7722439169884"
alt="152.4M"

<Approach type="ILS" runway="32"
gpsOverlay="FALSE"
designator="LEFT"
fixType="TERMINAL_WAYPOINT"
fixRegion="K5"
fixIdent="WM"
altitude="2000.978F"
heading="320.00"
missedAltitude="2999.964F">

<ApproachLegs>
<Leg type="IF"
altitude1="2500.978F"
altitude2="2500.978F"
altitudeDescriptor="A"
theta="79.0000"
rho="29269.0859"
fixType="TERMINAL_WAYPOINT"
fixIdent="WM"
fixRegion="K5"
recommendedType="LOCALIZER"
recommendedIdent="IMWS" />
</ApproachLegs>

<MissedApproachLegs>
<Leg type="CA"
altitude1="449.995F"
altitudeDescriptor="+"
magneticCourse="320.00"
turnDirection="E">
</MissedApproachLegs>
</Approach>

<Approach type="ILS" runway="14"
gpsOverlay="FALSE"
designator="RIGHT"
fixType="TERMINAL_WAYPOINT"
fixRegion="K5"
fixIdent="ZZ"
altitude="2000.978F"
heading="140.00"
missedAltitude="2999.964F">

<ApproachLegs>
<Leg type="IF"
altitude1="2500.978F"
altitude2="2500.978F"
altitudeDescriptor="A"
theta="79.0000"
rho="29269.0859"
fixType="TERMINAL_WAYPOINT"
fixIdent="ZZ"
fixRegion="K5"
recommendedType="LOCALIZER"
recommendedIdent="IMWS" />
</ApproachLegs>

<MissedApproachLegs>
<Leg type="CA"
altitude1="449.995F"
altitudeDescriptor="+"
magneticCourse="140.00"
turnDirection="E">
</MissedApproachLegs>
</Approach>

<Approach type="ILS" runway="14" suffix="0"
gpsOverlay="FALSE" designator="RIGHT" fixType="TERMINAL_WAYPOINT"
fixRegion="K5" fixIdent="ZZ" altitude="670.56"
heading="140.00" missedAltitude="609.60">
<ApproachLegs>
<Leg type="IF"
altitude1="2100.000"
altitude2="2100.000"
altitudeDescriptor="A"
theta="320.0000"
rho="21859.1914"
fixType="TERMINAL_WAYPOINT"
fixIdent="ZZ"
fixRegion="K5"
recommendedType="LOCALIZER"
recommendedIdent="IMWS" />
</ApproachLegs>
<MissedApproachLegs>
<Leg type="CA"
altitude1="449.995"
altitudeDescriptor="+"
magneticCourse="140.00"
turnDirection="E">
</MissedApproachLegs>

<Approach type="ILS" runway="5"
gpsOverlay="FALSE"
designator="RIGHT"
fixType="TERMINAL_WAYPOINT"
fixRegion="K5"
fixIdent="PT"
altitude="2000.978F"
heading="050.00"
missedAltitude="2999.964F">

<ApproachLegs>
<Leg type="IF"
altitude1="2500.978F"
altitude2="2500.978F"
altitudeDescriptor="A"
theta="79.0000"
rho="29269.0859"
fixType="TERMINAL_WAYPOINT"
fixIdent="PT"
fixRegion="K5"
recommendedType="LOCALIZER"
recommendedIdent="IMWT" />
</ApproachLegs>

<MissedApproachLegs>
<Leg type="CA"
altitude1="449.995F"
altitudeDescriptor="+"
magneticCourse="050.00"
turnDirection="E">
</MissedApproachLegs>
</Approach>

<Approach type="ILS" runway="23"
gpsOverlay="FALSE"
designator="LEFT"
fixType="TERMINAL_WAYPOINT"
fixRegion="K5"
fixIdent="PA"
altitude="2000.978F"
heading="230.00"
missedAltitude="2999.964F">

<ApproachLegs>
<Leg type="IF"
altitude1="2500.978F"
altitude2="2500.978F"
altitudeDescriptor="A"
theta="79.0000"
rho="29269.0859"
fixType="TERMINAL_WAYPOINT"
fixIdent="PA"
fixRegion="K5"
recommendedType="LOCALIZER"
recommendedIdent="IMWT">
</ApproachLegs>

<MissedApproachLegs>
<Leg type="CA"
altitude1="449.995F"
altitudeDescriptor="+"
magneticCourse="230.00"
turnDirection="E">
</MissedApproachLegs>
</Approach>

<Waypoint
lat="N37.5434954836965"
lon="W87.6841646432877"
waypointType="NAMED"
magvar="0"
waypointRegion="K5"
waypointIdent="WM" />

<Waypoint
lat="N37.6863200962543"
lon="W87.8356245160103"
waypointType="NAMED"
magvar="0"
waypointRegion="K5"
waypointIdent="ZZ" />

<Waypoint
lat="N37.5728197395802"
lon="W87.854039222002"
waypointType="NAMED"
magvar="0"
waypointRegion="K5"
waypointIdent="PT" />

<Waypoint
lat="N37.6807303726673"
lon="W87.6909555494785"
waypointType="NAMED"
magvar="0"
waypointRegion="K5"
waypointIdent="PA" />

</Airport>
</FSData>

Your approach code is incomplete

There are inconsistencies in the ILS headers because Suffix exsit in some and suffix is missing in others.

Your ILS header and <Leg type="IF" is pointing to the exact same fixIdent.

Each ILS is incomplete because there is no <Leg type="CF" data to tie the ILS to a Runway.

You need a ILS header that defines the FAF

Your Leg IF will then define the IAF

A CF is requited to define the FAF once again

a final CF defines the runway.

Wow, didn't realize so much. I'll try to get that on there. Thanks for the help.