Expand and clarify information in landing calculator pages

[Valastiri]

Copied from the Discord #docs channel provided by donbikes

Hey all, here is some new information that should be provided in the documentation for using the landing performance calculator. https://discord.com/channels/738864299392630914/754130199804772372/925605355919138816 NOTAMs and ATIS should contain runway condition codes whenever the runway is not dry. This message identifies how to go from the code to the runway condition identifiers in the calculator (good, good-medium, etc.) (We should add the code in parentheses after the descriptor in the calculator.) Also, the link to the SkyLibrary article and the use of the term "Landing Distance Required" is inappropriate for this calculator. The required landing distance is based on different parameters and applies at takeoff where it can limit the takeoff weight. It would be included in a takeoff performance calculator. This landing distance is an "operational landing distance" that is used to perform a landing distance assessment prior to landing. It is mostly for addressing wet and contaminated runway conditions.

Recommendations from Mav -> Inclusion into the flyPad Landing Calculator Page

[donstim]

Some thoughts for consideration:

1. Replace the introductory text (the 3 paragraphs above the screenshot of the calculator) with the following: "The primary purpose of this calculator is to aid the pilot in assessing whether a landing can be safely made within the given runway length in the existing conditions. The pilot can also use this tool to determine the appropriate level of braking and whether reverse thrust is needed to stop within the available runway distance. The calculator results are shown both numerical and graphically. Variations in airplane configuration, approach speed, runway surface condition, and other parameters can also be investigated to see their effect on the airplane's landing distance. The landing distance results include a safety margin of 15% added to the calculated distance.

[Insert screenshot of calculator here?]

The calculator provides results for the full range of runway surface conditions (even though the frictional characteristics of these surface conditions are not accurately represented in MSFS 2020 yet). The runway surface condition inputs in the calculator are specified in terms of braking action and the runway condition code associated with that braking action. The following table shows the correlation between runway condition codes, braking action, and a description of the conditions that cause the assigned braking action. The table also provides the maximum allowable crosswind value for each runway surface condition.

Runway Condition Code Correlation Matrix.pdf

(To be continued tomorrow)

[Valastiri]

Ah yes thanks I'll be picking this up soon -- end of year holidays had me a bit busy

[donstim]

In case you want to change formatting in any way to be consistent with how the guide is formatted, here is the Word version of the correlation matrix: Runway Condition Code Correlation Matrix.docx

Continuing on:

Under Usage:

I suggest starting with, "The initial state of the calculator has all input fields blank except for Runway Condition (Dry), Flap Setting (Full), Overweight Procedure (No), and Reverse Thrust (No). All input fields must be filled in order to activate the "Calculate" button. Using the "Clear" button will return the input fields to the initial state." Then continue with what is currently in the guide.

Under "Rwy Condition," I suggest adding the following: If runway condition codes are provided in the ATIS or NOTAM report, they will be in the form X/Y/Z, where X is the code for the first third of the runway length, Y is the code for the middle third of the runway length, and Z is the code for the last third of the runway length. You should use the lowest code for the section of runway you will be using for landing. Normally, all runway sections should be considered, unless you are sure that your landing distance will allow you to stop or use a runway turnoff before the last third of the runway. For example, if the code is 5/3/3, you should use a code of 3 (Medium) for your landing distance calculation.

Codes are not required to be given when the runway is dry, so if no code is given, and there is no weather information to the contrary, you can assume the runway is dry. You should use all available weather information to make a determination of what code to use.

Example screenshot (You may want to mark up the screenshot to point to or circle the conditions codes and the runway identifier. Can also note that FICON preceding the codes stands for Field Condition Report. This is used in the U.S., but other countries may use RCC (Runway Condition Code):

[donstim]

The units for each input should also be identified. Currently, the calculator is limited to using only the units identified in each of the input fields. In the future, options for using different units will be provided.

For the Overweight Procedure bullet, I suggest adding the maximum landing weight (67400 KG) as a reminder. I don't know if we provide that anywhere else. It isn't given in the Dispatch Overview page of the EFB.

For reverse thrust, I suggest changing to: "May be subject to airport requirements. If there are airport requirements regarding the use of reverse thrust, these requirements can be found on the airport chart. (See example below.)"

All the screenshots will need to be re-done since the UI and some of the calculations have changed. The approach speeds used in the examples appear to be unreasonably high, and the LDA used in examples 2 and 3 appears to be unreasonably short.

[donstim]

Any word on the status of this issue?

[Valastiri]

Apologies this one slipped by me! I'll start this up tonight and hopefully, have a PR up as well.

Will also check in to see if this would be part of the flypadOS3 PR... but since that might not see finalization until experimental branch is done testing it's likely we'll get this in for the current iteration first.

[Valastiri]

We're going to potentially put this into flypadOS3 PR instead. I might first make a small branch with the information and then move on from there. At least it would be included and we can figure out where/when to deploy it (i.e. production or later flypadOS3 PR).