• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

ILS Altitude

Messages
85
Country
unitedkingdom
Hi All,

I'm new to ADE and I'm using v1.2 updated to v1.35, when I use the fault finder it gives me a warning that the ILS is not at the same altitude as the runway but I am unable to change the altitude of the ILS, the altitude box is 'greyed out', what am I missing?

LATER:

Ok, found it, I just use the 'Adjust' button :o

I would have simply deleted this thread but I can't find a way to do that.
 
Last edited:
Hi All,

I'm new to ADE and I'm using v1.2 updated to v1.35, when I use the fault finder it gives me a warning that the ILS is not at the same altitude as the runway but I am unable to change the altitude of the ILS, the altitude box is 'greyed out', what am I missing?

LATER:

Ok, found it, I just use the 'Adjust' button :o

I would have simply deleted this thread but I can't find a way to do that.

No worries I will leave it here in case anyone else has the same issue
 
Jon,

If memory serves. I might be wrong but have to ask :)

My ENGM project was made with SDE a long time ago, and is now ADE. ENGM has a flatten that is 207.768 meters. I checked the stock airport, and it is 207.768 meters for all ILS and NDB`s.

A while ago I used the Fault Checker on ENGM, and it told me I had wrong altitudes. Unfortunately I pressed the "Adjust" button.

This ended up with some altitudes now being 207.768 meters, and some being 207.76 meters...in my opinion too big differences regarding ILS and such. And it is not easy to find and adjust an NDB from ADE. So everytime before I upload ENGM, I have to decompile it with BGLtoXML and change all .76 values to .768, then recompile it. The bad thing about this is that I loose those changes in the ADE project. I am not too happy about the ADE altitude checks.

Could you check if ADE "rounds off" decimals after comma from three to one when using the "Adjust" button?

Cheers,
:stirthepo
 
Jon,

If memory serves. I might be wrong but have to ask :)

My ENGM project was made with SDE a long time ago, and is now ADE. ENGM has a flatten that is 207.768 meters. I checked the stock airport, and it is 207.768 meters for all ILS and NDB`s.

A while ago I used the Fault Checker on ENGM, and it told me I had wrong altitudes. Unfortunately I pressed the "Adjust" button.

This ended up with some altitudes now being 207.768 meters, and some being 207.76 meters...in my opinion too big differences regarding ILS and such. And it is not easy to find and adjust an NDB from ADE. So everytime before I upload ENGM, I have to decompile it with BGLtoXML and change all .76 values to .768, then recompile it. The bad thing about this is that I loose those changes in the ADE project. I am not too happy about the ADE altitude checks.

Could you check if ADE "rounds off" decimals after comma from three to one when using the "Adjust" button?

Cheers,
:stirthepo

Will do Andrew although you are talking about 8mm here :eek: which I can't imagine is going to affect much :)
 
8mm is a *huge* difference and I am half German :D Thinking about it, a 8mm lower glideslope won`t kill me.

(Me looking at a plane coming in 8 mm too low) ->->:duck:

:laughing:

Cheers,
:stirthepo
 
8mm is a *huge* difference and I am half German :D Thinking about it, a 8mm lower glideslope won`t kill me.

(Me looking at a plane coming in 8 mm too low) ->->:duck:

:laughing:

Cheers,
:stirthepo

I have heard of precision approaches but this is getting ridiculous :D
 
8mm is a *huge* difference and I am half German Thinking about it, a 8mm lower glideslope won`t kill me.

(Me looking at a plane coming in 8 mm too low) ->->

I take that to mean you are watching the AI Planes land.

AI Planes and a ILS for a runway have nothing in common. AI Planes fly the Approach code ILS and not a runway ILS.
 
So Jim,

So if I create an airport in ADE(in which I can't write an approach code, yet,) and I don't give it an ILS code, than AI will still land there? I may be running on half a memory stick here, but I thought in FS9,all AFCAD wanted was a runway ILS for AI to land. Is FSX different? I don't have approach codes for any of my own airports and AI land.

Bob
 
Has anyone ever tested the effect of changing the elevation for navaids aside from glideslope? I haven't looked at it in full detail, but on the airport I am currently working on (RKSI) I put the glideslope antenna in the RW position lat/long. ADE defaults the antenna height to a single ILS height = runway height. In testing, that resulted in a TCH (threshold crossing height) of 80 ft -- too high. I lowered the glideslope antenna in the xml (no way to do in ADE I don't think) to get the TCH to 55 ft which I think is the norm at large airports. I notice that when I do this, the PAPI lights are all red. I'm not sure if that is a real problem or not. I know a lot of charts have notation that "VGSI not coincident".

I don't know if adjusting the GS is a good idea or not. Guess I will experiment some while testing my airport.

scott s.
.
 
So if I create an airport in ADE(in which I can't write an approach code, yet,) and I don't give it an ILS code, than AI will still land there?
Yes, most small airfields have no ILS.

ILS height = runway height. In testing, that resulted in a TCH (threshold crossing height) of 80 ft -- too high.
Do you mean AI? If so, it is dependent on the flight dynamics.

George
 
Jim,

I have been watching AI planes land, but that relates to another study regarding go-arounds at ENGM. "Me ducking watching planes coming in" was just a joke. Thanks for the info about AI / approach code. Makes sense as many small airports does not have the high fidelity navaids, but I guess they still should get some AI traffic flying the approaches.

Scott,

Have not tested different elevations for navaids, but I have lenghtened a few runways. When I lengthen a runway I have to readjust the GS and PAPI for that approach of course. I use the Baron to fly the approach after each adjustment until the PAPI and GS tells me the same thing all the way down to the runway. There are exceptions, at ENTC the PAPI does *not* "stay with" the GS according to the official papers. So one should not always trim the PAPI to line up with the GS.

Anyway it is interesting what you mention about the TCH. Adjusting GS positions have not given me trouble yet. I am still not fully confident in what FS can do to me if I touch the altitudes, so I don`t :scratchch

(Except from those 8mm at ENGM) :D

Cheers,
:stirthepo
 
Glide Slope and DME must be at airport elevation (not localizer). However Localizer elevation sets the GS and DME automactically for you.

If you set the GS below ground elevation based on a 3.00 degree slope the User Plane will fly into the ground. If you set the GS above the airport elevation based on the 3.00 degree slope the User airplane will land long.

DME also has a degree angle slope factor so if you overfly a DME at FL280 it reads the altitude height as well.

FS has a built in fallback set of hard code approach instructions if a XML approach is not found in the database. There is a set of hard instructions for AI/User Planes on a VFR FP and a hard set of instructions for a AI/User plane on a IFR FP. Now for IFR FP the Weather Engine also becomes a factor based on if the airport IMC vs VMC.

The problem with many AI planes as George pointed out fly on their flight dynamics. Many AI are only tested for a airport that has a ILS set of instructions written in the approach database. These same AI planes cannot fly a non-ILS approach because they are fallen back onto the approach .dll hardcode. When we ask for a AI Plane set of FD's that can fly curved approaches, hard coded .dll's VORDME's, NDB's etc (based on weather engine) our request falls on deaf ears due impart to FD designers not understanding how FS works. As long as their AI Plane lands on a default ILS written set of approach instructions they think everything is fine.

There is a workable fix so if your 8mm difference bothers you too much but it is not enough to see any issues both visual or non-visual.
 
Last edited:
I put the glideslope antenna in the RW position lat/long. ADE defaults the antenna height to a single ILS height = runway height. In testing, that resulted in a TCH (threshold crossing height) of 80 ft -- too high.

Scott

Placing the GS at the published Lat/Lon is not the best way to do it. The GS reference point centers on the LAT/LON but the point of the GS is what the User plane reads. Tweak the GS back/forth which will decrease the TCH down to the 50 to 55 ft published value.

You can use the Lat/Lon to position the GUID antenna but then place the point of the GS (Glideslope) green feather symbol to get a desired threshold altitude. That way you are backing into the GS position to give the plane a proper GP (Glide Path + Slotted) that it fly's from the FAF to the TCH.


I know a lot of charts have notation that "VGSI not coincident".

that is a very good point and most Users think the GS is the same as the VGSI but it is not at many airports.
 
Last edited:
So Jim,

So if I create an airport in ADE(in which I can't write an approach code, yet,) and I don't give it an ILS code, than AI will still land there? I may be running on half a memory stick here, but I thought in FS9,all AFCAD wanted was a runway ILS for AI to land. Is FSX different? I don't have approach codes for any of my own airports and AI land.

Bob

I just read this.

Lets address FS9 AFCAD and FSX ADE. Both FS9 and FSX use the AFCAD or ADE for ground movement only. That is to say all the lines that we see are for the plane once it lands and do not have any effect on a airplane approaching or touching down on a runway. The approach ILS code if present is used (not present then a fallback) to align the AI Plane flying to the center line and a touchdown point of the runway texture. The runway texture is the go between so the arrival AI plane transitions from flyable to on ground moving behavior.

I know many will argue with the runway texture because some set a runway to zero width thinking no texture exist. However, ACES has confirmed that there is no such thing has a zero width runway texture but zero is always .001 width when processed by the .dll. If there was no runway texture listed in the XML and zero meant zero then the AI plane cannot transition between flying and wheels on ground where AFCAD/ADE take command.

There is a pecking order used for the AI Plane (see below) because it fly's on coded data unlike a User Plane. The AI is contantly getting desired instructions in code vs what is actually happening and sent back to the desired for changes which is a closed loop system. A set of FD's should be ideal based on what FS says but many designers use a lesser empty weight vs actual to manage the flyability characteristics. This in turn causes other problems because the FD's are fighting the desired vs actual code and some AI planes fall out of the sky and taxi on the ground to a runway (that is a 2 fold problem).

The perfect world says all airports have at least one set of ILS instructions written in the database which then FS try's to use that runway as the default based on a scoring system.

A ILS runway and approach code is the only clear weather approach that FS9 and FSX knows. That means regardless of weather the Approach Code ILS XML instructions always take precedence over the hard code .dll instructions. That also means a poorly written set of FD's that the AI plane has is getting some help in order to fly the ILS written XML approach code in both VMC and IMC airport conditions.

Now that same AI Plane may just fall out of the sky on approach if for some reason (fair weather) ATC assigns a runway with a lower score (no ILS approach code) and the AI fallback on the hardcode .dll approach. That code is not very forgiving and the AI Planes FD's better be able to handle the no ILS XML approach code.

So FS rules for IFR Flightplan

1. If a ILS exist in the XML approach code then that takes precedence (over the default .dll) giving the AI a written set of instructions for vectors to final headings, descent altitude for the FAF, the Glidepath degree slope, trigger points for contacting Tower, missed approach turn direction, etc. It does not matter what weather is (IMC or VMC) the ILS approach code always wins.

2. If weather is clear (VMC rules apply) and a lower score runway becomes the default (no-ILS approach code) based on winds then FS has to use a defualt .dll set of instructions for the Transition from flyable to wheel on ground (reads the contact point structure).

Because there is no ILS approach code in XML the AI Plane must rely solely on a hardcode that vectors to final headings (based on true runway heading), a default 2000 ft AGL for a no FAF T_waypoint, a glidepath calculated from the runway texture touchdown point, no triggers except a hardcode rho value from touchdown, a missed approach turn to either side, etc.

Many AI Planes are never tested by the designer for a clear weather no ILS approach code in the database. If they did they would see sink rates (geardown in a turn to final) can cause a AI Plane to start descending (no written hardfloor altitude)and not reach a runway or even overfly a runway and go missed all the time.

3. Only when weather is IMC (below minimums) and I will say it again. Only when weather is below minimums does ATC go looking for additional approach code in the database. All the various type approaches (LDA, Localizer only, Backcourse, GPS, RNAV, VOR and NDB's (with or without DME) will be used in a pecking system by ATC and the AI Plane to seek a set of written instructions for the desired vs the actual.

That means if no ILS exist and weather is below minimums then ATC reverts to a pecking order of approach codes. A LDA is second in priority and a NDB is last in priority. ATC looks at the weather then looks for an approach code if no ILS exist for that runway and uses the pecking order to capture the written set of instructions for the AI Plane. If both a LDA and a NDB exist in the code ATC will instruct the AI to fly the LDA approach over the NDB. If a NDB approach is the only one that exist then ATC will tell the AI Plane and the User to fly the NDB approach as per the written XML.

Any written XML approach is better then the default hardcode approach for the AI Plane because in the XML there are needed hardfloors to always seek back to if the AI sink rate cannot recover back to the actual altitude vs the desired altitude.

If you see a AI plane that cannot land properly in clear weather (no ILS) then set your airport to IMC if other approaches by default exist. ATC will then revert out of the hardcoded .dll and use the XML written instructions. We see bad AI plane behavior at airports like TNCM because RWY 09 is not a ILS to work off of. Many complain that the AI land short in the ocean or cannot get down at all to land. Set the weather to IMC at TNCM and the AI plane will now fly a coded XML for the VORDME approach. This gives it a fighting chance to fly a better code. This helps to illustrate that many AI Planes are designed with poor FD's and the weather related VORDME approach code is much better then a visual hardcode approach.

Probably more the you wanted to know but it might also benefit others that read you ILS altitude concerns.
 
Thanks,Jim

That helps explain a freeware stealth bomber that I downloaded. When I tried to use it as an AI plane, it never made it to the runway. It landed a couple miles short and plowed along underground with just the tail showing for another mile and then vanished. That was on a clear day with ILS. Any Idea why the default Piper just wanders around as an AI plane?
Anyway, thanks for you answer. Anyone thinking about putting out a good airport and AI manual?

Bob
 
If you set the GS below ground elevation based on a 3.00 degree slope the User Plane will fly into the ground. If you set the GS above the airport elevation based on the 3.00 degree slope the User airplane will land long.

Did some investigation, here are my conclusions:

MS models the GS as an image-type system, i.e., signal "centerline" appears to come from the base of the GS antenna (in image system the ground plane is used to reflect the signals).

For a nominal 3.00 degree glideslope that means the GS antenna must be about 325 m from the threshold centerline to give a 55 ft TCH (FAA spec for runways handling large commercial aircraft). That works out to about 300 m down the runway, with a nominal 400 ft abeam antenna location (FAA spec). RL antenna location will vary based on terrain. For FS, I think maybe the best practice might be to leave the antenna at nominal field elevation and move it onto the 325m arc at an appropriate lateral distance from centerline (350-400 or so ft). The "checkershed" object can then be placed in the actual antenna location (if different). This may require the DME to be offset some from the GS antenna (ie., placed at RL surface position but it probably isn't a significant factor with DME read out to only +/- 0.1 nm.

In attached shot GS antenna has been moved slightly to achieve 325m distance.

scott s.
.
 
Last edited:
Any Idea why the default Piper just wanders around as an AI plane?

Bob

What I see is the small FSX GA planes cannot track very well on the ground based on the weight, winds and ground speed. That causes them to wander around.


Scott

That is a excellent conclusion. I visually place the GS point at the touchdown bars which always gets me close enough for the TCH.

If we add a ILS with ADE the GS defaults to the mid point of the runway. Jon is looking at a better way to code a new GS position.

I normally place the DME transmitter at either end of the runway off to the side a small amount. That is about the only 2 places that works. DME antennas can be placed anywhere in real world and calibrated for 0 even when it is not on the airport. The approach chart will show if 0 DME is at the threshold or at the end of a runway. FS normally sets the DME at the tip of the GS for 0 threshold and at the tip of the Localizer for 0 distance at end of runway. FS does not use the actual published Lat/Lon for setting the DME antenna in some cases because of the real world calibration.
 
Last edited:
That is what I did based on tips from here, placed the GS transmitter around 325 meters from threshold centerline or aligned with those stripes. When finished with test flying, I then placed the checkershed for visual hifi only.

Thanks for the heads up on AI planes. I got Ultimate Traffic X which was not made from the start for FSX, only "ported" from FS9. I can clearly (to put it mildly) see there is a lot to whish for. With Traffic set to 93%, I got a lot of go-arounds at ENGM since those AI guys are coming in too close to each other. Go-arounds are also caused by planes already landed, taxiing and leaving exits in such a stupid way that the runway gets "busy" much more than it should be for the incoming guys. Obviously there is not a very good FD present, and I am also starting to wonder what the heck ATC is telling them do do now and then. Even the ground vehicles are quite bizarre, and I found it safest to use a lot of time to route them as on the real airport, making dedicated roads for them along the terminal buildings and separate roads beside the taxiways. This is very important to do at larger airports as conflicts arise fast if you have your traffic sliders up high. I also found it best to keep the slider for ground vehicles at low since so many of them are driving drunk... :D

Cheers,
:stirthepo
 
Back
Top