Fenix A320. Descent in managed mode except speed.

[Vitold69 47]

Hi guys

I have noted strange behavior of Fenix A320 in the latest version .214

I'm in descent with some waypoints with constrains ahead. All in managed mode. AP and A/T are ON.  Below 10000 feet managed speed is 250 kn. Then controller asks me to slowdown to 220 kn. I switch speed knob in command mode. There is 250 in the speed window as it should be. I set command speed to 220 and plane starts to slowdown by DECREASING ITS DESCENT RATE! Say from 2000 fpm to 600-700 fpm. When speed reaches 220 kn plane almost dive to catch next waypoint constrain. I didn't note such behavior prior .214. In my understanding if you need to slowdown in all managed mode except speed you have to use spoilers only but descent rate. And computer calculates necessary descent rate based on speed to perfectly catch next waypoint constrain.

What I am doing wrong? 🙁

[Fiorentoni 4,358]

1 hour ago, Vitold69 said:

Hi guys

I have noted strange behavior of Fenix A320 in the latest version .214

I'm in descent with some waypoints with constrains ahead. All in managed mode. AP and A/T are ON.  Below 10000 feet managed speed is 250 kn. Then controller asks me to slowdown to 220 kn. I switch speed knob in command mode. There is 250 in the speed window as it should be. I set command speed to 220 and plane starts to slowdown by DECREASING ITS DESCENT RATE! Say from 2000 fpm to 600-700 fpm. When speed reaches 220 kn plane almost dive to catch next waypoint constrain. I didn't note such behavior prior .214. In my understanding if you need to slowdown in all managed mode except speed you have to use spoilers only but descent rate. And computer calculates necessary descent rate based on speed to perfectly catch next waypoint constrain.

What I am doing wrong? 🙁

Well how else is the plane supposed to slow down except for lowering the descent rate (thrust will go to idle of course)?
The glidepath calculation with managed descent uses the speeds in the fmc as the calculation base. Once you leave the managed (speed) mode, it will do what you tell him to and obviously can't follow the glidepath anymore, since you manually chose another speed than the one used for the TOD calculation.
So if ATC gives you another speed than the one you calculated with, there's a couple of things you can do:

1) Anticipate this by descending earlier and not in managed mode, but in VS. You'll have enough cushion this way to handle ATC restrictions. That's what's done in real life (pilots usually know very well when they can expect ATC interventions because they fly those routes a lot).
2) Leave it be, you'll be descending a bit slower at 220 kts (less speed = less drag), but usually you can still make it, unless there are alt restrictions in the next couple of waypoints.
3) Use the speed brakes. That's what they're made for.

The drawback of VNAV is that it relies on the FMC data only and ATC will interfere with that in congested airspace. So you're not doing anything wrong, you just have to anticipate and preplan for those situations.
 

[Vitold69 47]

2 hours ago, Fiorentoni said:

Once you leave the managed (speed) mode, it will do what you tell him to and obviously can't follow the glidepath anymore, since you manually chose another speed than the one used for the TOD calculation.

Nope. It follows glidepath including constrains with speed in command mode. That's the reason plane almost dive to catch the next waypoint constrain. I believe the problem is after the last update plane use too aggressive pitch change to slowdown. Plane wants to decrease to chosen speed as soon as possible. And this is wrong. The only way I found to avoid this is to decrease speed by increments in no more than 5 knots. Then descent rate is almost not changed. Then plane follows glidepath till the ground just perfectly. With speed in command mode and all others in managed one.

[Fiorentoni 4,358]

13 hours ago, Vitold69 said:

Nope. It follows glidepath including constrains with speed in command mode. That's the reason plane almost dive to catch the next waypoint constrain. I believe the problem is after the last update plane use too aggressive pitch change to slowdown. Plane wants to decrease to chosen speed as soon as possible. And this is wrong. The only way I found to avoid this is to decrease speed by increments in no more than 5 knots. Then descent rate is almost not changed. Then plane follows glidepath till the ground just perfectly. With speed in command mode and all others in managed one.

I don‘t really understand what you are saying. What is „command mode“? You should stick to the Airbus phraseology or it will be just confusing.

“Plane wants to decrease to chosen speed as soon as possible. And this is wrong.“
Again, it is not. It‘s exactly what it‘s supposed to do. If the pilot wants the aircraft to go to a certain speed immediately, the aircraft has to do it immediately without taking care of passenger comfort. This is mandatory because the pilots has to have immediate control over those things for safety reasons.
That‘s why in real life pilots won‘t just pull the speed knob (or use FLCH on the Boeing) when ATC tells them to slow down to e.g. 220kts. They will instead pull the alt knob to enter VS mode, then pull the speed knob to set it to 220 kts, and then slowly decrease VS until the 220 kts are reached. That‘s the only way.

Now that said it‘s possible Fenix in an update changed the rate of pitch change when pulling the speed knob, but I wouldn‘t know since I don‘t just pull the speed knob when in managed descent (see above). Anyway, you can expect an aggressive pitch up (as explained above) as long as it‘s within the aircraft G-force limits - that‘s what it‘s supposed to do (see above). Do you feel the pitch up is outside of the g-force limits? Is it that extreme that it would rip the wings off in real life?

[SierraDelta 1,355]

There's another way of doing this.

Pull the speed knob to activate SELECTED mode, but don't turn it yet.
On the MCDU PERF page ACTIVATE APPR MODE.
Dial the speed knob back to your desired mode, the a/c will not pull up to reduce speed, but will maintain v/s to stay on the profile, so you may need to use the speedbrakes.

[Bobsk8 12,853]

15 hours ago, Vitold69 said:

Nope. It follows glidepath including constrains with speed in command mode. That's the reason plane almost dive to catch the next waypoint constrain. I believe the problem is after the last update plane use too aggressive pitch change to slowdown. Plane wants to decrease to chosen speed as soon as possible. And this is wrong. The only way I found to avoid this is to decrease speed by increments in no more than 5 knots. Then descent rate is almost not changed. Then plane follows glidepath till the ground just perfectly. With speed in command mode and all others in managed one.

He gave you the correct answer.

[Fiorentoni 4,358]

4 hours ago, SierraDelta said:

There's another way of doing this.

Pull the speed knob to activate SELECTED mode, but don't turn it yet.
On the MCDU PERF page ACTIVATE APPR MODE.
Dial the speed knob back to your desired mode, the a/c will not pull up to reduce speed, but will maintain v/s to stay on the profile, so you may need to use the speedbrakes.

I'm not an Airbus driver so I'm curious about that: I thought all that ACTIVATE APPR MODE does is setting the managed speed to green dot. You are basically saying it will also prioritize the path above the chosen speed? I've never heard that before. What is the reasoning behind that?
Does that also work with extreme speed differences (like you set 220kt, you're at 320kt right now, and it will not pitch up at all)?

[Vitold69 47]

2 hours ago, Bobsk8 said:

He gave you the correct answer.

No. FMGS continue to recalculate glidepath to meet all constrains even if speed is in selected mode and all others in managed one.

[Bobsk8 12,853]

31 minutes ago, Fiorentoni said:

I'm not an Airbus driver so I'm curious about that: I thought all that ACTIVATE APPR MODE does is setting the managed speed to green dot. You are basically saying it will also prioritize the path above the chosen speed? I've never heard that before. What is the reasoning behind that?
Does that also work with extreme speed differences (like you set 220kt, you're at 320kt right now, and it will not pitch up at all)?

I used to fly Fenix all the time, now I am on 737, but if I remember correctly, approach mode when activated controls the speed with your flap settings. The more flaps are down, the slower the AT speed. Probably get a more accurate answer on the Fenix Discord page. 

Edited October 15, 2023 by Bobsk8

[Vitold69 47]

1 minute ago, Bobsk8 said:

now I am on 737

Yeah we know this! 😁

[cavaricooper 2,615]

18 hours ago, Vitold69 said:

Nope. It follows glidepath including constrains with speed in command mode. That's the reason plane almost dive to catch the next waypoint constrain. I believe the problem is after the last update plane use too aggressive pitch change to slowdown. Plane wants to decrease to chosen speed as soon as possible. And this is wrong. The only way I found to avoid this is to decrease speed by increments in no more than 5 knots. Then descent rate is almost not changed. Then plane follows glidepath till the ground just perfectly. With speed in command mode and all others in managed one.

Agreed- until the next update I have resorted to selecting individual SEL SPD rollback waypoints and then using the slow roll back method to allow for a non-Martini spilling vertical path. Looking forward to Fifi's next iteration.

[martinboehme 522]

54 minutes ago, Vitold69 said:

No. FMGS continue to recalculate glidepath to meet all constrains even if speed is in selected mode and all others in managed one.

It's recalculating the vertical path, but it may not be able to achieve it.

The vertical path is computed based on the assumption of an idle descent at 250 knots below 10,000 feet (in the absence of other constraints). If you select a lower speed, you'll get closer to green dot speed (the best glide speed). You're therefore gliding more efficiently, your glide angle will therefore become shallower and you'll deviate above the vertical path. The FMGS can't do anything about this as the vertical path already assumes an idle descent - and it obviously can't reduce the thrust below idle. What you as the pilot therefore need to do is to extend the spoilers (which the autopilot has no control over).

In the opposite scenario, if you increased the speed above 250 knots, the FMGS would be able to maintain the vertical path by adding power (which it does have control over).

[Vitold69 47]

2 minutes ago, cavaricooper said:

Agreed- until the next update

Lets see. Another problem is Fenix FMGS almost ignores altitude constrains with + and -. For instance there is a first constrain with -5000 and shortly another one with +3000. Fenix FMGS passes first waypoint EXACTLY at 5000 then plane dive to pass the second one EXACTLY at 3000. Instead of calculating constant descent rate and pass the first one say at 4500 and second at 3500 (keeping in mind the third constrain if any). 

[Vitold69 47]

9 minutes ago, martinboehme said:

What you as the pilot therefore need to do is to extend the spoilers (which the autopilot has no control over).

Exactly. In managed mode plane should be slowed down by spoilers not by automatically (FMGS managed) decreasing its descent rate. 

[Tom_L 558]

1 hour ago, Vitold69 said:

No. FMGS continue to recalculate glidepath to meet all constrains even if speed is in selected mode and all others in managed one.

 

37 minutes ago, martinboehme said:

It's recalculating the vertical path,

I think a clarification is needed: "If the flight crew reverts to the SELECTED speed/MACH mode during descent, the profile is not modified and the aircraft flies the same profile at the FCU selected speed/MACH value." (from the A320 FCOM, emphasis by me).

Maybe the pitch changes are overexaggerated, but the general behaviour is "by the book". By reducing the rate of descent in order to slow down (what else at IDLE thrust?) you'll get above the calculated path, and as soon as the speed is reached, the plane tries to get back onto it ("dive").