Deputy Sheriffs mopperle 4162 Posted August 8, 2013 Deputy Sheriffs Share Posted August 8, 2013 Leider konnte ich keinen Testflug machen, da ich mit dem aktuellen Build zwecks anderer Test keine aktuellen Navdaten verwenden kann. Aber noch eine generelle Anmerkung und um Ideen vorzubeugen, Aerosoft hätte da was spezielles eingebaut um andere schlecht dastehen zu lassen: Die für den AXE verwendeten Navdaten sind nicht speziell für den AXE "gemacht", sondern sehr generisch und werden gleichzeitig auch von Addons wie z.B. Flight 1 Mustang, Super 80 Professional, C182T, DA Piper Cheyenne und anderen genutzt. Link to comment Share on other sites More sharing options...
NAVData 8 Posted August 10, 2013 Share Posted August 10, 2013 Ich muss da Max Reverse ein wenig recht geben. Navigraph liefert die Daten FÜR den AXE, also muss auch der Publisher dafür Sorge tragen, das diese korrekt von dem Aircraft gelesen werden können und nicht andersherum. Das wäre auch absolut nicht machbar. Somit ist Navigraph angehalten seine Datensätze nachzubessern, was auch häufig passiert - wenn man sich die updates der einzelnen AIRACS beim AXE anschaut die andauernd von Navigraph veröffentlicht werden. Lustiger Aussage ... soviel zum Thema "Standardisierung". Also Freunde, Navigraph hat eine techn. Dokumentation bekommen, an die wir uns halten. Unterschiedliche Source-Provider liefern unterschiedliche Daten, sprich das Coding (und vieles mehr) der einzelnen Legs ist unterschiedlich. Letztendlich, sollte das Ergebnis aber immer das Selbe sein, da es sich ja um einen standardisierten Datenstand handelt (ich spreche jetzt einmal NUR! von den Rohdaten). Ich hoffe, hier sind wir uns alle einig. So, wie Hans-Werner jetzt festgestellt hat, gibt es unterschiedliche Codings in diesem Segment und man kann nicht sagen, dass eine Korrekter wäre als die Andere (bzw. eben schlechter). Ich möchte das auch noch anhand der Charts wiedergeben, denn gerade an dem Beispiel fällt es auf. Wenn man sich die Karte von Hans-Werner ansieht, so sieht man eine D5.8 BAM. Sieht man sich exakt die selbe Karte von Jeppesen an, so sieht man hier ein D6.1 BAM. Ist das jetzt nun falsch? Nein, es wird von unterschiedlichen Providern nur anders dargestellt bzw. gecoded. Aber zurück zum Thema: @Hans-Werner: Gute Analyse & danke dafür. Ich muss gestehen, dass auch ich jetzt doch ein wenig gebraucht habe, das Problem einzugrenzen. Ich werde das auch im Navigraph Forum beantworten. Der Punkt REGNO ist im Final mit mit folgender Höhenangabe gecoded: Altitude Description = "J" Alt1 = "3000", Alt2 = "3000" Altitude Description J bedeutet: GlideSlope Intercept Altitude specified in second "Altitude" field and "at or above" altitude specified in first "Altitude" field So, wenn man sich jetzt die navigraphsche Umsetzung dieser Codings ansieht, habe ich folgendes daraus geschlossen: IF,REGNO,51.386011,6.964225,IDNW,51.8,10.4,2,3000,3000,0,0,0,0,0 2 = above altitude1 3000 = Alt1 3000 = Alt2 Ich nehme jetzt einmal stark an, dass genau da das Problem liegt. Denn der AXE kennt "J" ja nicht, sondern nur 5 Zustände (no restriction, at alt1, above alt1, below alt1, between alt1 and alt2). Diese (meine Interpretation) ist somit falsch und ich werde in so einem Fall ein "AT ALT1" setzen. Genau das sind sogenannte "Justierungen", die in keiner techn. Doku stehen und die die Addon Hersteller selber wissen, nicht aber Fremdanbieter. Ich werde nach einem Test, ob es wirklich das Problem ist, eine neue Revision machen. Richtig wäre also: IF,REGNO,51.386011,6.964225,IDNW,51.8,10.4,1,3000,3000,0,0,0,0,0 @Hans-Werner: wenn du es vorher testen möchtest, bitte eine PM im Navigraph-Forum mit deiner Mailadresse ;-) Dankeschön & schönes Wochenende Richard Link to comment Share on other sites More sharing options...
Patrick1246 353 Posted August 10, 2013 Share Posted August 10, 2013 Richard, nach Diskussionen mit Joshua Che. There are two issues brought forward to me: 1. VNAV Path too high at METMA 2. After METMA, at OM23L. VNAV Path is still too high. 1. Is due to METMA being ABOVE or AT, not AT, so VNAV Choose more optimum path. So Richards Solution from 2 to 1 is correct. 2. OM23L has an above constrain BUT it has two alt values, 3000 and 1850 There should only be ONE Alt constrain unless its between The FMGS is not that smart to "choose" what alt constrain Link to comment Share on other sites More sharing options...
NAVData 8 Posted August 10, 2013 Share Posted August 10, 2013 Danke Patrick - auch Hinweis #2 ist sehr wichtig! Ich werde das richtigestellen und Revision 2 online stellen sobald ich fertig bin! Thanks to Josh too :-) Herzlichen Dank für die Hilfe! Lg, Richard PS: Revision 2 ist online - habe den EDDL approach probiert und der VNAV war perfekt ... Link to comment Share on other sites More sharing options...
HansW 28 Posted August 10, 2013 Share Posted August 10, 2013 Hallo Richard, danke für die klärenden Sätze und ich hoffe, daß damit die beiden Addons im Sinne der Kundenzufriedenheit ein Stück näher zusammenrücken. Ich wäre in diesem Zusammenhang aber auch noch an einer Klärung des BAM/00 (BAM248°) Wegpunktes interessiert, weil der FD legtype in vielen approach codings enthalten ist. Nochmals danke an die offiziellen Vertreter der beteiligten Addons. Ich fühle mich als Kunde ernst genommen und hoffe, daß dieses auch für den eigentlichen "Verursacher" (OP) dieses Themas gilt. Hans(-Werner) Link to comment Share on other sites More sharing options...
Patrick1246 353 Posted August 10, 2013 Share Posted August 10, 2013 Ich sehe auf Deinem Screen kein Problem mit dem FD Leg, wird es falsch abgeflogen ? Die Darstellung sieht für mich ganz ok aus. Link to comment Share on other sites More sharing options...
HansW 28 Posted August 10, 2013 Share Posted August 10, 2013 @Patrick APPTR,D23L,23L,BAM FD,BAM,51.327758,7.176983,0,BAM,0.0,0.0,320.0,5.6,2,3000,0,0,0,0,1,0 CF,FD23L,51.381814,6.971092,0,DUS,53.0,10.1,233.0,4.0,2,3000,0,0,0,0,0,0 Link to comment Share on other sites More sharing options...
Patrick1246 353 Posted August 10, 2013 Share Posted August 10, 2013 Das ist mit Navigraph, richtig ? Bei Post #11, welcher Airac wurde da benutzt ? Da sehe ich kein BAM/00 Link to comment Share on other sites More sharing options...
christian1974 130 Posted August 11, 2013 Share Posted August 11, 2013 Wenn man sich die Karte von Hans-Werner ansieht, so sieht man eine D5.8 BAM. Sieht man sich exakt die selbe Karte von Jeppesen an, so sieht man hier ein D6.1 BAM. Ist das jetzt nun falsch? Nur mal so als Tipp - in dem Fall war es nicht dieselbe Anflugkarte. Hans Karte war für die 23L, Die Karte von Richard (NAVData) war aber für die 23R. Daher wahrscheinlich der 0,3NM Unterschied im Anflug vom VOR BAM aus gesehen. Ansonsten stimme ich natürlich immer zu, dass die Navdaten incl der Höhen richtig im jeweiligen Cycle eingearbeitet sein sollten (egal von welchem Anbieter). Link to comment Share on other sites More sharing options...
NAVData 8 Posted August 11, 2013 Share Posted August 11, 2013 Nur mal so als Tipp - in dem Fall war es nicht dieselbe Anflugkarte. Hans Karte war für die 23L, Die Karte von Richard (NAVData) war aber für die 23R. Daher wahrscheinlich der 0,3NM Unterschied im Anflug vom VOR BAM aus gesehen. Ansonsten stimme ich natürlich immer zu, dass die Navdaten incl der Höhen richtig im jeweiligen Cycle eingearbeitet sein sollten (egal von welchem Anbieter). Mea culpa Christian, absolut richtig ... die Karten sind unterschiedlich! Eigentor quasi :-) ... Mir gings aber eher ums Prinzip und um die Aussage ... danke dennoch für den Hinweis Lg aus Wien, Richard Link to comment Share on other sites More sharing options...
NAVData 8 Posted August 11, 2013 Share Posted August 11, 2013 @Patrick APPTR,D23L,23L,BAM FD,BAM,51.327758,7.176983,0,BAM,0.0,0.0,320.0,5.6,2,3000,0,0,0,0,1,0 CF,FD23L,51.381814,6.971092,0,DUS,53.0,10.1,233.0,4.0,2,3000,0,0,0,0,0,0 Hans-Werner, Patricks Frage ist berechtigt ... welche Cycle verwendest du denn? Die DME-Distanzen waren bis vor kurzem nämlich wirklich an der falschen Stelle und Joshua hat mich voriges Monat oder davor darauf hingewiesen. Im aktuellen Cycle (Revision 2 :-)) sieht das nämlich so aus: APPTR,D23L,23L,BAM FD,BAM,51.327758,7.176983,0,BAM,0.0,5.6,320.0,5.6,2,3000,0,0,0,0,1,0 CF,FD23L,51.381814,6.971092,0,DUS,53.0,10.1,233.0,4.0,2,3000,0,0,0,0,0,0 Die DME 5.6 sitzen also VOR dem 320° (zusätzlich auch danach, aber das ist in dem Fall bei dem Leg irrelevant). So sollte es passen und wie gesagt, ich hab´s gestern kurz probiert und bei mir war´s ok ... wenn´s noch etwas gibt, bitte einfach melden - eh klar :-) Lg, Richard Link to comment Share on other sites More sharing options...
HansW 28 Posted August 11, 2013 Share Posted August 11, 2013 Das ist mit Navigraph, richtig ? Bei Post #11, welcher Airac wurde da benutzt ? Da sehe ich kein BAM/00 Vielleicht einfach mal das Brett durchlesen (Ende Zeile 3), bevor man hier mit schreibt. Alle, ja alle meine Tests wurden mit diesem Zyklus durchgeführt und zu dieser Zeit war mir von einer Rev. 2 nichts bekannt. Und BAM/00 ist das, was der Airbus X aus dem FD legtype macht. Und nochmal schriftlich für die, die offensichtlich ein eingeschränktes Sehvermögen haben, in der MCDU steht darüber ein "BAM248°". Beim Abfliegen wird der Outbound BAM und der Inbound METMA etwas abgerundet, sodaß der effektive Kurs bei ca. 305° geflogen wird. Das ist aber immer noch nicht die Vorgabe von 320°. Es führt (bei mir) dazu, daß der g/s vor dem loc gefangen wird. P.S.: im übrigen wird der 2 DME DUS Wegpunkt beim Missed Approach, der auch vom Typ FD ist im AXE vollständig unterdrückt. Link to comment Share on other sites More sharing options...
HansW 28 Posted August 22, 2013 Share Posted August 22, 2013 Leider hat die Korrektur des Codings von Navigraph bei mir nicht zu einer vollständigen Beseitigung der Probleme beim automatischen Anflug auf die 23L via DOMUX2G STAR geführt. Durchgeführt habe ich erneut den weiter oben aufgeführten Flug EDDL-EDDL mit der Version 2 des AIRAC 1308 von Navigraph. Der Screenshot zeigt, dass das Leg DOMUX-BAM verschwunden ist und der Bus von DOMUX direkt zum jetzt a.m.S. korrekt konstruierten Punkt BAM/05 (BAM/320/5.8) und von dort weiter zum FAF METMA fliegt. Richtig wäre m.E. DOMUX-BAM-BAM/05(als overfly). Durch den nahezu direkten Anflug auf METMA wird die Höhe nicht so abgebaut, dass der Localyzer vor dem Glidescope erfasst werden kann. Dieses zeigt das nächste Bild. Noch ein Hinweis: Nach Auswahl des ILS23L-App. und der DOMU2G Star ist BAM noch im FPL. Erst nach dem Einfügen der Appr. Transition BAM verschwindet BAM aus dem FPL. Link to comment Share on other sites More sharing options...
NAVData 8 Posted August 22, 2013 Share Posted August 22, 2013 Hallo Hans-Werner, auch hier habe ich jetzt nochmals analysiert. STAR,DOMU2G,23L,2 1. IF,DOMUX,51.419722,7.536389, ,0.0,0.0,0,0,0,0,0,0,0,0 2. TF,BAM,51.327758,7.176983,0, ,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,0 #1 - Initial fix DOMUX #2 - track to fix BAM Jetzt der Approach-Transition Teil: APPTR,I23L,23L,BAM 1. FD,BAM,51.327758,7.176983,0,BAM,0.0,5.8,320.0,5.8,2,3000,0,0,0,0,1,0 2. CF,METMA,51.383114,6.969997,0,IDSW,51.8,10.5,232.0,4.0,2,3000,0,0,0,0,0,0 #1 - Track from fix BAM to dme BAM/5.8 #2 - course to fix METMA So, und hier ist glaube ich das Problem im AXE. Hier ein Screenshot vom ARINC424 Standard eines FD Legs: Das FD Leg beginnt mit einem Fix, in unserem Fall wäre das BAM (ob das nun vom letzten Punkt der STAR kommt, oder ob es direkt im FD Leg in der Apptr kommen sollte, weiss ich nicht). Auf jedenfall, ist BAM vorhanden und sollte entweder von dort oder dort verwendet werden. Tut es aber scheinbar nicht. Denn wie du auch richtig bemerkt hast: BAM ist nach dem einfügen der APPTR auf einmal weg. Ich bin somit ziemlich sicher, dass dies ein Bug im AXE ist, denn es scheint so, als würde das letzte Leg der STAR gelöscht werden, da man ja davon ausgeht, dass es der erste Punkte in der APPTR ist. Nur dann ist das FD Leg falsch umgesetzt, denn dann fehlt intern BAM komplett. Sorry, aber auch hier denke ich jetzt mal nicht, dass es ein Datenproblem ist, sondern mehr ein AXE Problem. Hier mal zum Vergleich NavdataPro, denn hier sieht man sehr deutlich, was ich oben vermute: STAR,DOMU2G,23R,2 IF,DOMUX,51.41985000,7.53635556, ,0.0,0.0,0,0,0,0,0,0,0,0TF,BAM,51.32775833,7.17698333,0, ,0.0,0.0,0,0.00,0,0,0,0,0,0,0,0 APPTR,I23L,23L,BAMIF,BAM,51.32775833,7.17698333, ,0.0,0.0,0,0,0,0,0,0,0,0 TF,BAM58,51.40248333,7.07931389,0, ,0.0,0.0,0,0.00,0,0,0,0,0,0,0,0 CF,METMA,51.38311389,6.96999722,0,IDSW,51.9,10.4,232,4.00,1,3000,0,0,0,0,0,0 Der letzte Punkt in der STAR ist BAM (als TF Leg), der erste Punkt in der APPTR ist ebenfalls BAM (als IF Leg). Somit kann eines gelöscht werden, sonst wären sie ja doppelt. Soweit so gut, allerdings kann man nicht davon ausgehen, dass APPTR immer mit IF-Legs beginnen (hierzu gibt es keine spezielle ARINC424 Regel) - AXE tut das aber. Ich würde also sagen, Bug im AXE, sorry! Liebe Grüße Richard Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.