JaapV

Hi Urs, You say you have no idea, but the suggestion you make turns out to be the right one. I had not disabled this option. After unchecking the box, I ran a few tests and no more problems occurred. I also hadn't thought about EFB as a possible cause of the crashes at all, so I kept looking for other possible causes. I'm very happy that the problem has finally been resolved. Many thanks. Regards, JaapV

Hi, I am looking for a solution to the following problem: I usually fly PMDG's 737-800 for MSFS2020. I also use EFB V2. All programs and add-ons that I use are of the latest version. I often save a situation to continue the flight at another time or to redo a certain part of the flight. Unfortunately, reloading the saved situation usually leads to a CTD from MSFS (FlightSimulator.exe). After selecting the desired situation and clicking Open, nothing appears to happen for 7 seconds until the CTD occurs. The Exception code is then always 0xc0000005 and the Fault offset, with the current version of MSFS (1.36.2.0), is also always the same (0x0000000001b878da). To try to find the cause, I restored MSFS to the so-called vanilla state removing all add-ons, except of course PMDG 737-800 and Navigraph for the necessary Airac data. The problem then does not occur. Also after re-installing FSUIPC7, I can save situations, load them again and continue the flight without any problem. However, if I also use EFB and save various situations during a flight while EFB is loaded, this usually (but not always) results in a CTD of MSFS when loading these situations, even if EFB is not loaded at that time. For example: loading situations A, C, D and F always lead to a CTD, while situations B and E can be loaded and executed without any problem. Whether the plane is in the air or not appears to make no difference when saving. As far as I have tested, the problem only occurs when using the PMDG 737-800 and not when using MSFS aircraft. Regards, JaapV

Hello, For some reason, EFB V2 refuses to update the flight plan with a certain approach procedure. The route is VNKT KIMTI B345 TUMLI G348 SUBSU VQPR (Kathmandu to Paro). I want to land on RWY 15 using the RNAV/RNP 15-Z approach procedure via PR888 with STAR SUBS1A. After selecting this arrival procedure in the VQPR-Arrival window, the corresponding route is displayed on the MAP including all waypoints of the approach procedure (PR744, PR842, …. PR810, PR808). So far it's going well, but when I click 'Set FPL', the flight plan doesn't update. The same goes for RNAV/RNP 33-Z. After choosing procedures RNAV/RNP 15/33-X and RNAV/RNP 15/33-Y, the flight plan is updated as expected. Kind regards, 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

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

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

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

My system shows: Very strange. Is there a setting which could be the cause of this?

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

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

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

Hi Urs, Yesterday, after having updated to the latest version of EFB V2, I encountered an error when executing Performance Calculation. I am using Topcat version 2.74. This error arises with as well as without FSX loaded. See the attached file for more information. Best regards, Jaap Error message during Performance Calculation EFB-V2.docx

Hello Urs, Apparently, I was not clear enough. I did not copy the former FSX installation, but I downloaded and installed both FSX and the add-ons. Only the EFB turned out to be a different version. Because of your comment that the data formats are slightly different, I compared the content of the NavData files that I obtained with the new installation of the PMDG software, with the NavData files of PMDG that I still own from the previous installation. I expected them to be the same, but for some unknown reason one of the new files appeared to be damaged???? I replaced the damaged file and now everything is OK again. Both EFB and PMDG use the same NavData files from PMDG without problems and the Fixes are shown in the chart. Problem solved! Thank you Urs for your cooperation. Regards, Jaap

Hi Urs, Thank you for your reply. First let me tell you that it is absolutely not my intention to expect you to support other formats of Navigraph navdata files. When I installed EFB for the first time: - I had no technical knowledge of Navigraph Navdata files. - It was obvious to me the EFB and PMDG software should use the same navdata. - I knew the location of the navdata directories and files used by PMDG can not be changed. - In the Navigation data settings of the data provider the explanatory text is: Always select the folder which is 'hierarchically above' the two folders 'Navdata' and 'SIDSTARS', independent of whatever it is named. - The manual did not indicate that EFB Aivlasoft can only use navigation information from Navigraph. Based on the above it was obvious to me to let EFB make use of the Navigraph data of PMDG. So I changed the directory setting in the DataProvider and I was not surprised that everything worked as expected. Lateron I tried to let PMDG make use of the Aivlasoft navdata by copying the data files to the PMDG directories but for some reason PMDG did not work so I continued to use the 1108 Airac cycle of PMDG. After reinstalling FSX and the addons due to the transition to another mobo with Windows 10, the only difference with the previous installation was a different version of the EFB software. So you should agree with me it was clear that the DataProvider would be suspicious while reading exactly the same navdata as in the previous installation. Now that you know the history I hope you realize that I do not mix things up at all. Unfortunately, the red dot and the beep from the DataProvider did not give me any information about the error, but you undoubtedly have the means to determine the cause. Maybe it's just a small problem I hope you will find. If the problem proves to be too complicated, I can always buy another set of Navigraph navigation files, but I am just curious why suddenly things went wrong. Best regards, JaapV

Hi Urs, PMDG appears to accept only this 1108 AIRAC cycle. Once I replaced the 1108 data with the EFB cycle data but the PMDG program did not accept this. I suppose Navigraph has a deal with PMDG that only other AIRAC cycles are accepted if they are bought and properly installed with the special PMDG installer from Navigraph (probably a hidden hash check on the cycle data which is stored anywhere in the PMDG data). Apart from this in my previous installation with Windows 7 I did not have this Fixes problem using the 1108 AIRAC cycle. Triggered by your question I did some tests: I reinstalled EFB with the delivered Navdata (cycle 1310) and created a flight. The fixes show up! Then I copied these Navdata and SIDSTARS directories into the PMDG directory. When I started a free flight with the PMDG 737ngx a warning message appeared: "Navdata hash init: invalid latitude". After clicking OK the same warning popped up again and again (the hash check I presume). Then I reinstalled PMDG 737ngx to be certain to use the correct Navdata (cycle 1108). When I changed the Navigation data setting in the EFB Data Provider to the Navdata in the PMDG directory, the Data Provider restarted to handle this new setting. Before it was finished I heard a bleep and a red spot appeared in the window (see the picture below). After starting the Display Unit it did not show the Fixes. The problem therefore seems to be caused by the content of the Navdata. I have enclosed a link to the Navdata and SIDSTARS files so you can try to figure out what could go wrong (https://1drv.ms/f/s!AhfYrSQf3v9UjDYeQB7A6b9IOl41). As I said before this problem did not occur with my previous installation using Windows 7. Perhaps the latest version of EFB that I have installed for the first time, contains a minor flaw. Regards, JaapV