Using Windows 10 and X-Plane 11
Data in Chart view and AIRAC 2207 CIFP/LDOS.dat file do not agree
Unable to select proper Approach data from AIRAC 2207 data set to enable DME Arc App for G1000/FMC navigation
I believe the name for the KLS DME in AIRAC 2207 Nav.dat file is incorrect. Should it not read OSIJEK rather than KLISA
Cannot check in detail as I am on mobile. But you posted the CIFP for the final approach, whereas the DME ARC is most likely part of the approach transition insteadā¦
Tim
@Rodeo314 Please do further in depth checkā¦as your reference to ā the DME ARC is most likely part of the approach transition ā is the part of the CIFP data for LDOS that, I believe, is missing, and why I registered this thread.
That wasnāt particularly obvious to me from your first post.
It does seem like an approach transition to I29-Y from CE should exist and doesnāt; no idea why but this looks like a question for @NAVDataOld
Tim
Hi guys,
sorry for the delay of this answer ā¦ the problem here is the missing VHFNavaid ā¦ the KLS navaid is a DME only navaid (you see this on the chart-symbol and the small D on the top-left corner).
To code a AF leg (Arc-to-fix) according the ARINC424 standard rules you need a collocated VHF (means VOR, VORDME, VORTAC or a TACAN). A simple DME navaid is not enough to code this procedure and therefore its missing.
Hope that helps,
Richard
@NAVDataOld ā¦ Thankyou for your reply.
I would rather this topic was not auto closed yetā¦as I am now gathering more real world info, and relating with real pilotsā¦as to where the responsibility lies for this current apparent problem.
I can confirm the Navigraph chart, is a true reflection of the real world Croatian AIP chart. I can not believe a real world approach chart would exist, be approved, and issuedā¦if the required supporting infrastructure was not available to fly such an approach.
My belief is, there is sufficient data available to draw the dme arc with its relevant entry and exit, and other intercept waypoints, as you will note they are related to either CE or OSJ Nav Aids
ItĀ“s possible that you code this in any other way as tailored records, but as I wrote in my answer, according the ARINC424 standard rules a AF leg is defined over a VORDME navaid and in this case, there is only a DME component available - a code DME ARC via an AF leg needs at least following information that it could code correctly:
So, when you have only a DME navaid, you see that you canĀ“t fullfil this requirement. Therefore, not codeable, that does not mean, you canĀ“t coded in any other way as tailored record for ie. Airline specific procedures, but again not via an AF leg thatĀ“s impossible.
Last, the charts has nothing todo with the coding behind because the coding follows specific rules, you can draw what ever you want - the important thing in the charts are only the symbols but you have no information, how a leg will be coded.
Hope that helps,
Richard
PS: OSJ and CE are both NDBs and not navaids. NDBs have no DME component and therefore useless for a DME Arc.
Thankyou for your reply @NAVDataOld / Richard
I totally hear, and concur, with what you say in respect of required data to build an AF Leg to ARINC 424.
I do have a copy of ARINC 424, albeit not the latest release., and on many occasions had reason to refer to it.
In the light of:
I just find it strange that such a chart should be allowed to exist, and yet have to be manually configured for use in a modern FMS in order to fly this approach as set out.
I will continue to investigate.
Ref: earth_nav.dat
Should:
13 45.466183333 18.792266667 314 10935 130 0.000 KLS ENRT LD KLISA DME-ILS
be changed to read DME only
From current authentic āreal lifeā resource
I further question, what this Nav Aid should be currently known as. All current charts refer to it being named OSDIJEK.
Correct
Correct
Yes and no - the charts will not be created from the data and vice-versa. A chart is a visual view of the procedure but that doesnĀ“t mean, that you can code it according all ARINC424 rules, as I have shown you above with the requirements of an AF leg path type. To make it more simpler: a typical examples are visual parts in the charts ā¦ you see it on the charts, but you canĀ“t code it because there is no terminal-leg path type for this ā¦ therefore in most cases this part is missing in the data or you get a discon in your FMC/S but you can fly it.
ItĀ“s a DME only navaid, which is used for the ILS approach
The main point here is the duplicated names due the same name on the NDB - on the charts itĀ“s no problem but not in the database. In the FMCs/GARMINs you normally use the idents only, so thatĀ“s really only cosmetic and has nothing todo with the functionality ā¦
Cheers,
Richard
@NAVDataOld / Richard
Thank you very much for your time, contributions and understanding.
My investigation will continue as to how this topic and similar situations are being handled in the current real world, but as for now, will accept this topic be considered closed
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
