Inconsistencies in the Approach Procedure Panel

[JaapV]

Hi Urs,

 

Trying to find the decision altitude (DA) for LOWI (Elevation 1900 ft) for landing with a Boeing 737-800 (cat. C) I ran into some inconsistencies in the data of Procedure Panel item 1 and item 6 I don’t understand. Also in the data of other airports than LOWI I found the same kind of inconsistencies.

For the data I used Navigraph AIRAC 2105 and the files LOWI.txt (modified 7-11-2019 12:05) and 0Default.txt in the Minima directory of EFB2, also based on AIRAC 2105.

In my opinion the DA or MAP data in item 1 (Profile View) of the Procedure Panel should be a graphical representation of the data in item 6 (Minimums, MDA, DA or MAP).

 

Example 1:

Approach Procedure:    RNAV/RNP 08-Y

Key in LOWI.txt:             H08-Y     //RNAV/RNP

   Corresp. cat C data:   C;;A7100;5.0KM

Key in 0Default.txt:        H*     //RNAV(RNP)

   Corresp. cat C data:   C;;H250;800M

Data in item 6:               C  08  RNAV/RNP  2410 / 1.5 km (in light yellow: ‘default’ value)

Data in item 1:                WI814(MAP)   7100

De LOWI.txt info corresponds with the corresponding Jeppesen approach chart.

 

In item 6 I should expect:  C  08  RNAV/RNP    7100 / 5.0 km (in white) based on the ‘standard’ value in LOWI.txt. Besides the indicated ‘default’ value (RNAV/RNP  2410 / 1.5 km in light yellow) is not equal to the real default value (C;;H250;800M) in the 0Default.txt file.

The grey MAP arrow in item 1 starts at level 2410 (I presume) instead of 7100.

Questions:

1. Why is a ‘default’ value used for item 6 which is not even equal to the default value in the 0Default.txt file?

2. Why does the MAP arrow in item 1 start at 2410 instead of 7100?

3. Where are the values 2410/1.5 km based on?

 

Example 2:

Approach Procedure:    RNAV/RNP 08-Z

Key in LOWI.txt:             H08-Z     //RNAV/RNP

   Corresp. cat C data:   C;;A2900;2.4KM

Key in 0Default.txt:        H*     //RNAV(RNP)

   Corresp. cat C data:   C;;H250;800M

Data in item 6:                C  08  RNAV/RNP  2410 / 1.5 km (in light yellow: ‘default’ value)

Data in item 1:                RW08(MAP)   MAP arrow starts at RW08 level.

The LOWI.txt info corresponds with the corresponding Jeppesen approach chart.

 

In item 6 I would expect:  C  08  RNAV/RNP    2900 / 2.4 km (in white) based on the ‘standard’ value in LOWI.txt. The MAP arrow starts at level RW08 instead of level 2900; IMHO a missed approach point is never located at RWY level.

Questions:

4. Why is a ‘default’ value used for item 6 (which is not even equal to the default value in the 0Default.txt file) instead of the available value in LOWI.txt?

5. Why does the MAP arrow in item 1 start at level RW08 instead of 2900?

6. Where are the values 2410/1.5 km based on?

 

For the approach procedures RNAV/RNP 26-E and RNAV/RNP 26-Z I encountered the same kind of discrepancies.

 

Example 3:

Approach Procedure:    LOC 26

Key in LOWI.txt:             L26       //LOC

   Corresp. cat C data:   C;;A3300;3.7KM

Key in 0Default.txt:        L*         //LOC

   Corresp. cat C data:   C;;H250;800M

Data in item 6:                C  26  LOC  3300 / 3.7 km (in white: standard value)

Data in item 1:                 ML26(MAP)       MAP arrow starts at 3300 (I presume)

Unfortunately I cannot find the corresponding Jeppesen approach chart for LOC26.

 

The data in item 6 corresponds with the standard data in file LOWI.txt.

The MAP arrow starts at level 3300 while the allowed level at ML26 is not higher nor lower than 4420 ft so a level of 3300 is not allowed at ML26.

Question:

7. Why does the MAP arrow not start at 4420?

 

Example 4:

Approach Procedure:    LOC 26-R

Key in LOWI.txt:             L26-R       //LOC

   Corresp. cat C data:   C;;A3700;5.0KM

Key in 0Default.txt:        L*         //LOC

   Corresp. cat C data:   C;;H250;800M

Data in item 6:               C  26  LOC  3700 / 5.0 km (in white: standard value)

Data in item 1:                MA26(MAP) D0.9 OEV       MAP arrow starts at 3700 (I presume)

The Navigraph approach chart for L26-R indicates a MDA of 2250 and RVR of 1600 for Cat C.

 

The L26-R data in LOWI.txt does not correspond with the Navigraph figures. (I know these 'minimums' data are obtained from the User Forum).

Question:

8. Why does the MAP arrow start at 3700 while it should start at the level indicated by the descent line in item 1 at D0.9 OEV (MA26), in fact at 2250 ft?

 

I hope you can shed some light on the inconsistencies I've encountered.

 

Regards,

 

Jaap

 

 

 

 

[lonewulf47]

Hi Jaap,

 

May I answer these questions in a rather short way as I'm the person who takes care of the minimum files.

 

All those minimum data are compiled to the best of my knowledge and possibilities and do in no way represent official values, although in some case they may be similar or even an exact match. This is also expressively mentioned in the disclaimer header of each individual minima file. It's just a collection of files to help finding a reasonable DH or DA for a certain approach, nothing more. The missed approach arrows are - also seen in this light - just a reminder for a missed approach. The altitudes are calculated from the approach angle for this specific approach and do not represent the actual DA. The reason for this is that the profile is depicted using ARINC data which do not include any minimum figures. The figures shown are just calculated values for the last fix of the (non-precision) final descent.

 

As for the data in the "0default.txt": You might have noticed that those are only give as "height", bearing in mind that height has to be added to the THR elevation depicted in the approach profile. Here again those are just standard values to give an idea of a DH or DA, but of course - as they are just standard values - they do not include any conditional increase of minimums due to obstacles, A/C performance etc.

 

In addition to this it is of utmost inportance for every user to know the he can adjust these values to his own liking at any time. Whenever a user deems it necessary to do corrections for a specific minimum file (*.inc od *.txt), he is free to post the corrected file in our forum, where they can be included in the collection and thus shared to all users.

[JaapV]

Hi Oskar,

 

Thanks for your comment.

Perhaps I was not clear enough in my previous post. This post is not about the correctness of the contents of the .txt files but about the inconsistency of the data in item 1 and item 6 of the Procedure Panel and the application of the available data in the *.txt and 0Default files.

 

I have investigated the approach of several airports and in all cases the DA/DH values in item 6 are equal to the corresponding values in the *.txt file. In addition, the values differ little from those of Navigraph. So no calculations are necessary at all to determine the DA/DH values for item 1. Only in cases where the default values should be used because no *.txt file has been compiled for it and where the default value would be illogical in specific situations, I can imagine that an additional calculation is necessary.

In my research, it was striking that only for all RNAV/RNP approaches, the present value from the *.txt file is not copied, but deviating values are shown in light yellow. However, these 'default' values do not correspond to the default value from the 0Default.txt file (plus the airport elevation if necessary). Moreover, the RVR is always 1.5 km while the corresponding value in the 0Default.txt files is 800M. See also the examples in my previous post. Do you have an explanation for this?

 

Since the values for DA/DH are available in item 6, the corresponding positions on the glide path in item 1 can be easily determined and indicated with an arrow. Multiple arrows can be placed for multiple DA/DH values. See also the Jeppesen charts showing the different DA/DH values with multiple arrows. These all start on the glide path at the location corresponding to the DA/DH.

Positioning the DA/DH arrows in the right place seems to me to be a good improvement compared to the current situation where the arrows are not always in logical places.

 

Maybe I'm wrong and everything is much more complex than I think. In that case, perhaps through some examples with underlying calculations this complexity can be demonstrated so that I can increase my knowledge, and that of other readers, on this point. Also answering each of the 8 questions from my previous post would help to clarify things.

 

Regards,

Jaap

 

 

[lonewulf47]

Have you updated the Minima Files to the last valid set: https://forum.aivlasoft.com/topic/3003-minima/ (delete ALL old files before unzipping the "EFB2_minima_complete.zip")?

 

[JaapV]

Yes I did. See my first post for the version of the used LOWI.txt file.

[lonewulf47]

I was asking this as e.g. I see different values than you show in Example 1. See below:

 

 

Your example reads: "Data in item 6:               C  08  RNAV/RNP  2410 / 1.5 km (in light yellow: ‘default’ value) ", but here I see exactly what you expected, without light yellow figures ?!?! So at least this one looks strange to me.

 

[JaapV]

My system shows:

 

 

Very strange. Is there a setting which could be the cause of this?

[lonewulf47]

Well, it seems that you are using a different database than me. Your approach identifier is "R08-Y", compared to "H08-Y" which wpould be correct for an RNAV/RNP approach. According to Austrian AIP this approach if of the RNP-type (Required Navigation Performance) and the procedure in question was  validated on NOV 7, 2019. The value shown with the amber background is the default value from "0default.txt", corrected for the THR elevation in LOWI:

 

[Approach]
Key=R*            //RNAV
A;;H500;1.5KM
B;;H500;1.5KM
C;;H500;1.5KM
D;;H500;1.5KM
E;;H500;1.5KM

 

You might want to check the database installed for EFB.

 

[JaapV]

Hi Oskar,

 

Re-generating the EFB database did not solve the problem. Uninstalling and reinstalling of both the server and the client, installing AIRAC 2105 using the Navigraph FMS Data Manager, re-installing the Minima data and renewing the Settings of the Client and the Server did not solve the problem either. The approach identifier for RNAV/RNP still remains R instead of H.

Below you will find some details about the installed database to compare with your database:

 

The cycle_info.text file of Navigraph Airac 2105 reads:

AIRAC cycle    : 2105
Version        : 1
Valid (from/to): 20/MAY/2021 - 17/JUN/2021

Forum          : http://forum.navigraph.com

Data provided by Navigraph - www.navigraph.com - Source data copyright (c) 2021 Jeppesen
This data may be used ..........

Parser-Version : DFD v1.0 21.0421 (c) Richard Stefan
Files parsed on: 12/05/2021

 

and the cycleInfo.txt file reads:

// AivlaSoft EFB - Procedures data - www.aivlasoft.com
// Copyright (c) 2021 Navigraph, Datasource Jeppesen
// Created by AivlaSoft.Efb.Arinc424Parser, Version = 2.1.70.957
// Files created at 2021-05-12 12:44
Cycle = 2105
Revision = 1

[Statistics]
No of airports total = 14662
No of airports without procedures = 7910
No of airports where at least one SID is available = 2669
No of airports where at least one STAR is available = 2053
No of airports where at least one approach procedure is available = 6640

 

Both item 6 in the procedure panel and the selectable procedure in the LOWI Arriva panel indicate RNAV/RNP (and not only RNAV).

 

Also the Jeppesen chart of Navigraph indicates 'RNP Apch' so it is definitely a RNAV/RNP approach.

 

Any ideas what to do next?

 

Jaap

 

 

 

 

 

 

[lonewulf47]

This problem is not to be solved at the present time. I use the LIDO/NavDataPro database for checking the available approaches, and obviously in a few rare cases Jeppesen and LIDO do not use the same coding priciples. IMHO coding this RNP approach as "R" type is not correct, as the designation RNP explicitly requires a check for the navigation performance for the time window of the approach +/- 10 min, while a RNAV approach does not.

The only possibility would be a complete set of minima files for both Jeppesen and LIDO. To be honest: as I do this checking fpr each new AIRAC cycle courtesy of the EFB users and free of charge, the additional workload to do this twice is out of question for me. Nevertheless if someone is willing to do this for the community I would heartily welcome him/her...😀

 

Alternatively you may also do changes within the LOWI.txt file.

Change "Key=H08-Y    //RNAV/RNP" to "Key=R08-Y    //RNAV/RNP" with the help of any normal text editor. if the "Key=H08-Z    //RNAV/RNP" is also affected, make the same changes there. Just make sure that you make a backup of this file inorder to eventually replace it when a new update is due.

 

[JaapV]

I've replaced Key=H with Key=R in all *.txt files, but I'm not sure if this is the right solution in all cases. So I ended up switching to the LIDO/NavDataPro database just to be safe. I have also taken out a subscription for 1 month to view the maps of Aerosoft. Unfortunately I have not yet been able to find a user manual of these navigation maps. Do you have a suggestion where to find it?

 

Jaap

[lonewulf47]

29 minutes ago, JaapV said:

I've replaced Key=H with Key=R in all *.txt files, but I'm not sure if this is the right solution in all cases. So I ended up switching to the LIDO/NavDataPro database just to be safe. I have also taken out a subscription for 1 month to view the maps of Aerosoft. Unfortunately I have not yet been able to find a user manual of these navigation maps. Do you have a suggestion where to find it?

 

Jaap

No, this is definitely NOT a good idea and not what I sugtgested. My suggestion was to replace it in the specific file where the inconsistency appeared, i.e. LOWI. To replace ALL H key with R keys is definitely wrong as the H key is correct for all RNP approaches. The only inconsistecy is that Jeppesen do in some rare cases still use the R key although the approach is defines as RNP. There is no solution for that. I'm afraid you have to live with that inconsistency. There is however no direct threat to anyone's life if a wrong key is used...

[JaapV]

Using EFB with the Navigraph database I have checked many randomly chosen RNAV/RNP approaches (with the H identifier).

It turns out that for ALL RNAV/RNP approaches the approach identifier R is used instead of H. Navigraph apparently always uses the R identifier for both RNAV/RNP and RNAV approaches (and not only in some rare cases).

Aivlasoft, as a company, is undoubtedly in possession of the Navigraph specifications and can therefore verify whether my assumption is correct.

 

So when using the Navigraph database and you don’t want to obtain the default minima instead of the real minima in case of any RNAV/RNP approach the only solution is to replace Key=H with Key=R in ALL minima *.txt files.

With the utility Notepad++ it is a piece of cake to realize this.

 

The only problem is that the contents of the files may have been updated or new files may have been added to the database when EFB is updated (I suppose the database will not be changed between EFB updates). To be sure,  you will have to do the replacement exercise again with each EFB update.

 

I don't see any real solution to prevent Navigraph users from having to change the minima files by themselves except when Aivlasoft makes a minor change to EFB.

 

The simple and effective solution could be to use only Key=R for both RNAV/RNP and RNAV approaches in the minima files for both Navigraph and NavDataPro; the key H should then be removed from the Client manual. On the approach panel of EFB both RNAV/RNP and RNAV approaches are all named RNAV/RNP so basically it doesn't make sense to use two different approach IDs just for the MDAs.

 

The minor change in the coding of EFB is that in case it has to retrieve an MDA with Key=H, it should search for R instead of H.

 

Jaap

[lonewulf47]

Hi Jaap,

It is not a question of Navigraph or not, it is a question of ARINC Specifications that have changed recently.

We use the new specifications as per the following table and description, which allows a clear distinction between RNAV only and RNP.

 

 

Nevertheless I would like to point out that of course you are free the manipulate your minima files to your liking. This said we will of course continue with the official ARINC recommendations for our own publications.

[aivlasoft]

Additionally to what Oskar already mentioned, I would like to emphasize that providing and maintaining all these minima files is a FREE service from AivlaSoft.

[JaapV]

Hi Oskar, Urs,

 

I know the minima data has been provided by volunteers and are maintained by volunteer Oskar, for which I am very grateful.

 

Thanks for the information, but this raises 2 questions for me:

 

1. Can you tell me since when the changed Arinc specifications are in effect?

2. Do you have information from Navigraph that they will implement the changed specifications (to use H instead of R for RNP approaches) and if so when will this implementation take effect?

 

For now, I'm using the NavDataPro database, so there's no need for me to modify the minimal files but as long as Navigraph uses the R instead of the H, (other) Navigraph users may use my suggestion to modify the minima files.

 

Regards,

Jaap

[aivlasoft]

1 hour ago, JaapV said:

Can you tell me since when the changed Arinc specifications are in effect?

This is unknown to me, I can only tell you that the specification ARINC 424-21 (from which the above screenshot has been taken) was published in July 2016.

 

1 hour ago, JaapV said:

Do you have information from Navigraph that they will implement the changed specifications

This would have to be done by Jeppesen but we do not have any information about this.