Incorrect IAF waypoint placement at YMML

[BenLong]

Hi there,

I suspect something is misaligned at YMML Melbourne, the LOC beam seems pretty good which leads me to believe it is the exact placement of the GNSS waypoints. Please view the attached image:

You can see that the LOC beam is to the left of the GNSS path (the aircraft was kept in LNAV mode to test).

Futhermore, on a recent flight, the aircraft overshot a very slight turn onto the ILS when turning onto BELTA from the ARBE7A STAR for the ILS rwy16. You can see this below:

Using latest AIRAC and Fenix update. I’ve tested this several times and had the same result, please investigate.

UPDATE: Further investigation by myself indicates that either the waypoint BELTA is slightly misplaced or the ILS course is very slightly off. If this could be looked at that would be great.

FURTHER UPDATE: Looks to be the IAF waypoints for nearly all the approaches, even RNPs. We can see this thru the MCDU data:

BRG should be 160 degrees (ILS course) for both. As we can see from the following image, BELTA is very slightly displaced from OKMEL:

This problem is also consistent across all other runways at YMML.

Kind regards,
Ben Long

[NAVDataOld]

Hi Ben,
the cockpit screenshot is sadly not very clear but anyway I think, I can answer it.

You are approx. 3000 feet high and I guess that´s the tolerance - the really main question is:
Do you land on the runway (centerlined) or not? Would it be better (more accurate) or not? You can´t really compare an ILS approach with a GPS approach, or at least not 100% - two different systems, two different technical solutions.

What I see, the offset is minimal to the left - so in my eyes absolutely normal but I´m not a real pilot so I can only speak about the data behind and the data are correct so far (at least what I have tested now).

The same for the “overshot” which I feel is not really an overshot what I see on the images here. It depends on a lot of calculation and settings on the aircraft. Further, this is nothing what we have in our hands because we “only” offer the data behind, so waypoint to waypoint and not the flightpath to these waypoints. The path is a result of the specific leg-paths behind which will be interpreted by the aircraft/FMC.

But I want to give you an short example how complex that could be and how accurate that is (or not). I have calculated the true courses from:

Here a simple overfew about the following caluclations:

Color: blue dotted
from: BELTA (-37.46219444, 144.79822222)
to: runway threshold 16 centerline (-37.65318056, 144.83491389)
true-heading: 171.3155274170515

Color: orange
from: BELTA (-37.46219444, 144.79822222)
to: localizer antenna ILS 16 (-37.68863889, 144.84152778)
true-heading: 171.35861913781741

Color: green dotted
from: runway threshold 16 centerline (-37.65318056, 144.83491389)
to: localizer antenna ILS 16 (-37.68863889, 144.84152778)
true-heading: 171.56850993583419

You see in all three examples a slightly difference between the calculations (based on WGS84 - no roundings). This is nothing on the ground or near the centerline but when you are 8-10 nm away, this deltas will increase and I assume that happens here. What I want to say is, that the complete path is a calculated one and it should be more and more accurate as soon as you reach the final/next waypoint/point.

As summary - it would not be ok, when you land left or right the runway (or at least with a large offset to the centerline), but in this case, I guess it´s absolutely correct. I´m no real world pilot - I can only compare the data and here you see a slightly offset and we are working with real-world data so I assume, you will see the same offset in a real-world airplane too …

Hope that helps,
Richard

[NAVDataOld]

Hi again Ben,
I have seen you have updated your posting, therefore also an update on my side. You mentioned that something is misplaced. I have now checked all details against the AIP Australia and have calculate the possible offset of the results:

BELTA:
from the AIP: -37.462222, 144.798333
from our data: -37.46219444, 144.79822222
delta in feet: 33.68417445128398

OKMEL:
from AIP: -37.561944, 144.8177777
from our data: -37.56186111, 144.81788889
delta in feet: 44.156937501728358

… and now a few calculations as before (all courses are true course to be on the safe side):

BELTA → OKMEL:
using AIP data: 171.17694247160307
using our data: 171.07295485285306

BELTA → THR16:
using AIP data: 171.340117535952
using our data: 171.3155274170515

OKMEL → THR16:
using AIP data: 171.50678172603136
using our data: 171.56864294660943

When I would now switch to magnetic (11°E) and round it, I get with both “worlds” a course of 160 degrees. You also see, that there is between BELTA → runway 16 and OKMEL → runway 16 a small offset - but here, I have calculate with real-world values without any system between or roundings - and also here, the small offset.

I can´t say anything about the calculation in the Fenix but what I can say is, that we don´t offer any misplaced information. Also my calculation is very accurate that´s not the case in the FMC but also when you use such accurate values you don´t see any real offset.

The difference between the AIP coordinates and the Jeppesen one is, that the electronic information from Australia, is more accurate (seconds with comma) as the published one in the AIP but also here 30-40 feet over 8-10 miles are nothing.

Cheers,
Richard

[NAVDataOld]

… one thing what I have forgotten here:
Fenix uses true-heading values and they calculate the magnetic headings by their own. I´m not aware, if they use the magnetic-database from MSFS or if they calculate the magnetic-variation by yourself. This is also nothing what we have in our hands.

Cheers,
Richard

[BenLong]

Hi Richard,

I understand what you’re saying and to make it clear, after testing this a few times I don’t think it’s the LOC beam that is incorrect. In saying that, the problems that this boils down to is not one present in IRL aircraft

Basically I’m having a hard time believing that BELTA is correctly placed as if it is the BRG should be 160 degrees (magnetic) from BELTA to OKMEL to THR16, but as you pointed out this could be an error in the declination calculation that the Fenix is using.
If it were like this in the real aircraft, then we would theoretically see the same result that the Fenix performs (overshoot) but they do not. Theoretically, if BELTA was to be 100% accurately placed, it would be at a PBD of OKMEL/340/6 per the chart. Placing it this way in the aircraft looks like this:

Compared to this:

So in my head this is what we’re dealing with:

Of course, I understand that the most you can do is provide the correct data to the aircraft, and nothing else, so if the waypoints are correct based on the data, then it is what it is

[NAVDataOld]

Thanks Ben - and also thank you for the screenshots and the valuable insights … After my analysis and comparison with the AIP, I´m pretty sure, that the data are correct so far. Fenix is the only addon, which expect true values and not magnetic values - so, they calculate the magnetic headings/bearings by their own.

Depending on the source of the magnetic variation and also the rounding somewhere in their calculations it could result in this offset. In my eyes, we (from the data point perspective) can´t do anything here. Would be interest to get any statement from Fenix on this. Have you still asked there too? Because we both have now collect good details in this topic …

Thanks Ben for this great posting … I like such topics because they are more in detail, even when we don´t find a final answer/solution for this. Good stuff Ben … thank you!

Cheers,
Richard

[BenLong]

Hi Richard,

Thanks for your kind words and quick input in this. Indeed it’s very interesting to look at little details like this. I can pitch this to Fenix but I doubt they will be too concerned with all that they’ve got going on. For what it’s worth, it seems to just be YMML that has this issue, so I think PDB waypoints will be the way for now.

Cheers,
Ben Long