STAR ALT restraints completely ignored

[jrotaetxe 242]

Applied. Do not know when I will have time to flight again (very busy week), but wait for my feedback.

Regards and THANK YOU all.

[jrotaetxe 242]

Well.

The restraints now come well, in a row and correctly displayed in magenta (and respected).

From this point of view is enough. For future refinements, I would take this strategy for the constraints:

If you are in DES mode, take the lower limit as reference (now takes the Upper. Legal but you are always a bit high),

If climbing, take the upper one as "the constraint".

But from the Thrust control point of view, and from the descent path point of view, the thisng has gone very badly. Began the descent a little bit before TOD mark and the first impression was very good. Mild descent before crossing TOD and a slightly more energical after crossing it.

But things became very odd after crossig SEPKA (1st constraint with an At or Lower constraint). This moment was flying 16000 more or less, a little bit low for the next (GURU) but legal.

Then, the bird begins to climb and "forgets" the speed control, keeping IDLE while climnbing, losing speed against height, till the limit

Once in the limit to stall, began a mild descent keeping the minimum speed (as you can see, in the razor blade to stall), till entering in the 15000 of the costraint.

Once "in the cosntraint", Speed mode activated, gaining speed ans normalising the situation

Let me drive your attention to the FDU?. No ALT* and "no mode" displayed...

Once GURU crossed, DES mode activated again, and an energical dive to LOVE (nice, isn't it?) , with the speed completely out of control.

The rest is a repeat of the history. In certain moment, climbed again, and in the moment to catch the glideslope, too high and fast (then diving to the limit)...

Lessons learned:

The parsing of the constraints is good. Can be better, but the info is there, reachable to the rest of processes.

Seems the TOD is better situated, but must check better. The climbing did not allow me obtain a clear feeling.

The control over the speed is lost. Instead of climbing, it should use the brakes. Do not undestand why she began to climb. Perhaps to recover the "ideal" descent path, as she was very low between SEPKA and GURU? (But LEGAL).

So, for me, the Algorthm has 9 states:

Just for reference, not trying to give any lesson, and perceiving it is obvious, but to have a frame as reference....

Kind regards

States.pdf

[welchb21 20]

I had this exact same problem when descending via the ANNEY2 arr into KMIA, had to engage OP DES to keep my speed and flight path decending, this occured after installing the Hotfix 002 for me. I am gonna stick with Version 1.03b for now.

[KyleD 1027]

Okay, this will be looked in to.

[jrotaetxe 242]

HF003.

Performed well, smooth and under control.

Only a last question to the devs.

Why in this kind of restraints, and in descent mode, have they chosen the upper limit instead the lower one?

The reason I question is clear, at least for me. If you are descending, your main interest is to be as low as possible within the publisHed limits. You will control better your speed and you will be more comfortable to catch the nav aids...

Thank you, Kyle. Express my gratefulness to the crew.

Regards

[KyleD 1027]

Why in this kind of restraints, and in descent mode, have they chosen the upper limit instead the lower one?

The reason I question is clear, at least for me. If you are descending, your main interest is to be as low as possible within the publisHed limits. You will control better your speed and you will be more comfortable to catch the nav aids...

Well, I'll break this into two parts, ATC considerations and then descent logic as it should be and as it is now programmed.

The block constraint itself in terms of ATC can be for a number of reasons. Typically, the main two reasons will be other airspace, and then also other procedures, most likely SID's. So, with a block constraint, you can have that 15,000 upper limit so you can have departing aircraft be cleared to higher flight levels as well as having the ability to give them their desired cruise altitudes sooner, while at the same time getting you in your STAR down to the approach environment. So, at that same waypoint, on a SID, the constraint there might be "cross at or above 16,000". That way, you have your 1,000 ft separation and like I said before continue to climb the other aircraft while continuing to get you down. As for the lower limit, typically underlying airspace and terrain are usually the cause for that, but can also be do to navaid reception etc.

Now, for how it is handled by aircrew and by the managed descent of aircraft, that will depend. An aircraft will make its calculations based on the first constraints it has, and then the following constraint after that (This is typically. VNAV calculations come in all shapes and sizes, and older/less complex ones are more limited and only take it on a waypoint by waypoint basis). So, if you have a block constraint like you see there and that waypoint is still 70-80nm from the airport, that's a lot of distance, you don't necessarily need to be hugging 12,000 ft the whole time. That is unless you have a low constraint at the next waypoint. Take for instance if your next constraint is "At 7,000", and it is only 20nm or less from your block constraint, then you definitely want to be at the lower 12,000 ft limit.

From an aircrew standpoint, you want to take a look at all of these things beyond what the VNAV calculations may say. Generally, you'll have a similar conclusion. But, if you don't need to be low, then you don't want to be. Altitude and airspeed give you options if anything were to happen (not that it will in FSX without failure modelling, but you could give yourself a nice simulated engine failure).

So, in the end, the VNAV will take a look at the whole picture, and see where it needs to be and when, in terms of altitude. For the Extended, as you know VNAV is still being tweaked, and hopefully soon, you will be able to see even better what the VNAV is thinking when the VDEV may be implemented.

Hopefully this 1. makes sense and 2. hopefully helped to answer your question without going too far out in the blue.