VNAV KRDU to KBWI

[XPlanePort]

RTE (KRDU to KBWI) BEXGO2 LVL THHMP RAVNN6

 FL230

 

ACROW FL210A

DFORT 284 / FL180A

WALKN 280 / 17000A

JAYOH 280 / 12000A

...

:

 

At FL230 T/D is calculated after ACROW. ACROW FL210A. Current FL230 and above FL210, not too bad at this point:

 

At ACROW at CRZ altitude FL230 (already changed my altitude to 9000 on MCP to start descending at T/D).

Next, DFORT at FL180A, 10NM out:

 

At T/D 508 above.

 

At DFORT 2727 above (V/S 3K):

 

(V/S 4K +) trying to get to VNAV path:

 

At JAYOH leveled out at 18000. "Drag Required". Speed brake out. Engines spooling up to maintain 18000 at 280.

Approaching CAPKO, leveled at 17K (7314 above VNAV PTH), should be at 9K. MCP at 3K.

...

...

...

NAVEY should be at 6K, leveling at 9K. MCP was set to 3K.

From here it is just staying at 9K. MCP is at 3K:

If I am doing something wrong, please let me know.

If you need additional information, please let me know.

If this is already reported, disregard the report.

Thank you!

[mmerelles]

To me, problem here is TAIL WIND. You are having 42 at t/d and up to 62 knots of tail wind during the descend THIS IS HUGE strong tail wind that pushes the aircraft forward making it unable to comply its descend profile (assumed no winds). The FMC keeps asking for DRAG to put the nose down.

 

You have to apply speed braes promptly not to allow the fmc deviate from the vertical profile, you can start your descend sooner than t/d when you are anticipating tail winds.

Ultimately IXEG is working to load and compute wind layers for accurate vnav predictions over windy conditions.

[XPlanePort]

 

I will try to turn off all the weather and try the same RTE.

 

Why would this prevent from descending below 9K? I see how this (TAIL WIND) is effecting my GS and VNAV calculations.

 

I did set my altitude to 9K at some point during the descend, I than changed it to 3K, but it was way before I reached the 9K altitude. Can it be that somehow (in the code) 9K to 3K change on the MCP was not updated?

 

I also promptly use Speed Brake so I don’t go over the set airspeed when autopilot lowers the nose for descend.

 

 

I will report after 0 wind flight.

 

 

 

 

Edited May 2, 2016 by XPlanePort

[mmerelles]

4 minutes ago, XPlanePort said:

 

I will try to turn off all the weather and try the same RTE.

 

Why would this prevent from descending below 9K? I see how this is effecting my GS and VNAV calculations.

 

I did set my altitude to 9K at some point during the descend, I than changed it to 3K, but it was way before I reached the 9K altitude. Can it be that somehow (in the code) 9K to 3K change on the MCP was not updated?

 

I also promptly use Speed Brake so I don’t go over the set airspeed when autopilot lowers the nose for descend.

 

 

I will report after 0 wind flight.

 

 

 

 

 

Yes, trying the same route with no winds could be a good one to compare.

I did not notice you also mention the aircraft got stuck at 9k. Usually this means you did not reset the MCP on time but you did. It could be a bug or something we did not see yet.

Next time this happens please press DES button on the FMC to see what the altitude constrain active is

[XPlanePort]

With 0 Wind and the same RTE:

 

T/C was reached (FL230) at the point shown on the HSI:

 

T/D in HSI is showing after ACROW .64/FL210A (my FL230 CRZ is in the vicinity):

 

Changed ALT to 12K 5NM (or so) before ACROW, to get ready for the descent:

 

At T/D the plane did not start the descent:

 

At DFORT the DES changed and aircraft started the descent:

 

I have the X-Plane paused now.

Let me know I you need me to continue the flight.

[mmerelles]

Something is way wrong here.

The T/D prediction is consistent, i did expect that because it doesn't account for winds forecast as of now.

I have seen the arrival procedure RAVVN6 and the transition THHMP calls mandatory for 280 knts and FL250A. You are out of speed and altitude entering the procedure. I am wondering if this makes the fmc go wrong not able to handle properly this erroneous scenario? just speculating.

You can try a higher altitude to compare?

 

THHMP star procedure https://skyvector.com/files/tpp/1605/pdf/00804RAVNN.PDF

 

[Litjan]

Hi,

and thank you for the excellent report - did you output a debug.txt by any chance? This enables us to examine the vertical profile with the click of a button, instead of reflying the whole route ourselves...

Will look at this nonetheless, of course!

Jan

 

[XPlanePort]

Hi Jan! Thank you so much for the plane.

I did not output to the debug. Is this the 4(....)? I will try.

As was pointed out by mmereless regarding the RAVVN6 (older RAVVN5 in the NAV database), the THHMP is at 280 /FL250A.

I was flying CRZ FL230 because this is what is being reported on flightaware:

How is something like this handled in real life?

I did the flight with CRZ FL310 last night and was happy smiling how good the plane was following the VNAV path, until… I think it has something to do with how the LNAV is calculated for the ABOVE (A) altitude restrictions. The VNAV path was perfectly centered for (A) restrictions, the plane was at the same altitude (I was expecting it to stay above the FL***A restrictions, but descent).

Even though the (A) restrains were lower for every next fix on the SID, the plane was flying at the same altitude, complying to the (A) restrictions, but too high when (AT) restriction kicked in. At that point VNAV path was way below the current altitude and 6K (plus) dive (with spoilers out) was commenced… Eventually the plane was able to get to the VNAV path with overspeed and VNAV turning off two times (I was able to turn it back on).

Anyway, I was not taking any screenshots last night. I am going to fly the RTE now with FL310 and 0 wind, output to debug.txt, take screenshots and report back.

Having too much fun with this!

[Litjan]

Thanks for the report and getting back to me on this!

If you enter a cruise of 230 but have restrictions that are higher than that, I think the FMS will disregard them (or even eraze them for you). This will be part of the VNAV tuning that we will do over the next weeks and months...

Again, really happy that you report this, and yes, make sure that you have DEBUG OUTPUT selected in the PREFERENCES and then click the .... on the CDU. You will get a message "debug exported" or so - and the debug.txt will be in the aircrafts root folder.

Thanks, Jan

 

[Litjan]

Thanks for the report and getting back to me on this!

If you enter a cruise of 230 but have restrictions that are higher than that, I think the FMS will disregard them (or even eraze them for you). This will be part of the VNAV tuning that we will do over the next weeks and months...

Again, really happy that you report this, and yes, make sure that you have DEBUG OUTPUT selected in the PREFERENCES and then click the .... on the CDU. You will get a message "debug exported" or so - and the debug.txt will be in the aircrafts root folder.

Thanks, Jan

 

[XPlanePort]

 

T/D:

 

Altitude set to 9000:

 

 Starting the descent:

 

To FZEEK On the VNAV Path:

 

 Leveling at 23000 at FZEEK on the way to WHHTE (WHHTE is at or above 23000 on SID chart. It is at FL230 in the database):

 

To ACROW at 23000 (above FL210):

 

To DFORT at 23000 (above FL180):

 

To WALKN at 23000 (above 17000):

 

Just now starting to descent from FL230 (20NM to CAPKO 240/9000):

 

At JAYOH 18,720 (on the SID chart, JAYOH below 12000 above 11000. In the database 12000A):

 

At JAYOH to CAPKO at 18,120 (5141 above the VNAV path):

 

Trying to get on the VNAV path. V/S 6000. Speed increasing. Speed brake out.:

 

VNAV DISCONNECT (Speed?):

 

Was able to reengage VNAV. Altitude set from 9000 to 6000:

 

Back on VNAV path:

 

I was able to generate the attached debug file just after takeoff. Looking at the file, it looks like I can generate them at different points.

If you need me to generate more debug files, please let me know.

 

IXEG_debug_10.txt

Generated after takeoff.

IXEG_debug_01.txt

Edited May 3, 2016 by XPlanePort

[XPlanePort]

IXEG_debug_02.txt

Generated after "Back on VNAV path:"

IXEG_debug_02.txt

[reflic]

If you want to avoid the vnav hassles from what I've experienced. You have to get rid of those above altitudes in your FMC especially if you're using navigraph, the plane will never meet a restriction with the above waypoints right now from my experience. But I know they'll fix it in the coming weeks. So say Instead of 17000A just put 17000 and you will decend fine, below restrictions work really well too.

Edited May 4, 2016 by reflic

[Litjan]

10 hours ago, XPlanePort said:

IXEG_debug_02.txt

Generated after "Back on VNAV path:"

IXEG_debug_02.txt

Hi XPlanePort,

thanks for the detailed and excellent report. I see the quirk and I am sure Tom will be able to reproduce the problem very quick. We are currently still in the "kill all crash-issues mode" - the fixing of erroneous VNAV path will ensue very soon. Your case is logged and we will look at it fairly soon.

For now (just as a temporary workaround) try to stay ahead of your FMC´s VNAV calcs. The plane will rougly do 1000 feet in 3 miles. Anytime you see that your next restriction (like 9000 at CAPKO) can´t be made, assume the FMC is trying to **** with you and revert to FL CHG and make the plane go where YOU want it to go.

Airbus came up with "4 golden rules for pilots" - well, actually two of them have been there since the Brothers Wright - and one of them is "Take action if things don´t go as expected!". That´s why there are still pilots in the cockpit these days. The simple task of flying from A to B could be easily done by a computer... like our FMS .

Jan

 

[tkyler]

awesome.  THX for posting that debug file.....this is what we do with it...analyze the VNAV path.  The path should descend after WHHTE and I can see instantly the issue and we can begin working on a fix....though we are focused on soft crash prevention at the moment.

-tkyler

 

Edited May 5, 2016 by tkyler

[XPlanePort]

AWESOME is what you Tom and your team have accomplished. I am just having fun.

 

Thank you!

[jfjoubert]

Just read through this post... and I'm absolutely amazed by the feedback and interaction from IXEG.

And the fact that you actually share some info with regards to your bug fixing and issue resolution processes.

Well done... keep it up.