A32nx: [BUG] APPR phase activates during cruise despite not passing DECEL point

Created on 28 Oct 2020  路  29Comments  路  Source: flybywiresim/a32nx


Mod Version

Master

built: 2020-10-28T04:59:23+00:00
ref: refs/heads/master
sha: a175647cd77b46b1ef4da4c7ee0482126b73ab48
actor: Benjozork
event_name: push

Describe the bug

During cruise, at seemingly random points, the APPR phase of the flight will begin, causing airspeed to drop and pitch to increase.

To Reproduce

  1. Load a flight
  2. Takeoff and climb to cruise
  3. Occasionally APPR phase will activate on the PERF page during cruise

Expected behavior

The plane remains in cruise phase until descent at which point the plane will change to DES phase.

Actual behavior

During cruise the plane switches to APPR phase instead of remaining at cruise.

References

APPRphase

Additional context

Might be hard to reproduce, since it seems to be random.

Was this working before/when did the issue start occurring?
Multiple people reported this happening as of 28/10/20

Is this a problem in the vanilla unmodded game?
Unsure but probably not

Discord username (if different from GitHub):
ThatRedMelon#6756

Bug

Most helpful comment

Found the issue, it is related to #1505 but in a very subtle way, looking into it to see if there's a way to patch it cleanly.

All 29 comments

Verified. Just occurred during my flight right now 1457Z KDEN-KLAS

ROCKI5 DEN DCT TEHRU DCT JASSE Q90 DNERO ANJLL4

Bug occured somewhere after JASSE mid crz way before even first waypoint of STAR.

image

Image of Navigraph point whereabouts I noticed the issue.

Same for me (and yes, I know the baro should have been set to Std 馃槈):

approach phase (Large)

I never had this problem until today. Maybe it's related to a175647cd77b46b1ef4da4c7ee0482126b73ab48? My current version is:

built: 2020-10-28T04:59:23+00:00
ref: refs/heads/master
sha: a175647cd77b46b1ef4da4c7ee0482126b73ab48
actor: Benjozork
event_name: push

As far as I know, the only condition for the MCDU switching to APPR is <40nm from the destination. Just this seems already strange to me - as well as the reported issue. But I didn't find another parameter so far. We're getting more and more issues with 3rd party liveries involved. Maybe that's one of them.

I believe there are only 2 ways to switch to APPR phase

  • Manual activation of phase
  • Passing DECEL point

On expected behaviour you say "The plane remains in approach phase until descent at which point the plane will change to DES phase." Just checking this is what you mean as DES should be before APPR.

Did you have a normal managed descent or did you descend manually? Did the DES phase activate as expected?

Apologies, that was a mistype, I mean cruise phase

Got ya! I was a little confused.

Yeah, strange though. Was there a particular time in flight, or maybe a particular distance from the RW that this happened, or random?

I'll try tonight and see if it happens to me on a175647

@kielyscott yes. I discribed what I found in the specific code so far. I don't think that's all. I must have missed something.

I performed a selected descent however the APPR phase activated a long time before I began my descent. Could the DECEL waypoint be at the incorrect place, causing the APPR phase to activate? I understand the DECEL logic was changed in a175647

I couldn't see a specific point it activated. However, I wasn't paying full attention to the sim, just heard the engines spooling down.

EDIT/Correction: ok it's switching to APPR if less than 40nm from DEST and/or lesss than 3nm from DECEL. It could be a DECEL problem. I saw DECEL flickering over my MFD more than one time.

Spotted this in the code, I suspect DECEL is being calculated incorrectly thought I don't know what the logic _should_ be

[CDU] Cleanup logic for DECEL ETA calculation

if (mcdu.flightPlanManager.decelWaypoint) {
            const idx = waypointsWithDiscontinuities.findIndex((e) => e.wp.cumulativeDistanceInFP > mcdu.flightPlanManager.decelWaypoint.cumulativeDistanceInFP);
            if (idx > 0 && idx < waypointsWithDiscontinuities.length) {
                mcdu.flightPlanManager.decelWaypoint.cumulativeEstimatedTimeEnRouteFP = mcdu.flightPlanManager.decelWaypoint.cumulativeDistanceInFP / groundSpeed * 3600;
                mcdu.flightPlanManager.decelWaypoint.estimatedTimeOfArrivalFP = utcTime + mcdu.flightPlanManager.decelWaypoint.cumulativeEstimatedTimeEnRouteFP;
                waypointsWithDiscontinuities.splice(idx, 0, {
                    wp: mcdu.flightPlanManager.decelWaypoint,
                    fpIndex: -42
                });

For reference, the APPR phase activated ~170-152NM away from airport mid CRZ.

OP says it might be random. I have had the issue 2 times in a row mid flight in cruise phase.

Spotted this in the code, I suspect DECEL is being calculated incorrectly thought I don't know what the logic _should_ be

[CDU] Cleanup logic for DECEL ETA calculation

if (mcdu.flightPlanManager.decelWaypoint) {
            const idx = waypointsWithDiscontinuities.findIndex((e) => e.wp.cumulativeDistanceInFP > mcdu.flightPlanManager.decelWaypoint.cumulativeDistanceInFP);
            if (idx > 0 && idx < waypointsWithDiscontinuities.length) {
                mcdu.flightPlanManager.decelWaypoint.cumulativeEstimatedTimeEnRouteFP = mcdu.flightPlanManager.decelWaypoint.cumulativeDistanceInFP / groundSpeed * 3600;
                mcdu.flightPlanManager.decelWaypoint.estimatedTimeOfArrivalFP = utcTime + mcdu.flightPlanManager.decelWaypoint.cumulativeEstimatedTimeEnRouteFP;
                waypointsWithDiscontinuities.splice(idx, 0, {
                    wp: mcdu.flightPlanManager.decelWaypoint,
                    fpIndex: -42
                });

This code just tries to put the DECEL point in the correct position in the flight plan, its coordinates are calculated in another place as 32nm from DEST, and can confirm I saw it glitching as well for a few frames at times.

I did 3 flights with the a320 today, with the latest master every time, and the first two times I faced this bug, I just finished another flight without any issues. The only difference besides the F-PLAN itself was that for the ones that I had the issue, I added some ALT constrains to cruise level waypoints, for example a mid waypoint with FL 350. Don't know if have something to do with that. Also took a look to the code but looks like the conditions to activate the approach are good, the only part that I'm not sure is on the A32NX_NavSystem.js file, line 330:

if (this.currFlightPlanManager.isLoadedApproach() && !this.currFlightPlanManager.isActiveApproach() && (this.currFlightPlanManager.getActiveWaypointIndex() == -1 || (this.currFlightPlanManager.getActiveWaypointIndex() > this.currFlightPlanManager.getLastIndexBeforeApproach()))) {
            if (SimVar.GetSimVarValue("L:FMC_FLIGHT_PLAN_IS_TEMPORARY", "number") != 1) {
                this.currFlightPlanManager.tryAutoActivateApproach();
            }
        }

it could be to do with the function: tryAutoActivateApproach()
or to be with when it is called:

if (SimVar.GetSimVarValue("L:FMC_FLIGHT_PLAN_IS_TEMPORARY", "number") != 1) {
this.currFlightPlanManager.tryAutoActivateApproach();
}
you can find it being called in: A32NX_NavSystem.js and i suspect it could be to do with it.

I also had this issue with the latest master. It happened litterally in the middle of the flight (EDDM -> LGIR,
approx. 1h after takeoff). DECEL was not passed at that time
original_e2376373-051c-4836-bd5f-2ef300a2e740_Screenshot_20201029-105628_Chrome

Perhaps this helps you out: DECEL was (as expected) a few miles before the airport.
Microsoft Flight Simulator Screenshot 2020 10 29 - 10 33 13 51

@billsux yeah decel looks correct for me, even tho it should be on the line xD

I made several flights the last days and there was no issue at all. Of course that doesn't mean, that the problem doesn't exist. But there has to be a precondition for it to happen.

Long or short haul?
CRZLevel (higher or lower ones)?
Heavy or light weighted?
Used Appr procedures like a STAR or not?
Inserted the landing rwy / appr (MCDU) at the beginnig of the flight or later?

The last few times I experienced this, it was short hauls at FL350-370 with a light payload with STARS and arrival runway selected before takeoff.

I am currently performing a long haul flight at FL350 with a heavy payload with STARS and arrival runway selected before takeoff and have been in flight for 3hr 27 with no approach phase activated.

I don't insert a landing rwy from the beginning. Maybe that's a difference...?

Is the decel point calculated if a arrival runway is not set? Because multiple people say they saw the decel point flashing which could be causing the appr phase to activate. That could be the difference. It might be worth a try to set an arrival runway and see if the issue occurs on your end.

I can confirm this is an issue in the latest master.

Found the issue, it is related to #1505 but in a very subtle way, looking into it to see if there's a way to patch it cleanly.

I have just flown Schipol to Heathrow and did not have a DECEL point at all and ILS would not connect/approach mode would not activate. Worked fine on default A320 on same plan.

Yep, just tested this again both on FBW Neo and default. When I flew the FBW there was no DECEL in FMC but there was in Default. This was using the same pln loaded from a file and ILS27R. A bug in the new master for FBW, prior to the patch and the prior master all was fine again on this same pln

Noticed that as well, is due to the last update, but it's not related to this, there's no DECEL even on the ND, looking into it, probably some new code needs to be ported.

Found the missing code, will push fix soon after I test some more.

Great, thanks - managed to land the Airbus FBW with a full manual approach. Not saying it was a smooth landing but at least not the black screen with 'Overstressed Aircraft' note!

Was this page helpful?
0 / 5 - 0 ratings