In search of a wandering localizer

[rfields]

I've been trying to locate the code for the IASE localizer at KASE in FSX.

The IPKN localizer which is used for departures and missed approaches is in the KASE airport data - just as it was in FS2004.

However, the IASE localizer is somewhere because it shows up on the GPS. The approach to use the localizer is not in FSX, but the localizer itself is.

Just trying to figure our how MS assigned to localizers to the same runway end.

I've looked in all the files in the 0202 folder which might in anyway be related to the KASE airport.

 

[DougMatthews]

I've been trying to locate the code for the IASE localizer at KASE in FSX.

The IPKN localizer which is used for departures and missed approaches is in the KASE airport data - just as it was in FS2004.

However, the IASE localizer is somewhere because it shows up on the GPS. The approach to use the localizer is not in FSX, but the localizer itself is.

Just trying to figure our how MS assigned to localizers to the same runway end.

I've looked in all the files in the 0202 folder which might in anyway be related to the KASE airport.

IASE (LOC/DME) localizer is just south of the runway.

IPKN (LOC) localizer is about 4.7 NM SSE of the airport.

We use the assignments from the data providers (Jeppesen in this case). This is one of a handful in the world where there are two locs associated with the runway end.

-Doug

 

[scott967]

bglcomp accepts ILS elements that are "part of" runways, but the actual ILS data in the AP9/APX files is contained in a navaid section. Some other tool than bglcomp was used to insert these other ILS elements, since a runway can have only 1 ILS associated with each end. That is the situation at KSTL, and that is why I've been trying to get "scruffyduck" to decode the VOR/ILS data in his sde, and not just rely on the runway data in the airport section.

scott s.
.

 

[scruffyduck]

bglcomp accepts ILS elements that are "part of" runways, but the actual ILS data in the AP9/APX files is contained in a navaid section. Some other tool than bglcomp was used to insert these other ILS elements, since a runway can have only 1 ILS associated with each end. That is the situation at KSTL, and that is why I've been trying to get "scruffyduck" to decode the VOR/ILS data in his sde, and not just rely on the runway data in the airport section.

scott s.
.

Hi Scott

I am about to upload a new build Can I make sure that I understand what is going on? This is what I understand at the moment.

The ILS data is compiled into the same section of a bgl as the Vors. It is therefore decoded away from the airport runway data itself. What I do after decoding is to search through the Vors found in the bgl file and match them back to the appropriate runway. If there are any left over in an AP/APX file then they would be displayed separately. So far that has not happened and there are only ILS records in the airport bgl files (unless my code is wrong).

I do not think there is anything in my code which would stop additional records being associated with a runway if they were thus coded. Of coulse it would not be possible to re-compile since, as you say, BGLComp will throw an error

All other navaids are in the NV/NVX bgl files and are is therefore no easy way to relate them. Are there likely to be such airport related records in a navaid scenery file?

 

[jvile]

What I think is, whenever 2 Localizers are assigned to a single end runway MS coded one of them in the dll file. That means we will never find it.

KSTL, KSNA which also have 2 localizers cannot be seen with newbglanayanlyze or bglanalyzeX because the first IF type statement does not list the Localizer/LDA IDENT like BGLX180 and 190 does.

KSTL is actually backwards because the LDA frequncey was assigned to the ownership of the runway instead of the LDA. That can be reversed if the xml code is re-written.

One of the things that lead me to believe the second Localizer (LDA) in most cases is in the dll is because there is no record for Lat/Lon and heading which must place the green ILS symbol seen in the GPS receiver.

KASE like Reggie points out is even different yet then a runway with 2 Localizers because the backcourse departure Localizer (IPKN) is owned by the runway and the Frontcouse localizer (IASE) is no where in sight (Code).

The issue is compounded somewhat because there is no associated Approach data for either Localizer symbol in the APX.bgl.

 

[jvile]

Jon

I used SDE which will help understand what the problem has always been.

Your SDE utility locates the second LDA localizer for the runway by extracting all the record data

Open 0202/16200 KSNA

This airport has 2 Localizer assigned to runway 19R. One is a ILS and one is a LDA. If you were to view this airport in MAP or GPS mode of FS you will see 2 ILS symbols (green triangle)

The Localizer that is owned by the 19R runway record is IDENT ISNA

In the IF leg you decoded the following which Winfried decompiler leaves out.

recommendedType="LOCALIZER"
recommendedRegion="4Y"
recommendedIdent="ISNA"

That data is very important because now go down to the 19R LDA approach record

<Approach
type="LDA"
runway="19"
designator="RIGHT"
suffix="0"
gpsOverlay="FALSE"
fixType="WAYPOINT"
fixRegion="K2"
fixIdent="TUSTI"
altitude="487.68M"
heading="194.9545"
missedAltitude="914.4M">
<ApproachLegs>
<!-- ApproachLeg IF -->
<Leg
type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="K2"
fixIdent="EFFIE"
recommendedType="LOCALIZER" <--------- 2nd Localizer assigned to 19R
recommendedRegion="4Y"
recommendedIdent="IOJW" <---------- LDA IDENT
theta="0.9"
rho="18895.23M"
altitudeDescriptor="A"
altitude1="701.04M"
/>


and that is what we are still looking for in all airports that have 2 Localizers assigned to the same end runway.

The compiler will not let you have 2 ILS records nested to the same end of a runway. You can have one for BASE END and one for RECIEP END but not 2 for the same end.

Since FS9 Reggie and I have been trying to find the ILS (LDA) localizer data for all these runways in FS9/FSX that have 2 Localizers. That 19R LDA IOJW IDENT has a Freq, heading, LAT/LON somewhere in FS9/FSX and yet we have never been able to located it.

Like Scott says it might be in the NAV records.

The original question Reggie ask follows this same issue but KASE is even a little different then just adding 2 Localizers.

 

[scruffyduck]

Hi Jim
OK I can see all that and understand the problem. clearly 19R LDA IOJW IDENT is not in the airport bgl. Also a quick search of the NVX bgl in the same folder does not come up with that ident.

 

[rfields]

The goal is to find the information in the code necessary to write the LOC/DME I-ASE approach - http://204.108.4.16/d-tpp/0701/05889LDE.PDF

It can be done, because it was done for KSNA in FS9.

You can fly the approach in FSX now - but because it is not in the code the GPS and ATC are unaware of the approach.

There is no navaid with the IASE ident in the APX19180.bgl. There is no navaid with the IASE ident, ASE ident, or frequency 111.15 in the NAVX02020.bgl.

If as Jim suspects, this is coded into .dll files and we will not be able to write that approach, okay - I can live with that.

This two localizer for one runway is a very rare occurrence in the real and FS world.

It's just this is a very popular airport - and it would be nice for FSX to be able to fly it somewhat realistically.

 

[jvile]

and that is the problem Jon!!!

Somewhere the second ILS Localizer regardless of it being a Localizer or a Offset ILS (called a LDA based on offset degrees) is somewhere yet to be found. Both a ILS and a LDA is what will create a green ILS symbol seen in the GPS receiver. Nothing else will do this including a coded Localizer that has a suffix

I also have searched every possible bgl in the past on the IDENT code and always come up empty.

In some cases like previously posted FS9/FSX by accident coded the LDA to the owership of the runway instead of the ILS.

KSTL has this problem. If you select the ILS freq as per the MAP mode in FS you actually get the LDA offset second localizer and the User Plane flys inbound on the approach on a offset heading.

I have answered some post on other forums to be sure and select the LDA freq not the ILS freq if you want to fly a precision ILS LOC/GP into KSTL.

Its on my "to do" list to fix by writing a xml code that will reverse the reverse code FS accidendly used.

 

[jvile]

Reggie

If FS had assigned the I-ASE to the owership of the runway (nested) we could write the code.

But the Backcourse I-PKN is nested to the runway leaving the I-ASE as the illusive Localizer that we can't find.

would you agree?

 

[scruffyduck]

Well I am going to add 'scanners' to SDE in a future build and maybe some sort of search funtion - it would be rather slow however since there is a lot of data!!!

 

[jvile]

Jon

Here is the twist to the mystery

When ever a 2nd Localizer exsit at some airports Lee's AFCAD program always found it in FS9.

This is why we always assumed the 2nd Localizer was in the airport records somewhere but no decompiler except AFCAD had the ability to decode it.

If you use the AFCAD program on FS9 KSNA and ask to see NAVAIDS both green Localizer symbols and Localizer data displays on the AFCAD grid properly.

In order for that to happen AFCAD has to find the LAT/LON, heading, freq. etc of that 2nd illusive localizer. I took the AFCAD program apart (has much as I could) to see what additional bgl's it read besides airport facility data. Never found where it was reading the second localizer from.

 

[scruffyduck]

Hmmm - I wonder if Lee would tell us?

 

[jvile]

Here is the second localizer which is a LDA as seen in your SDE approach data for 19R.

This is what AFCAD shows for properties which means it is somewhere in FS9/FSX

KSNA
19R
ils ident IOJW
name LOC/DME 19R
freq 108.30
Mag var 13.7
range NM 27.0
Lat N33* 40.9410'
lon W117* 51.7940'
elevation 54.0
true heading 194.700
beam width 6.0


DME
Lat N33* 40.9410'
Lon W117* 51.7940'
elevation 54.0

find any part of this data and we may find where all the 2nd illusive localizer records are located for all runways


I will e-mail Lee

 

[scruffyduck]

Well that certainly looks like it should be possible to find it. There isn't enough information in the airport records though. Thanks for mailing Lee. If he can tell us how he did it or where to look then I will try and include this in SDE.

 

[scott967]

I don't know any easy way to determine when the "extra" LDAs exist, but if you know the name, such as LOC/DME 30L at KSTL it is easy to find the record in APX23180 with a hex editor. Or I guess if you had an ident "decoder ring". Obviously one could parse all the idents in the VOR/ILS section, and compare against the ILS idents in the runway records to determine the "deltas".

I-ASE is at file offset 0x3FAF8 in APX19180

scott s.
.

 

[jvile]

Scott

I am not sure what hex editor you are using but Hex Workshop (Payware) reports that there are no instances of I-ASE, ASE, I ASE, IASE etc. found in APX19180.bgl

However, lets go back to your original post that said it could be in the NV9/NVX navdata bgl's.

Guess what, I have good news and bad news.

I have found 5 records that are unknown when decompiled by all decompilers for FS9/FSX (bglx180, 190 and Newbglanalyze, bglAnalyzeX).

I have not heard back from Lee yet but he reads the AP9.bgl and the NV9.bgl so all the VOR, NDB's and the illusive localizers will show on the AFCAD grid.

Below are several pictures of what I have found with the unknown records and added a third Localizer to runway19R at KSNA. The AFCAD is FS9 Stock the way AFCAD reads the default files so FS9 now has 3 localizers. The GPS is FSX which I also added another Localizer to 19R (3 total).

This is all done within the NV9/NVX respectful bgls for KSNA. I now believe that those "unknown" records that the decompilers are not decoding are the illusive Localizers.

I also ask myself why so many unknown records of that size in the NV type bgls. The answer is that for a 2nd Localizer to show as a default in the MAP (FSX) or AFCAD (FS9) requires a Airport Header, minimum runway data and the Localizer to nest in. Without all that info you can't have a second Localizer just based off of a Lat/Lon/heading value.

I don't think Jon missed in his SDE utility that much unknown record data in the APX bgls.

The bad news is if the illusive Localizers are nested in the unknown records that I see there is no way of writing approach code unless we edit a MS default bgl and add it to a upload for approach data.

I am still thinking this through but Jon would be the one that finds out if those unknown records are in fact the 2nd localizers. That is beyound my knowledge level.

@Jon

Use SDE and open 0202/NVX02020

The window shows unknowns and VOR_ILS data

Decompiler Output...

... Vor_Ils
... Ndb
... SceneryObject
... UnKnown_0x0028
... UnKnown_0x0029

I found 5 unknown records with bglx 190 decompiler


One other observation is that Winfrieds decompiler does say there is ILS data in the NV9/NVX type bgls but when you go to find it nothing is listed.

1. First and second picture is my new KSNA with 3 Loc's assigned to 19R and all display properly when running FS9

2. Third picture is the FSX GPS for KSNA where I now have coded a 3rd Localizer to runway 19R and it works also when running the sim

 

[scruffyduck]

I have found it - it is in the APX record - the problem is with the post processor in SDE (and presumably in BglAnalyze also). I will modify the program to handle it correctly. I presume that it needs to be displayed outside the aiport record and I can do that. Placing it inside would cause BGLComp to crash.


EDIT

OK it is done - SDE will find the extra localizer and put it in the tree outside of the airport records. What I can't seem to do is decode the airport ID field correctly for Vor records - I an not using it at the moment but I will look into it. That would make it a lot easier. Unless the SDK is wrong we can't place a vor element inside an Airport record in any case.


Also decoding some other APX files I am finding several of these records turning up now

 

[jvile]

Don't keep us in suspense too long.

I know that Reggie, Scott and I have wanted to find these since the early days of FS9.

All the VOR's that I looked at in the past and added were always placed outside the airport record. On the other hand a NDB can be placed in either location. If the NDB in inside the airport record it is a TERMINAL_NDB and is also assigned to the Airport code. If outside the airport record it is a NDB.

 

[scruffyduck]

Jim I am getting them fine. I know that NDBs can be placed inside an airport record but not, it seems, Vors.

I will release the new build over the weekend with this fix in place