Descent profile and manual constraints

[thierryd]

It seems that the descent profile will not respect any altitude (or speed) constraints entered manually. If I manually enter an altitude constraint, let's say FL100 for the next waypoint on the flight plan and roll down the altitude below FL100 (in managed mode) the PFD would not display FL100 in magenta. It displays the altitude set in the FCU in blue. Altitude restrictions that are part of the STAR do correctly show in magenta in the same scenario.

[Buford]

Exactly same behavior here.
And another vertical profile related issue: The TOD symbol on the ND does not match with the (correct) calculation of the TOD in the MCDU even when no altitude constraints are entered manually.

[Buford]

Here an example. While MCDU correctly shows TOD 42 NM before LAMUS, the symbol is shown at LAMUs on the ND.
And it is not caused by scaling, it stays that way even when coming near.

[bbruechmann]

Hi JL, i can confirm what what Buford and Thierry found. In general there seems to be something messed up in the FMGS management for decent profile. A major point for me is that the FMGS/FBW commands thrust increase instead of increase the vertical speed in case the ac gets below the managed speed range. This is really an issue because it´s something immanent part of the decent management of the real Airbus, that you can really "manage" the decent profile.
For instance: in case you want to increase the vertical speed to match a specific altitude, you can set a lower speed as selcted speed via the FCU and let the ac slow down to that speed. Let´s say green dot speed plus 10 or so. If you go back then to managed speed, which is at a range of 280 to 320 knots i. ex., the ac should increase dramaticly the vertical speed by lower the pitch, while the autothrust system let the engines idle. This can produce a vertical speed of 5.600 up to 6.000 ft per minute vertical speed, what is wanted.
Jeehell FMGS instead commands the engine to thrust increase, which is really wrong.
This Behavior was much more realistic simulated in the older builds of FMGS, but since build 56 i think the FMGS/FBW shows up with this issue.
I hope you could look into this and change this very important management part of the FMGS.

[jeehell]

I don't think I understand your message. To match a constraint by increasing V/S you would NEVER first slow down then accelerate to increase the V/S, this does not work like that. The aicraft adds thrust once the VDEV is roughly higher than 250 ft, in which case it's only way to get back on profile is using SPEED mode and 1000fpm target.

[bbruechmann]

To match a constraint by increasing V/S you would NEVER first slow down then accelerate to increase the V/S, this does not work like that. The aicraft adds thrust once the VDEV is roughly higher than 250 ft, in which case it's only way to get back on profile is using SPEED mode and 1000fpm target.

Hi JL. sorry but i have to argue that, hoping you´re not gonna hate me.
What i mean is not related to match a constraint. It´s more related to some changes of the FMGS management which where already correct in former builds. The changes you made meanwhile may affect also the mismatch in computations or in matching constraints, because we exspecting a specific reaction if the FMGS as we where trained by the type rating course.

When i made my type rating course, my Instructor showed us, how you schould manage the decent exactly that way in the real aircraft. And at that time, Jeehell FMGS acted the same way, what it does not anymore since build 56 or so. The reason why especially this behavior was discussed in the type rating course, was to understand why well trained A320 Pilots never ever have to use V/S mode in descent, which is really really dangerous if you are not aware, that in V/S mode, the ac does not have a fail save to get into over- or even underspeed.
That´s the reason why in reallife, in case you may end up too high and too fast at the final descent point, which would end in a rejected landing or go arround, you stay in managed or open decent mode and use the FMGS system logic instead to get a much higher rate of decent for a short time, when the ac tries to catch up the managed speed. In fact the real ac usually increase the rate of decent at first to keep a specific speed instead of adding power to the engines.
Have that said, this does not mean that under no circumstances the ac never increase thrust, of course. It´s just that it would first increase the vertical speed as i have discribed.
Even if you are not need to catch up the descent profile, because you are way above the profile, the real aircraft uses primary slight changes of the decent rate to keep the ac within the managed speed range. Only if that would not have enough effect, i. ex. if you level off, the ac add thrust.
Don´t get me wrong, please. This is only meant in short words, and i know that in fact it´s much more differential and complex. But actually it seems the ac is nailed to specific rate of decent and allways increase engine power to control the speed while it decents and that´s just not how the real aircraft does. Usually the engines stay at idle in an continous descent and don´t need thrust unless the decent isn´t decrased.

I give you an example. In case you will not have the allowance by ATC to decent when you reach your FMGS computed TOD, it is common procedure to change into selected speed mode and slow down the ac instead. This can be done down to Green dot speed. Then, once you get the allowance for your decent, you put the ac as usaul in managed decent mode and change the speed back to manged speed. The real aircraft will then go into a high rate of decent in order to increase the speed. It may also add some more thrust to the engine aswell, but that is usually not nessecary.
What i try to say is, that Jeehell FMGS doesn´t even think about a significant higher rate of decent. Instead it allways add thrust ONLY and thats´s not right.

Another example: If the ac is in managed decent mode and let´s say keeps the managed speed exactly but your VDEV is way too high, let´s say 5.000 or 10.000 ft. It schould be possible to increase the rate of decent by using the speedbrakes, to reduce the VDEV. But if i do this in Jeehell it add power to the engine to compensate the increase of the descent rate. And this is definetly not right.

[jeehell]

Have you actually flown the aircraft after your type rating? because you seem to confuse a few things?
First, even in THR IDLE/DES mode, the real ACFT does add thrust, that can be seen on the EWD where you don't get the IDLE message.
When the ACFT switches from THR IDLE to SPEED (MACH) mode that means that you are too low below the profile, even at the lower limit of the managed IAS your flight path is still too steep and you keep diverging from VDEV target. It will add thrust and accelerate to the IAS target. This is well described and it works this way, even on the real aicraft (maybe slightly smoother but not much, it is brutal with thrust...).
There is NO reason to increase thrust before increasing IAS/nose down attitude to intercept the VDEV from above. If you encounter that in my software, film it and post it so I can see what is happening.

[bbruechmann]

There is NO reason to increase thrust before increasing IAS/nose down attitude to intercept the VDEV from above.

That´s exactly what is my understanding and expectation, but it was different on my flight.
I will show up with a Video if this missbehavior persists.

But on the other hand it is still very mysterious aswell, that some of us, if not all, have this issue with the TOD/TOC arrow on the ND. Meanwhile the TOD arrow on the ND comes up on every flight, at least. But this isn´t the case for the TOC arrow. Sometimes it´s shown, sometimes not. But i can confirm that the TOD arrow position differ from the MCDU calculation. I have also noticed that the Deceleration indicator (the D in a circle) doesn´t show up, nor the ac is activating the approach mode automaticly when this point is passed.
This could indicate, that the FMGS/FBW computations may have an issue.

I know, it seems we are nagging all the time, but don´t get it this way. Your FMGS is just too important for us homecockpit users, and if course we want it as perfect as possible, never forget the hard work you have put into it.

[thierryd]

Regarding the TOC, this is not necessarily a hard rule but my observation is that there is a higher likelihood to see it if you reduce your current target altitude (keeping it still above your current altitude of course, but not setting it to cruise level quite yet) so that the TOC is before your next waypoint, then you will typically see it (blue arrow) in the early stages of the climb.

[bbruechmann]

When the ACFT switches from THR IDLE to SPEED (MACH) mode that means that you are too low below the profile, even at the lower limit of the managed IAS your flight path is still too steep and you keep diverging from VDEV target. It will add thrust and accelerate to the IAS target. This is well described and it works this way, even on the real aicraft (maybe slightly smoother but not much, it is brutal with thrust...).

Yes, that is absolute right and maybe i´am too complicated in my discription. My worries is never about being much BELOW the descent path, because as long you are not in high terrain areas it´s not an issue at all, usually (except from nagging by ATC ). The much worse situation is being to much ABOVE the path which ends nearly always in a mess as being to high and too fast at FDP. And when you try to catch up with the path from being too high ABOVE the path, the last thing you would need is an accelaration based on engine thrust when you want to increase the descent rate.
But what i think after your comment, we have the same understanding in fact and will have another closer look what exactly happen in my case.

[bbruechmann]

Regarding the TOC, this is not necessarily a hard rule but my observation is that there is a higher likelihood to see it if you reduce your current target altitude (keeping it still above your current altitude of course, but not setting it to cruise level quite yet) so that the TOC is before your next waypoint, then you will typically see it (blue arrow) in the early stages of the climb.

Exactly what i can see, too. But the blue TOC arrow should be visible anytime your current altitude is below the actual commanded target altitude.

[Buford]

I would like to take up the subject again because the original problem has been somewhat lost sight of and is still unresolved:

It seems that the descent profile will not respect any altitude (or speed) constraints entered manually. If I manually enter an altitude constraint, let's say FL100 for the next waypoint on the flight plan and roll down the altitude below FL100 (in managed mode) the PFD would not display FL100 in magenta. It displays the altitude set in the FCU in blue. Altitude restrictions that are part of the STAR do correctly show in magenta in the same scenario.

It´s not about how to get back on target at a VDEV, the problem is simply, that it is impossible to add an altitude constraint to a waypoint before the second one on a STAR, which gets recognized by the descent calculation and is kept magenta in managed descent. On the ND it stays orange instead of magenta, the MCDU still calculates the old descent profile and does not respect the constraint.
Example:
I fly to EDDF 07L via the KERAX4D RNAV STAR. The Jeppesen chart for KERAX shows a constraint "FL110 or above = +FL110". After loading the procedure into the MCDU, there is even no constraint at KERAX, but that might be a Navigraph issue. Let´s say, ATC orders (far enough away for a normal descent): "When ready, descend to FL110 to be levelled at KERAX".
Shouldn´t it be possible, to add now, still on cruise level, a constraint of FL110 for KERAX in the MCDU, which now gets magenta, so that the TOD and descent path is calculated new, so that I can start a managed descent at the new calculated TOD, which brings me to FL110 at KERAX? Or does the real aircraft not allow to change the once calculated descent profile for a managed descent?
And if I´m right, shouldn´t it even be possible, to dial already a lower altitude, in this example let´s say 5000, into the FCU, while the manually added constraint for KERAX is still respected, in this case "FL110" should be shown magenta in the PFD below the altitude band until KERAX is passed?
--------
Remark: Because my P3D still steadily produces CTDs, I am flying with MSFS and Sven´s private mod, but I still had it identically when I last time could use my P3D, so it should be independent of the used simulator and the mod. A320 FMGS version is latest B61.3.9.
EDIT: Rechecked and corrected: Constraints are taken from the second point of a STAR on, in the example above first for GEDEH, not, as I wrote initially, not before the Final Descent Point. But the problem persists as described, I think, it should be even possible to add an altitude constraint manually for every waypoint of a flightplan?

[thierryd]

As pointed out in the previous message the problem is compounded by the fact that the FMGC doesn't seem to import any constraint (altitude or speed) associated with the initial waypoint in a STAR (despite the fact that such constraint, if it exists, is properly included in the Navigraph data).

[Buford]

…could complete a flight with P3D v5.3 yesterday. Behaviour with manual constraints in P3D is definitely the same.

[Buford]

According to the Thales manual a constraint shown amber means, it is regarded as missed or not reachable by the FMS.
Seems, there is still a calculation bug in the JeeHell FMS (and, btw, similar in other cockpit software).
Another issue apparently related to this one is, that all altitude constraints of an approach procedure are taken as „or above“ from a SimBrief flightplan and have to be changed to „exactly at“ manually, otherwise the approach is initiated too high when flying managed.

[Buford]

I cannot believe, Captain Tango and me are the only ones with that behaviour of the FMS. And I´m pretty sure, the real A320 must be able to keep a constraint added manually for each waypoint of the flightplan.
Perhaps it gets better understandable with an example with pictures. I rechecked it today on a flight from Bremen EDDW to Frankfurt EDDF on this (Simbrief-) route:
EDDW/27 N0368F190 ERLA3Z ERLAD Y804 PIROT T152 KERAX KERA4A EDDF/25R
1. After importing the route from Simbrief via SEC FPLN all constraints of the ILS Y 25R approach are "+" = "at or above", while they should be "at". I show that for DF430, but it is the same for all waypoints up to DF426.

EDDF1.jpg

EDDF2.jpg

As that appears everywhere, I don´t think it´s a problem of the Navigraph (or Simbrief) database, but of A320 FMGS to interpret that.
I corrected that for all waypoints of the approach to "at 5000".
2. At KERAX, there is no constraint, while the chart for the STAR KERAX4A (and the Navigraph procedure) shows a constraint "at FL110" for KERAX.

EDDF3.jpg

EDDF4.jpg

Still on ground I added the constraint.

EDDF6.jpg

Interesting, that the VERT REV page shows an altitude error of +8000, what is absolutely correct, instead of calculating the vertical profile so, that the error disappears.
(Continuing with new post, as one only takes 5 attachments)

[Buford]

On the VERT REV page, the constraint is shown magenta, but on the flightplan page it only appears amber.

EDDF5.jpg

You can see it even better on a screenshot:

1.JPG

The Thales manual sais, magenta stands for unreachable constraints. But from Cruise Altitude FL190 to FL110, these are only 8000ft, 30 NM should be more than enough for that descent, so that cannot be a problem on this route.

2.JPG

Inflight nothing changes with that. The TOD is shown far behind (!) KERAX, neglecting the inserted constraint. At the beginning, the Level Off is still shown before KERAX, but of course with the descent rate of 900 ft/min in managed descent, the aircraft does not reach FL110 before KERAX.

3.JPG

6.JPG

(continued in new post)

[Buford]

The airplane crosses KERAX higher than FL130 and reaches FL110 far later, even behind GEDEH.

11.JPG

13.JPG

And even worse:
If I turn the altitude to 5000 ft before KERAX, before passing the waypoint with the constraint, on the PFD below the altimeter "FL50" is shown blue instead of still "FL110" in magenta. I also checked that: Given already lower altitude, the aircraft would not keep the constraint, but descent already lower instead of the constraint.

7.JPG

For sure I can reach FL110 at KERAX in selected mode with V/S. But shouldn´t the aircraft be able to do that in mamaged mode, too? And it cannot be correct, it would even fly below a constraint in managed mode!
Anything I´m doing wrong? Or an issue of A320 FMGS?

[Eintagsflieger]

I am having same issues with manually inserted ALT constraints. They are just being ignored by the descent calculation of the Airbus. The CSTR is showing up perfectly on the ND, but it has no effect. There is no magenta ALT indication of the CSTR during managed descent. I have taken a video of it:



Eventually I just misunderstand the Airbus Logic. If so, please let me know.

@Buford
The ALT constraints at EDDF are indeed 5000 or above (+5000) at DF430 and DF426. Also the CSTR +FL110 at KERAX works perfectly fine on my sim when I insert the KERAX4A Arrival.


Overall I love this masterpiece of software! Thanks for your work.