DET2F incorrectly coded - Fenix A319/20/21

Hi all,

Just noted that the Fenix A319/20/21 does not fly the DET2F departure runway 27R at EGLL/LHR correctly, I believe this may be a result of mis-coding.

The aircraft does not intercept the 136 track to EPM NDB and instead is programed to fly a “direct to” D10.0 LON after passing D2.0 LON. It also does a very poor job at complying with the 090 from the EPM VOR then onwards.

The IRL aircraft are clearly programmed to intercept this track but the Fenix does not appear to be. Depending on the bank angle, this could very well take the aircraft out of RNP1 tolerance. Could I suggest this is double checked? Otherwise, everyone will end up unwillingly flying the SID non-compliantly.

Hi,
Please report this to Fenix, it seems an implementation issue because the coding seems to be correct.

Here, when we draw the path from the same source:

The path looks correct - I can’t see any navdata issue here. Sorry.

Cheers
Richard

The PMDG also flies it incorrectly:

I’ve tested multiple aircraft now (A320, 777, 737, 787). None of them are programmed to intercept the track:

I have advised Fenix but this will definitely turn into a “that’s the other guy’s problem” debacle.

Hi,
This is the coding from the source which we offer in all databases. You see the course 136 which is corresponding to the charts. You also see the waypoints and that both first waypoints are defined as fly-over waypoint. I have also compared the coding with the NATS UK and the coding itself is identically.

image

So, I can´t identify any incorrect coding here. The intercept depends on your speed (and of course the bank-angle). On your PMDG screenshot you are on the ground with zero speed so the path draws correctly.

It´s not coded as “intercept to fix” D161J (which is the “not before LON10” waypoint), its coded as “course to fix” … again, the coding is 100% the same as in the NATS UK.

Cheers,
Richard

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.