Hi, I noticed that since the last update the SIDs in Frankfurt are sometimes displayed incorrectly, here is an example of the CINDY2A depature on runway 18, actually the flight route is when you start on runway 18 heading south, but somehow the flightpath on the display is a depature to the north and then about a 180 degree turn.
I also noticed that the “800 feet waypoint” should be the begin of the runway, and the end of the runway should be in the south.
On the first picture you see the warning “gps primary lost” - therefore the a/c doesn’t know the exact postion and set the default to north.
Your second screenshot is absolutely correct. The SID goes to south and the initial climb instruction is “fly runway heading to 800, direct RID” …
The altitude restriction of 800 feet is a fictive waypoint because the climb rate can be differ but sure not on the beginning of the runway.
Hope that helps
Richard
No, sorry for the confusion. These are two different SIDS from runway 18.
Regarding the first picture: runway 18 goes south and not north. In the latest Airrac, runway 18 faces north. So wrong way around.
Regarding the second picture: you can see that runway 18 is placed incorrectly (i.e. the coordinates)
And on the subject of “GPS Primary lost” that doesn’t matter, because the error also exists with a completely alingned irs
Strangely, the problem only occurs in the Fenix, the problem does not exist in the PMDG.
I also re-downloaded the Fenix Navigrpahdaten - did not help.
And as I said. The error occurred after I updated the Airrac data in the Fenix.
Hi,
I guess I have found the issue in the Fenix - please give me a little bit time, I will fix it and will release a second revision.
Thank you,
Richard
2 Likes
Hi guys,
I have (hopefully) fixed the issue and have uploaded a new revision for the Fenix database. Please update your Fenix database via our Navigraph Hub and try it again. Feedback are welcome 
Here EDDF CIND2A departure:
Thank you,
Richard
Hi, yes thanks for the fast support and fix. But I saw that some SIDs are selectable when I select wunway 18 e.g. ANEK3D, CIND2 both are SIDs for runway 07C and 07R only.
Hi,
great thank you for the feedback … according your other question:
Thats a database limitation and is not a bug (at least with this version).
The problem is, that a terminal procedure (ie a SID) is splitted into 3 parts:
- a runway transition part
- a common part
- a enroute part
The runway-transition part is clear that this part is designed per runway. The common part (as the word say), it´s more or less either for all runways or for a specific runway (if defined) and the enroute part is a follow up to reach the requested airway, so this part has nothing todo with the runway.
Now, when I look as an example ANEK1F, then we have two runway transitions for 25C and 25L, a common part without any runway and no enroute part (in this case).
The Fenix database has now two tables for this:
- one for the procedures
- one for the legs
Here are both tables (left the procedures, right/right below the legs to the procedures):
You see on the procedure table the ANEK1F and the ANEK1L … the ANEK1F is not runway specific due the common part. The procedure ANEK1L is runway specific to 18 because the common part is only valid for 18 or has possible no common part only a runway transition part (as in this case ANEK1L). Fenix looks now (my assumption) only in the procedure table and when the RWY column is NULL and not specific to a runway, the procedure will be shown for all runways, even when it´s designed in the legs path with the correct runways (as in ANEK1F red line).
It´s a little bit tricky to understand, but in general - I can only set one runway (like the ANEK1L only 18) in the RWY/RwyID-column in the terminals table or NULL, when the following legs are for more then one runway available (like for the ANEK1F for 25C and 25L). Also, there is a index on the terminals table, which makes it impossible to duplicate the entries (ie. for each runway one entry).
Therefore, we must life with that limitation. The database design itself was initially designed for an FSX addon so quite old and therefore the limitations.
It´s not a bug, it was from day one on (incl. the default database which is shipped with the released version). What I want to say is, that this has nothing with the issue and fix now … the same happens with all the previous cycles too.
Sorry, for that I can´t offer any improvement …
Cheers,
Richard
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.