NAVData

Hi gentlemen, please be so kind and open a topic in the Navigraph forum, whenever you mean, that there is an issue with our database. We can´t have our eyes everywhere - in such cases, it makes more sense to go directly to the developer: directly means to Carenado (via ticket) and/or to us (via a posting in our forum). Thank you very much, Richard

Hi guys, Sarun pointed me to this topic in our forum. I have tried to figure out what the issue is, but I´m not sure, if the solution from you Dave is really a solution. The reason is, that in nearly all transitions are "between" altitude restriction - crazy, unlogic, silly, ... whatever you want but there are these restrictions. I have looked on to the current charts too and again, you see these restrictions. The "solution" is now: to supress all "between" restrictions, which means in all procedures but that can´t really be the solution because sometimes it makes sense, sometimes possible not. Further when you look onto the charts, you see, that there is a Military flying area around Don Mueang, possible that this is the reason for this special restrictions ... So, the question is: Should we really remove the "between" constraints ... ??? By the way, in the PMDG 777, there is no "constraint issue" with exactly the same syntax ... the PMDG 777 uses exactly the same procedure-file as the 737NGX - Here are the current chart of VTBD SID Rwy 21L/R Frank2

But honestly, the developer tries to make the a/c so realistic as possible - power-settings, aerodynamic, systems, ... but you can´t rely on that the a/c flies the path correctly which is shown on the ND? We know (an Jan-Paul had explain it excellent - thank you), that this is a "design-issue" in the procedure files and/or a "design-issue" in the navigation part of the PMDG addons - as an example: Aivlasoft use the same file format as PMDG, but the procedures there shown correctly (left turn and without any additional circles): RJOO - 32L / ASUKA4 Cheers, Richard

Hi Dan, first of all - yes, we are a kind of "mammoths" here in the community ... aren´t we? B) I have optimized the coding now on my side, and the golden key is really the direction directive - but it´s partly very tricky because you can´t "translate" the ARINC424 source 1:1 into the PMDG syntax ... anyway, I will do some more testings the next days before I release a second revision of this cycle. Thanks again for your time Dan and take care Cheers, Richard

Hi guys, first of all thanks for some hints here, regarding the wrong turns or the missing turn information. But I have still open question, which is completely unclear for me and I guess, for your customer too: Before I start with my testings - following startup parameter: RJOO on RW32L, in every test scenario the FMC was fully configured and ready for take-off Mystery #1: This line (without the turn directive), produce two different result in the 737NGX and the T7: RNW 32L TRK 322 UNTIL 500 HDG 071 INTERCEPT RADIAL 101 TO FIX ASUKA FIX ASUKA AT OR ABOVE 5000 Result on the 737NGX ND - flight path is correct, a/c flies the turn (left) correct and follow the path Result on the 777 ND - flight path is incorrect, a/c flies the turn incorrect (right) too Question: How knows the 737NGX that the a/c should turn left? There is no reference ... ?? Mystery #2: Now the same conditions but with the turn directive, as suggested RNW 32L TRK 322 UNTIL 500 HDG 071 INTERCEPT RADIAL 101 TO FIX ASUKA TURN LEFT FIX ASUKA AT OR ABOVE 5000 Result on the 737NGX ND - flight path looks incorrect, but the a/c flies the turn (left) and follow the path correctly Result on the 777 ND - flight path is correct, a/c flies the turn correct (left) now too Both a/c´s fly the procedure correctly, but the flight paths on the ND are different Question: Why? How can this happened? And more: how can this be fixed? My conclusion is now, that there must be an incompatibility existing between the 737 and the T7. Both addons use the same information, fly the same path but looks different on the ND. I guess that was what Kuzao and some PMDG customer here mean. It´s difficult to say, what happend with the a/c when you see two rings on the ND (in this case, we know what happened - nothing, but that can´t be a general rule). It´s difficult for the data provider too, because we can´t test all such procedures from month to month - and last: I hope you see, that this is NOT a data issue (this issue exists in the default database which is included in the 737NGX/T777 too) Thanks for your time, Richard

Thank you Philipp, I'm sure Aerosoft will fix this issue in his database latest for the final version because I'm sure that the information is in the Lido database too! Thanks for fixing and thanks to Ryan and Scott for the explanation in this case! Had learned a lot again in this posting! Cheers Richard

Hi Ralf, thanks for clarfication - I'm a X-Plane newbie, sorry! May I ask a question? Can you manual enter the flightplan? Does this work? Cheers Richard

Anyway - this discussion doesn't help Ryan and the other guys here! Fact is, that this IAF waypoints (defined or not) are not in the list and when I had understand the result correctly - this is a bug (or missing link) in the GPS and not a data issue! I guess thats the conclusion now ... Cheers Richard

Sorry Philipp, but I see ONLY ONE correct way because this is a part of the official technical documentation which I had received - and we (Navigraph) had implemented it in the correct way - Aerosoft not. It´s simple ... sorry! I don´t see any fun here ... Cheers, Richard

Ok, thanks for the clarification guys - I´m not a pilot or similar else, this was my personal adoption - but I guess, this is a limitation of the new GPS. Here the important part - you see the structure acording the technical documentation of the new GPS. The red-bold numbers define "special waypoints" 1 = IAF 2 = FAF 3 = MAP 0 = normal Waypoint So, the waypoints are marked as IAF (IFAFY isn´t a IAF, thats wrong), but you can´t select it in the GPS. What I want to say is, that you see the IAFs in the data but it looks like, that the GPS doesn´t handle it ... It could be possible, that Philipp had forgotten this ... Sorry, but I don´t see any chance to fix it ...by the way, this isn´t a Navigraph issue - because the result is in the default Aerosoft database the same - but the Aerosoft data hasn´t the information about the special-waypoints in it as we have. APPTR,R02,02,SANTY IF,SANTY,36.979239,-122.073075, ,0.0,0.0,0,0,0,0,0,0,0,0 TF,LEPWU,36.807600,-122.056878,0, ,0.0,0.0,0.0,0.0,2,4000,0,1,210,0,1,0 TF,IFAFY,36.747581,-121.938372,0, ,0.0,0.0,0.0,0.0,2,3000,0,1,180,0,1,0 APPTR,R02,02,SNS IF,SNS,36.663836,-121.603186, ,0.0,0.0,0,0,0,0,0,0,0,0 TF,RISPE,36.687245,-121.820056,0, ,0.0,0.0,0.0,0.0,2,4000,0,1,210,0,1,0 TF,IFAFY,36.747581,-121.938372,0, ,0.0,0.0,0.0,0.0,2,3000,0,1,180,0,1,0 Cheers, Richard

Hi Ryan, ok, now I have checked what you mean ... Sorry, I need a little bit more time - I guess, it´s my age :huh: LEPWU and RISPE are only IAFs which can be ONLY reached via a SANTY or SNS. There is no airway connection to LEPWI or RISPE and therefore you have no possibility to select it in an FMC nor in the GPS here. IFAFY is the IF and also not connected directly via an airway. A transition is defined as a connection between an airway to the IAF (or IF). In this case, you have two approach transitions - one from SANTY and one from the SNS VOR. The procedure is correct, the data are correct an the GNS works as it should. Sorry, but I can´t see any issue here ... Cheers, Richard

Hi Ralf, sorry to ask, but what has this done with the navdata update? From what default FMC do you speak? And when you wrote, that not all waypoints weren't imported, than this isn't an navdata issue ... Or do I missinderstand here something? What navdata issue do you exactly have? Cheers Richard

Sorry Ryan, possible a stupid newbie question, but what do you mean with "select one of the ..."? Do you mean during a flight as a "direct to" or what do you mean with this ... because after selecting the GPS approach with a transition, I get the complete list of waypoitns ... so i can´t see any problems with the data because they are there. Cheers, Richard

Hi Ryan, can´t reproduce it ... I have seleted the RNAV02 with SNS transition as example - the result, is correct so far ... Cheers, Richard

Hi, the main different between Aerosoft and Navigraph is the different sources. Aerosoft uses a tailored database which comes from Lido, we (Navigraph) use the standard database from Jeppesen (standard means really worldwide, not airlines specific like a tailored database). The difference in the coverage between both source providers is minimal. Some addon developer takes the Aerosoft database with the default setup, other our (the Navigraph) database. This depends on personal contacts and/or business contacts (ie. Aerosoft is publisher for XPlane in Europe). In other words (as a general answer), the difference between Navigraph and Aerosoft data in the new gps is none existing - it´s by your own choice, which company/which data provider (Lido or Jeppesen) you prefer. The XPlane developer had tested the Navigraph database too, but the XPlane management has decided to use the Aerosoft data in the default setup. As you know, Navigraph offers now an update for the XPlane default database too, which will be used for example the UFMC/XFMC and some other addons too. XPlane itself doesn´t support SIDs/STARs (only via addon products), so the default XPlane database doesn´t include terminal procedures. All other addons like UFMC/XFMC, X-FMC, Ramzess B777, VASFMC, ... use own database which we offer too. So, you have one consistent database from the basis XPlane sim to any XPlane addons - you can plan a flight with XPlane and can use exactly the same route in your addons (because the airways are equal, you have all waypoints, and so on). Or you use addons like PFPX, Flightsim-Commander, EFASS, ... create/plan a route and you will use it in an XPlane addon - fully compatible between all addons over flightsim borders! As Mike wrote: All in one ... that´s exactly the benefit ... Hope it´s clearer now - when not, please ask ^_^ Cheers, Richard