ND Misalignment on SID Departure Waypoints & Inconsistent FD Behavior

[jvtbalds]

Hi everyone,

I’ve been noticing a specific behavior on the Navigation Display (ND) during SIDs that require an immediate turn after takeoff, and I was wondering if anyone else has observed this or if it’s a known limitation in how the FMS parses Navdata.

When departing on a SID where there is a waypoint or a conditional turn point right along the runway centerline (e.g., turn at a specific DME or altitude right after rotation), this point appears visibly misaligned/offset from the actual runway centerline on the ND.

What makes this more intriguing is the Flight Director (FD) behavior:

Sometimes: The FD aggressively tries to track and fly towards this misaligned, offset waypoint right after liftoff.

Other times: The aircraft completely ignores the visual offset and continues to fly the SID profile smoothly without any issues.

Is this visual misalignment on the ND just a drawing/rendering quirk resulting from how the FMS interprets ARINC 424 leg types from the AIRAC database, or is it an actual bug in the lateral navigation calculation? Since the FD occasionally hunts for that offset point, it seems to affect the actual LNAV guidance rather than just being a purely graphical anomaly on the screen.

Has anyone else noticed this during immediate-turn departures?

For exemple:

SBGL, RWY10, SID TIVR1A/NAXOP

[pedropolak]

Hello João!
This quoted missalignment in particular I've never noticed (never noticed, but might had happened), however there's two behavior around it that happened to me before, couldn't note any coincidence or what triggers this, so I'll describe here as I've noticed on my flights.

In some cases this altitude contrained turns looks to me, and the aircraft behaves like it's a fixed WAYPOINT, were it flies all the way to it and independent from the altitude starts the turn.

Using this same chart view posted by you I've over exaggerated the drawning to be more didactic, but what I've experienced was something like this, the FMS defines this point were it "thinks" that will reach 500ft being the point were it will start the turn, but, every time it did like this altitude was way over the minimum altitude for the turn.
*I know there's no problem if that altitude is a MINIMUM altitude like in the chart above, but that still a strange behavior to me.

[pedropolak]

Second part and posting it separatly as i don't know if that's a "bug or feature"

This does not limits to the example above were the altitude seems to become a "waypoint", it is also noticeable when the aircraft starts the turn at the defined altitude.
What I've noticed is, after the plane starts the turn defined by an altitude or by a DME and it suposed to fly direct-to the next waypont it follows a path that looks more like a FLY OVER path than like it's flying direct to the next waypoint.
Not knowing if I was 100% clear defining it here I come with another of my drawnings.

Defing the green one as the path I use to expect
And the red one as the path I ussually note when flying the F100 on similar sitiuations.

Finally, knowing that the F100 does not have GPS and not 100% of what is the expected behavior on this case, I leave here my final question, is this a feature, a bug or a limitation?

[SliderCDN]

You are showing RNP1/GNSS required SID. This aircraft is not certified to do them, so do not expect FMS to display correctly either.

[jvtbalds]

@SliderCDN

I am fully aware of the aircraft's limits regarding RNP1/GNSS SIDs.

Precisely to rule out that exact variable and isolate the drawing issue, I made sure to test this on a purely conventional departure as well.

I flew an OMNI departure out of SBCT (RWY 33). This is a standard conventional profile that simply requires a climb on runway heading until reaching a specific altitude (3500ft in this case) before initiating a turn toward a transition or a VOR outbound radial.

Even under these basic conventional parameters, the Navigation Display exhibited the exact same misalignment bug for the altitude-based turn point along the extended centerline.

So, the graphical offset and the subsequent Flight Director inconsistency are not tied exclusively to RNAV/RNP data. It appears to be a broader parsing or drawing issue within the ND logic whenever a turn is triggered by a point (whether it's a waypoint or a strict altitude restriction) straight ahead on the runway axis.

[pedropolak]

@SliderCDN From my side the chart was a pure representation of what I've experienced. This specific case show GNSS required, however it's also a RNAV1 SID, wich if not considering the GNSS requirement the F100 is capable of, and should correctly fly it.

So, chart was used only as an example, but if needed we can link thousand of other procedures that the F100 behaves exactly the same.

[SliderCDN]

@pedropolak Not to go off topic much, but if it says GNSS required, then it's GNSS required

[pedropolak]

@SliderCDN "not to go off topic but pretending I didnt understood"
As said I can link thousand of other procedures that do not have the same GNSS requirement and still does the same thing.

[SliderCDN]

Please, do link them and keep insults to yourself.

[pedropolak]

Here it goes, only some that I remember using with the F100





*This last one isn't even an RNAV one

[SliderCDN]

Firstly, you need to learn differences between equipment requirements and certifications. Incidentally, I used KUDAD2F dep few days ago and it worked as intended.

[pedropolak]

Yeah, keep you accusation to yourself
But thanks for the tip, I'll have a look on the differences between requirements and certification.
And thank you for helping bump this topic! That might help us to be seen reporting the bug.