Route drawing glitch on ND

[Nicrative]

Aircraft Version

Development

Build info

{
    "built": "2023-09-02T09:03:14+00:00",
    "ref": "refs/heads/master",
    "sha": "1160fe5fcb0206ffcd270a683579d3b75b8a5221",
    "actor": "tracernz",
    "event_name": "manual",
    "pretty_release_name": "master:1160fe5f",
    "version": "v0.11.0-dev.1160fe5"
}

Describe the bug

Noticed a strange route drawing glitch before EDISA on the route EGLL/09R DET1J DET L6 DVR UL9 KONAN UL607 REMBA DCT PITES DCT EDISA DCT PICWI DCT UTABA L607 MOMUK DCT GEDSO DCT VEKEN DCT NEMEK DCT TUPUS/N0449F390 DCT AKIKA DCT PINDO UL607 XORKI LGAV (no arrival was selected at the time). I am not sure if it matters but here are the steps I took with route manipulation during the flight: The flightplan was planned via Simbrief and loaded with REQ INIT feature. Selected runway and SID and cleared the discontinuity after DET. No other changes done.

The aircraft also flew the green line making the strange turn before EDISA.

Expected behavior

There should not be any extra turns on the leg between PITES and EDISA.

Steps to reproduce

• Planned flight with simbrief. Route: DET L6 DVR UL9 KONAN UL607 REMBA DCT PITES DCT EDISA DCT PICWI DCT UTABA L607 MOMUK DCT GEDSO DCT VEKEN DCT NEMEK DCT TUPUS/N0449F390 DCT AKIKA DCT PINDO UL607 XORKI
• load the plan in sim with REQ INIT (not sure if steps after this matter, I have not tested it further)
• Loaded runway 09R
• Loaded SID DET 1J
• Cleared discontinuity after DET
• Fly the flight normal, no other steps was made with flightplan manipulation.

References (optional)

No response

Additional info (optional)

No response

Discord Username (optional)

Nicrative

[Benjozork]

Doesn't look wrong for waypoint that are as close as those two. Working as intended unless someone finds evidence of the contrary.

[Benjozork]

Cleared discontinuity after DET

I don't know where exactly DET comes here, but it should be noted that deleting things from your flight plan can lead to issues, so it isn't recommended in most cases.

[Nicrative]

Doesn't look wrong for waypoint that are as close as those two. Working as intended unless someone finds evidence of the contrary.

Even if the waypoints are close together, there is nothing in the ARINC 424 format that would suggest such a turn before the waypoint between two TF legs. It's almost like the second TF leg between EDISA and PICWI is trying to dictate some sort of CF leg before EDISA to match the track between EDISA and PICWI. And even if this was the case that it would dictate some sort of CF leg to EDISA, there is no reason for that leg to be that long, or the aircraft trying to catch such CF leg that late when it's possible to plan a turn in such way that this glitch would not be necessary.

Unfortunately I don't have any real world picture reference, but I am very confident that this is not how the real aircraft would draw this. But you can make your own conclusions and if you want to keep this as "non-issue" so be it. I'm just trying to help to improve the product.

Cleared discontinuity after DET

I don't know where exactly DET comes here, but it should be noted that deleting things from your flight plan can lead to issues, so it isn't recommended in most cases.

I don't think this is really relevant for this issue. I just tried to give as detailed steps that I took when manipulating the flight plan. I simply deleted a discontinuity after DET which comes when route is loaded with INIT REQ which after RWY and SID (which ends at DET) are selected. The discontinuity should not be there to begin with since the SID connects to the first waypoint of the route, but FBW creates such discontinuity and it's completely reasonable flightplan cleanup in this case.

[Nicrative]

Just to add how the real system logic behind drawing would go.

It tracks PITES to EDISA as normal TF leg, and over EDISA would start drawing the curve that would match with the track between EDISA and PICWI. Also around PICWI there would be a curve that would match the course from EDISA to PICWI and PICWI to UDASA. If the waypoints are too close in such a way that these two arcs cannot share the same tangent which is the course between EDISA and PICWI then these two lines would essentially break between EDISA and PICWI. So I would expect something to break between EDISA and PICWI if at all.

Of course what the aircraft is doing now ensures pretty much that the route line never breaks. But it's pretty drastic workaround when the aircraft starts flying it's own routes outside the ARINC 424 specification. Even the real aircraft route drawing can break from time to time

[Benjozork]

 Even if the waypoints are close together, there is nothing in the ARINC 424 format that would suggest such a turn before the waypoint between two TF legs.

The turn algorithms used in the A320 FMS are not based on the ARINC 424 specification, as that specification dictates the encoding of navdata, not the generation of LNAV turns. Many proprietary and non-standard implementations exist, some more complex than others. The implementation on the Airbus FMS is limited to calculating turns between a set of two legs, except in some hard-coded circumstances.

What is happening here is that while a TF->TF turn is generally generated using the "fixed turn radius" algorithm, there exist conditions to revert to the "path capture" algorithm (as you seem to know, often used for capturing CF legs). Those conditions aren't super clear or consistent, but what we have right now is our best interpretation based on real-world references.

to match the track between EDISA and PICWI

That is indeed what is happening, because the turn is inbound to the leg TF -> PICWI, which gets its track from the previous fix, EDISA. The turn is simply "pushed back" because on the current turn radius - which is a general rule that could use some tweaking, but we lack references to know how exactly it works. But I fail to see how it would look better if the turn started closer to the waypoint.

Of course what the aircraft is doing now ensures pretty much that the route line never breaks

This is not the goal of our LNAV implementation - the goal is to match what the real aircraft does. And compared to most offerings, it performs very well in that regard.

I also said:

Working as intended unless someone finds evidence of the contrary

So yes - this isn't ideal - like the picture you sent of the real aircraft isn't ideal either.

[Benjozork]

P.S.: I'm not saying this isn't an issue, or that what we do right now is 100% correct, but there is no reference to suggest the current behavior is wrong, and on the contrary I have references to suggest it is correct, albeit in other scenarios. Should references come to light, this issue would be reopened, and considered to be fixed in an upcoming major revision of LNAV.

[Benjozork]

the waypoints are too close in such a way that these two arcs cannot share the same tangent which is the course between EDISA and PICWI then these two lines would essentially break between EDISA and PICWI. So I would expect something to break between EDISA and PICWI if at all.

I know of this happening, and I've seen it before (a few days ago too actually) in a real plane.

Do you have discord so we could discuss this more efficiently?

[Nicrative]

Thanks Benjozork, that is an answer I can get behind. And I appreciate you taking the time to write that explanation.

I understand that this issue can be rather complex one to solve since it seems to indeed be an edge case with two waypoints close together.

But I fail to see how it would look better if the turn started closer to the waypoint.

It might not look "better" on the ND. As you can see even the real thing can have problems with ND drawings in these cases. But I guess we are both on the same page thriving for realism in the end. I would imagine in this case if the real aircraft was unable to match the turns with the track in time, there could be a gap on the ND lines or just a hard angle (which is seems to already do before the waypoint). But yeah, unfortunately right now I don't have any better reference for this particular issue. So I guess we'll just have to leave it for now. Hopefully some references can be found and improvements can be made down the line.

[Nicrative]

the waypoints are too close in such a way that these two arcs cannot share the same tangent which is the course between EDISA and PICWI then these two lines would essentially break between EDISA and PICWI. So I would expect something to break between EDISA and PICWI if at all.

I know of this happening, and I've seen it before (a few days ago too actually) in a real plane.

Do you have discord so we could discuss this more efficiently?

Sure. My Discord is "Nicrative"