FSXA EGAC ILS 22 problem

[borgfan]

Using ADE 1.66, I wanted to modify EGAC airport and decided first to simply recompile from stock before introducing my changes. I put the resulting BGL file into my Addon Scenery folder and tried an ILS 22 approach. The default Cessna could not pick up the GS on the ILS and upon inspecting the new BGL back in ADE I found the following ILS defined ( all on freq 108.1 ):
IHBD ILS/DME 04
IBFH ILS/DME 22
HBD LOC/DME 04

I'm wondering whether the HDB LOC/DME 04 should actually exist as I'm guessing it conflicts with ILS/DME 22 and so the GS problem. I've assumed that ADE extracts the stock airport data from APX46120.BGL but that file doesn't seem to contain a definition for that LOC/DME 04. I've check for duplicated airports and also confirmed the problem with a virgin copy of FSX/SE.

While there is a strong possibility that I'm just doing something dumb, I'd appreciate any ideas as to how I can resolve this, tks
Gerard

 

[scruffyduck]

Addon Scenery or Addon Scenery\scenery? I see only two ILS in the stock airport HBD and IBFH

 

[borgfan]

Looks like the problem is of my doing .... I had installed an updated navaid package from http://www.aero.sors.fr/ which replaced the stock APX46120.BGL with one which had IHBD ILS 04 added.

When I recompiled EGAC with this change, although the new BGL showed the additional ILS IHBD 04, I lost the glideslope for some reason on ILS22 ( ILS04 worked ok)

Reverting all to default, everything worked as expected. It would be good if ADE could process the modified APX46120.BGL to produce a working result as it is convenient to have ILS 04 in operation as per real-world, but I recognise that modifying the stock BGLs isn't good practice anyway.

 

[scruffyduck]

We really don't recommend using packages that update stock navaids. We are aware that the navaids in FSX are well out of date. However the implications of changing the stock data can also cause problems as you have seen. There are some folks who find these updates useful of course.

At the moment ADE will only read stock data as provided by Microsoft as part of the default data.

 

[borgfan]

No problem, I think that's a very reasonable position. Thanks for ADE and the excellent support of it.

 

[hervesors]

I just checked on my FSX and there's no problem on my side with the modified APX46120.bgl file that only contain the IHBD and IBFH ILSs. BC flag has also been set to "off" considering they use the same frequency, but GS and DME (that read 0 at threshold as indicated in UK AIP) are separate. The HBD LOC/DME is an old one and doesn't exist anymore in the modified file so it probably comes from "elsewhere" and explains the discrepancy you observed. May be you could search and inactivate it.
Even if I understand one may consider it is a questionable practice (I know it is Jon's position), IMO, it solves a lot of problems for those who only use current charts and don't want to worry about what they will find on arrival, effortlessly.. In addition, original files are backuped and can be restored in a single click at any time so it is risk free...Making hundreds of new editions with ADE for each missing, wrong or decommissioned ILS, the numerous runway Id changes we all observed, missing or wrongly positioned PAPIs and wrong approach lighting systems - on a worldwide basis - is probably a bit too much work for many, the reason why I proposed these updates since a long and update all data at every AIRAC cycle. Now for sure, if you only fly on a limited number of airports, better to find a suitable scenery or make your ADE by yourself. ADE is really a terrific program but the work will still be your's ;-). My 2 cents

Hervé

 

[borgfan]

I believe that the 'old' HDB LOC/DME is being introduced by ADE from its own FIXLIST.DAT. Thus when a stock airport is opened, ADE combines the navaids from the relevant APX?????.BGL and FIXLIST.DAT.

Would be nice to be able to update this fixlist.dat such that inconsistencies introduced by the use of updated stock navaids could be remedied.

 

[hervesors]

>>I believe that the 'old' HDB LOC/DME is being introduced by ADE from its own FIXLIST.DAT<<
Correct but only in ADE display after loading a XML/BGL file from it (and this is not ADE purpose)..surely not in the sim if there's no other BGL reference to this outdated LOC/DME.
So nothing to worry about..
Another remark: when 2 ILS have the same frequency on opposite runways, FS doesn't have any problem (at least if backcourse flag is disabled) but it may happen that your NAV display locks on the "wrong" one depending on your approach sector (the ILS Id will show that). In such a case, just deselect temporarily the ILS frequency and select it again when properly positioned in the intended approach sector. It will then act correctly

 

[jvile]

I believe that the 'old' HDB LOC/DME is being introduced by ADE from its own FIXLIST.DAT. Thus when a stock airport is opened, ADE combines the navaids from the relevant APX?????.BGL and FIXLIST.DAT.

Would be nice to be able to update this fixlist.dat such that inconsistencies introduced by the use of updated stock navaids could be remedied.

True, ADE is combining the modified APX46120 to the stock APX46120 which now has 2 ILS's and 1 Localizer which FSX allows. However the problem started before you even used ADE and tried to load a airport from modified MS files.

ILS's are nested in the runway data which means that type navaid is owned by the runway. The companion approach code is nested in the Airport record which is owned by the FSDATA. When you installed the updated navaid package from http://www.aero.sors.fr/ which replaced the stock APX46120.BGL you lost all your Approach data. Go to EGAC and open the GPS approach page. It is blank.

I suspect the approach data was deleted because it became corrupt due to changing the LOC HDB to a ILS IHDB. When the weather engine ATIS reports the airport is IMC the ATC engine does not understand IMC and thinks all runways are visual approaches. When IMC and visibilty is a 1/2 mile in rain and low cloud ceilings the ATC controller says cleared for the visual approach, report runway in sight even though you are 8 miles from the runway.

Not only is the weather engine and the ATC engine broke it has also broke the AI engine. The ILS approach (not Localizer approach) as per ATC is a all weather approach and the AI planes are programmed internally to use the FAF fix and altitude as the hard floor. When the ATC can no longer identify the runway as a ILS in the approach code it uses a hardcoded canned approach of 2000 ft and 5 mile FAF fix. This causes many AI Planes to land short of the runway.

Go over to EGLL Heathrow and ask the Controller for a ILS approach or any of the many transitions. There are none and this has nothing to do with ADE but the update files you installed.

ADE has 2 Objectives

1. Make the airport look as good as or better then the default
2. Make the airport work as good as or better then the default

Even if ADE only read the modified APX46120 there is no approach data, there are no Terminal_Wayponts, Many VOR's and NDB's have been moved which causes the Flight planner to Crash FSX. Contrary to what the FAQ's page says on the updated navaid package from http://www.aero.sors.fr/ the Flight planner crashes FSX because none of the VOR companion route Waypoints for the Victor and Jetway airways have been moved.

FSX is coded to ARINC Navdata not AIRAC navdata. If you update the navaid package from http://www.aero.sors.fr/ then turn the default ATC system off, do not use the FS Flight planner, use VATSIM, fly a plane that has a FMC that works with AIRAC type navdata and do not try and update an airport with any of the airport utilities.

 

[scruffyduck]

Would be nice to be able to update this fixlist.dat such that inconsistencies introduced by the use of updated stock navaids could be remedied.

Except that the 'cure' has the potential to be worse than the original issue. Please note that I am not addressing the specific issue here nor taking sides on whether it is a good idea or not. Except to say that over the years we have counselled against modifying stock files. We have discussed the idea of allowing users to generate their own custom 'stock' database of airports, navaids and so on but rejected it for several reasons. you may not agree with these but they include:

• The point of the stock files is to create a known common base for everyone. It is hard enough for us to understand what a user is doing when they have an issue without having to factor in that the expected base is not what it should be.
• Having a common base means that a developer should be able to release an updated airport or scenery with an understanding of what should be there. If you are developing only for yourself and never intend or expect to release it to others then your base could be different than everyone elses and aside from support issues you can do as you please.
• If a user tries to modify an airport created by someone else where there base is different then more problems can arise.
• and again I am not making any specific remarks about the stock mods referred to here - we cannot be sure that the mods made do not have unexpected consequences because they interfere with the expected or contradict something that is in an addon airport placed at a higher priority.

Microsoft gave us the tools to allow changes to airports and other scenery that did not involve modifying the known stock base. They did that for good reasons - hopefully including some I mention above. Unfortunately they did not provide a way to modify that stock base for navaids - at least not a clean or reliable way to exclude the stock data and replace it with new data without changing the base.

So while we are always looking for ways to allow users more flexibility that currently (and probably always) means that ADE will assume and provide for the users who have an unmodified stock database. These are by far the majority of our users. Please don't ask me to provide an option for users to over ride the stock databases and use their own - I have a list as long as my arm of new options that folks would like

So our position can be summarized thus:

• We assume and support that the user has an unmodified stock database for airports, scenery and navaids
• Users are entitled to modify or change that stock base data as they please and that is their right (leaving aside copyright issues of course)
• However if users use ADE with a modified or changed stock database then they need to understand and be able to work with the implications.

I hope that is fair, reasonable and unbiased

 

[borgfan]

Jim and Jon make good points and I think it is in no one's interest to make a complex affair even more complicated!

Assuming the stock data is left as is, I'd be happy if I could add a ILS/DME 04 to EGAC. I don't know if this can co-exist with the default LOC 04. When I tried just to add another ILS to RW04, I found once again that ILS 22 lost its GS. I'm not sure if I'm trying to do something impossible or just doing it wrong

 

[jvile]

borgfan

You do not add another ILS to runway 04. You have a Localizer for RWY 04. Click on the Large green triangle and now add the GS checkmark and you will see in the property dialog name change from LOC/DME to ILS/DME.

Attached is a master EGAC_adex.ad4 file but requires the FSX default APX bgl. It has a ILS 04 Ident IHBD and a ILS 22 Ident IBFH. The approach code has also been updated to include the new ILS 04. DME's are in their proper place. The Back Courses are deactivated since they are not needed.

In FS2004 the Front Course of the ILS could get confused with the Back Course based on the sector entrance. This problem was fixed in FSX but it is still a good practice to uncheck the BC since it is not needed.

You can make changes to the airport as needed and compile.

 

[hervesors]

For still better realism, I'll also suggest:

- you move both DMEs aside runway thresholds considering DME should read 0 at threshold
See section 2.19 of textual data
http://www.nats-uk.ead-it.com/public/index.php?option=com_content&task=blogcategory&id=19&Itemid=74.html
You'll have more accurate and matching DME readings when compared to approach charts while performing approaches
Not a problem considering DMEs do not have associated objects

- you move forwards IHBD GS to 980 ft from displaced threshold 04 (actually about 900 ft); however you'll have to remove glide transmitter scenery object not to interfere with apron (don't know if it is possible at compilation time in ADE)

- you correct both PAPIs that are (as for nearly all stock airports) wrongly positioned (PAPI 04 has to be 820 ft from DTH and PAPI 22 at 1040 ft from TH ; see section 2.14)
FS nearly always put them at 750 ft from TH..a very unrealistic situation

- you enter the correct calibrated magnetic variation for both ILSs that is W3.6°. It will have an influence on the magnetic track readings and displays on map view (but not on ILS course following)

- according to real distances between TH and localizer antenna, beam width should be set to 6.0 for both ILS as far as it is the maximum accepted value for standard ILS design. Some AIPs (US for example) give the true calibration value, others do not; in such a case, make the calculation by yourself with 3 to 6 as limits

Then enjoy ;-)

Hervé

 

[borgfan]

Thanks very much to all for the help and advice, much appreciated.