ND Misalignment on SID Departure Waypoints & Inconsistent FD Behavior

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.

Screenshot (1324).png

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.

Mark

If you see that behaviour again, could I kindly ask you to raise a support ticket for this with Just Flight Support at the following link: https://www.justflight.com/support

In the ticket, if you could provide a video of the behaviour, as well as a log file generated by the product, then our support team will be best positioned to be able to further assist.

Instructions for locating the log file can be found here: https://support.justflight.com/en/support/solutions/articles/17000152594-where-to-find-the-log-file-s-

Mark - Just Flight