lonewulf47

Here you go. Those are the entries for KORD in my runways.txt (7 actively useable RWYs in FSDT KORD): KORD 10 10L KORD 28 28R KORD 09L 09L KORD 27R 27R KORD 09R 09R KORD 27L 27L KORD 14L 14L KORD 32R 32R KORD 14R 14R KORD 32L 32L KORD 22R 22R KORD 04L 04L KORD 22L 22L KORD 04R 04R Regards Oskar

Welcome ! As a former member of LIDO (Lufthansa Systems) I was involved in this kind of charting issues and fortunately I still have access to most of the sources..

Well Michel, The RWYs at MGGT ARE indeed 02/20. Not sure when it has changed, but it looks as this has happened by the end of 2013. IMHO the change message in the runway.txt file should be the other way round: MGGT 01 02 and MGGT 19 20.

Sounds great !

Thank you Patrick! Indeed there are numerous different export formats that can be used. Of course you will need to check the respective boxes and also insert the export path that points to the flightpln folder of the selected model(s).

Well, I wouldn't call this an issue, it's just a normal flight planning with EFB and saving the Flight Plan into the Airbus' flightplan path. Actually all is precisely described in the respective manuals of Airbus Extended X and EFB. To make it a bit simpler: 1) Create a flightplan in EFB 2) Save it. When saving make sure you have selected the proper export path for the Airbus Extended 3) In the Airbus' MCDU insert the aiport pair for the planned flight, e.g. EBBR/EGLL if you have planned a flight from Brussels to London Heathrow 4) The MCDU will show you whether it has a stored flightplan for that route (it will of course, if you have followed all steps properly) This is the way it works and it indeed does work flawlessly

Gentlemen, there seems to be quite a mix-up about what is "correct" and what isn't See the excerpt from the LO-AIP: The actual (correct) RWY designators are: RWY 15 and RWY 33 ! It is always a good idea to verify such data with the respective AIP. However also if a current dataset is available, this serves (of course) also as a reliable source! So, yes, you will need the entries: LOWS 16 15 LOWS 34 33 in your runway.txt file. You will see the RWY numbers 16/34 in the simulator, but EFB will (correctly) give you indications for RWY 15/33. That's one of the shortcomings of simulations vs. real life

I have exactly the same setup for KORD with FSDT V2 and the actual datase from NavDataPro. I don't see any problems in getting SIDs out of all RWYs (ORD8 is available for all RWYs), however there are NO transitions, as quite common in the US. If you look at RW charts for SID it would even not be necessary to publish ANY SID as for each RWY there is just a RWY HDG to maintain plus a few altitude restrictions. That's all! The rest is - also as usual in the US - radar vectors to the first enroute waypoint. Now a few comments to the airport: FSDT is still one RWY "behind" the actual state. RWY 10/28 has become 10L/28R and a few hundred yards south there is now RWY 10C/28C, and again a few hundred yards youth there is a third parallel RWY under construction, which eventually will become RWY 10R/28L. The only necessary change in the "runway.txt" file is the change for 10/28 into 10L/28R. All the rest is not influencing EFB. IMHO if an airport is not showing ANY procedures at all it might be necessary to run the "Scenery Data Update" on the Data Provider Module to make sure EFB has the latest airport data from all installed airports. Oskar

While being in the process of setting up my new machine I have also deleted ASE and switched to FSGRW to operate networked on a separate computer along with EFB. However I do not see any transfer/exchange files from FSGRW. The one mentioned in the forum named "current_weather.txt" obviously does not exist (anymore?). I searched all possible drives and directories (even during realtime running FSX, EFB and FSGRW) but found no trace at all. Is there any hidden secret that might need to be unveiled... ? Could it be that when now using the new network-bridge this file is no longer generated? Not that it matters too much, as picking up FSX weather is of course identical to the injected FSGRW-weather. Just for my knowledge...

Well, to make it clear: ENE.PARCH1 is the Arrival Transition that leads from ENE Kennebunk via PVD Providence to PARCH. From there a PARCH1 RNAV Approach would further be available (PARCH-CCC-ROBER-CRAIL-CAPIT). This said it becomes obvious that ENE.PARCH1 is not a waypoint name but a STAR/Transition name which starts at ENE. Any route generators that use ENE.PARCH1 as waypoint are doing wrong. Only ENE must be in the routing. An example of your routing generated today using NAT B: CPT4K CPT UL9 KENET UN14 PEMOB UN24 SLANY DCT GISTI DCT MALOT NATB DOTTY N109B EBONY J573 ENE PARCH1. I must admit however that I haven't tried but I'm sure that this string would work in EFB.

Just a shot in the dark: did you have the Oceania Scenery activated? If not EFB will not find the airport as the entries are removed from scenery.cfg if the scenery is set to default FSX. That's the ORBX way Oskar

With all respect Guillaume, I HAVE seen real EFB's. Whereas the screen size is less important in that respect the RESOLUTION is something completely different. No today's commercially certified EFB's are working with such a low resolution. You might have read about iPAD APPS having been certified commercially. Now that's what we are talking about.... Oskar

Yes, RWY 08/26 at LLBG is under reconstruction. That's the crucial things with those real- time NAV databases: they are soo accurate Nevertheless I wonder why these approaches have been deleted from the database. Usually a database provider does not cancel approaches when they are temporarily unavailable. Even when you look at the most recent NAVIGRPAH charts (which should represent the same data as for the ARINC 424 AIRAC file) e.g. the ILS 26 chart is still provided. So in my eyes this seems to be a conversion error by NAVIGRAPH. About the issue of the recosntruction work you can retrieve information in the NAVIGRAPH LLBG GENERAL TEMPO publication. It will remain closed till Sept. 1st, 2011. Oskar

I had a similar problem on my installation. To be honest - I didn't read all the Handbooks and readme files but analyzed the installation. I found that - for any unknown reason - the installation was not complying to the FS rules - nevertheless EFB found it - but not FSX If you look at the installation (maybe depending on the installer) you will see the following: Installation path ->FSX root\Simmarket\VTBS-FSX and within that two more folder "VTBX higher priority" and "VTBY lower priority" Those are the paths which are also set in your scenery.cfg. As per FSX norm within this registered path there must be at least a Scenery folder and - only if necessary - also a Texture folder. If you look not at the "VTBY Higher Priority" folder you will find these two folders Scener and Texture however: - the Texture folder is empty - within the Scenery folder you find another setup of a Scenery and Texture folder !! I simply copied the contents of these two folders "one step back" into the Scenery and Texture folders in the "VTBS higher Priority" folder and now it works. The other folder "VTBS lower priority" is ok as it only contains a Scenery subfolder and within that one simple *.bgl. Maybe I missed something within the installation that would have prevented this ugly setup but I see also in other forums that we're not alone HTH!

Well, I don't think that a fixed gate as part of a flight plan adds realism. Actually it's exactly the other way round. First of all the gate is NEVER part of a flightplan and secondly in reality your A/C is not alwas at the same gate. Choosing a gate by random - that's realism

Hmm, sounds strange. I work with a touchscreen for quite some time without any problems. Just a few questions: What operating system are you using? Did you connect the touchscreen with the additional USB cable to the computer? Can you do any inputs on your standard operating system? does the touchscreen keybord work normally?

Well, I'm not sure about the CIVA INS - btw one of the best freeware designs I have ever come across! I haven't been digging too deep into that system. My guess is however that for simplicity reasons it uses the native FSX variation - but as I said -only a guess. As for the navigation beyond those limits - not too sure about the correct figures anymore - might also be 68N - in the A330 (as this one was certified for polar navigation) the whole system simply reverted to TRUE NORTH navigation, of course accompanied with the relevant warning. You would also be able to use TRUE NORTH all the time. There's a simple pusbutton on the panel, however it's not SOP in any airline - yet In a non-polar certified A/C you would of course lose all heading information - not a pleasant outlook... however on the IRS Control Panel you will have a True track output in plain numbers all the time. Edit: I rechecked on the Airbus' 320 FCOM. The limit is 73°N (on a certain latitude sector even 82°). So it confirms that my brain is not 100% reliable anymore

Jean -Louis, Sorry for the late answer. I was quite busy outside Flight Simulation You are right with your remark that INS is working with true bearings only. Every modern Aera Nav System does so - even GPS. but after all our Aviation Navigation is still based on Magnetic North (except beyond 70N/65S or so). That's why the Heading Output of such sytems needs to be shown based on Magnetic North. This is done unsing an internal table within the Naviagtion System itself - be it INS/IRS/AHRS or GPS. So there is another source of discrepancies. We have found - don't tell it anybody - and A/C within a B737 fleet with an old table (they usually are updated through Service Bulletins of the respective Manufacturer) which led to complaints of the Crew that on a certain RWY the A/C HDG was misaligned by 3° ...

Hi all, the official values - derived from the actual worldwide Lido FMS database - are: VOR DME one RWY 11 -> 102° VOR DME one RWY 29 -> 305° There are two things to observe: 1) Mexico is among the worst (sad to say...) countries when it comes to official sources. Believe me, I know exactly what I'm talking about Database work is my daily business. 2) Variation (declination) is a subject that has two key features in navigation: first the actual variation which influences any earth magnetic derived compass system (icluding all GPS/INS based systems who use a tabulated variation value) Second - and especially important for VOR approaches - is the STATION DECLINATION of the VOR station. Even if the local variation has - say a value of 2°E - it does not necessarily mean that the VOR is aligned to the same variation. Adjusting the VOR's declination to the actual value is a time consuming and therefore costly process. This means that - even if a track can be accurately calculated to have 100° M it might be on a different radial e.g. 102° from the VOR if the station declination is not properly adjusted. And don't think that only "third world" coutries have a somewhat sloppy way of coping with Station Declination: in the US there are many MAJOR airport VORs with a Station Declination Error as big as 4-5°!! (ORD, JFK etc.) p.s. Don't worry about the two namings: variation and declination are the same. In aviation we use "variation" when it comes to on-board navigation however when speaking about fix-based systems we stick to the old nautical and terrestrial term "declination". Don't blame me for that

I see. Thank you Urs, for the information. I was afraid of that. It's a pity that not the complete content of the ARINC 424 dataset can be used. It would make many things more flexible (and of course more complicated for the programmer... ) I still dream of a simulator using ONE complete dataset for every navigation application - and not dozens of subsets with individual limitations for each add-on. We are still allowed to dream, aren't we?

Transition levels and altitudes are part of the airport record in the ARINC 424 file. So - it's only the question whether Navigraph includes such data in it's databases. I'm sure they have it as my guess is that they work with a complete ARINC 424 data set and they should be able to supply all data included there.

I see a certain potential for further problems in the mentioned interpretation of wayoints/navaids as a function of their namelength. Many european VOR's - not to say most - have their equivalent waypoint with exactly the same coordinates and designator inorder to replace the VOR in case of a short or longterm malfunction or outage. If e.g. a VOR is being reconstructed over a period or more than one AIRAC cycle without being substitued by a TEMPO VOR it may well happen that there is only that replacement waypoint. As this is common throughout the current professional FMS databases it is reflected in NAVIGRAPHs data - being derived from EAG - as well. So as a conclusion I would suggest to step away from the term "3-letter names depict by definition a VOR" which is simply not true. My guess ist that this did not have any consequences until now as there were obviously no problems with other VORs that have their 3-letter waypoint equivalent till now - but it might happen soon again

Uhmm, never been a boyscout, huh? Looks almost perfect to me. Personally I wouldn't underline the FAF. Just print the text "FAF" in an prominent way -> either BOLD or BOLD INVERTED. Underlining should serve the only purpose of defining an altitude restriction. Just my five cents though .. Oskar

Hi Urs, Yup, exactly ! Right on the spot Oskar

Well, as you see there is not really a STANDARD in those notifications. Besides Jeppesen there are two more main competitors on the Route Manual (and thus charting) market - not talking about FMS databases where about a dozen main competitors share the market - which are Lufthansa FlightNav (known as LIDO) and EAG - the latter being used by Navigraph. My only concern in this topic was not to mix up two notation systems but to stick to ONE. I understand that underlining the altitude figures in EFB is meant to emphasize it's importance and improve visibility. As I said on my previous post: not really a big issue - just a personal concern and remark Oskar