Jump to content

JaapV

Members
  • Posts

    15
  • Joined

  • Last visited

Recent Profile Visitors

312 profile views

JaapV's Achievements

  1. 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
  2. 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
  3. 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
  4. 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
  5. My system shows: Very strange. Is there a setting which could be the cause of this?
  6. Yes I did. See my first post for the version of the used LOWI.txt file.
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Hello everyone, After downloading and installing EFB v1.6.15 on a new motherboard with Windows 10, the fixes are no longer displayed on the chart as they used to do with Windows 7. I have tried all zoom settings and also disabled the virus scanner, but no fixes show up. The other chart objects show up as expected. EFB is using the Navigraph AIRAC cycle 1108 as delivered with the PMDG 737ngx package. I reinstalled EFB (you never know) but no fixes. When I open the Modify page (Enroute tab) and select a waypoint in the lower pane, the fixes appear in the upper pane after clicking the option Fixes. Any ideas? Regards, JaapV
  14. Hi community, Problem solved! In trying to solve this problem, Aivlasoft provided me with a company route file created by PFPX. Using this file no problems occured. After comparison the content appeared to be equal to the file created by the EFB, so the cause of the problem should lie elsewhere. After some testing I finally found out that company route filenames containing spaces are not handled correctly by the 737ngx software of PMDG. In first instance everything seems to be OK but after reloading and executing a previously saved flight, problems arise. Best regards, Jaap
  15. I created a flight with the EFB, loaded it in the PMDG 738ngx as a company route, completed the FMC with the required data and started to fly the plane. Having reached TOC I saved the flight in FSX. After reloading this flight, the route appeared to be not active anymore, the Flight Level had to be filled in again and the flight number was replaced by the ICAO code of the destination airport. After entering the FL and activating and executing the route, FSX was frozen. I contacted PMDG and they suspected the company route file to be corrupted. So did some tests: To exclude the influence of any addon, I reinstalled only FSX (SP2), PMDG 737-800 NGX (1d) and updated EFB to the most recent version (Dataprovider 1.6.8.33244, Diplayunit 1.6.8.33245 and AivlaSoft.FlightPlanHandlers.PmdgRte.dll 1.6.0.0). In Aivlasoft EFB I created a simple flight, EDDL NOR EDFH, and saved the route as 'EDDL EDFH EFB.rte'. I started FSX free flight with the 738ngx on EDDL, active runway, executed POS INIT and loaded the 'EDDL EDFH EFB.rte' in the FMC as a company route. I didn't enter any other data in the FMC and activated and executed the route. The route was saved as 'EDDL EDFH A.rte'. I restarted FSX in the same way as before but now I entered the waypoints manually and saved the route as 'EDDL EDFH MAN.rte'. After having restarted FSX and ngx and loaded 'EDDL EDFH A.rte' as co-route, the FMC showed the same errors as I mentioned before. I did the same thing with the manually created route 'EDDL EDFH MAN.rte' and there were no problems at all. I attached the three mentioned .rte files for information. Jaap RTE files.zip
×
×
  • Create New...