will the 777 support RF-legs?

[DLH_FRA 0]

They get all the public data from EAG, EAG are about to start supporting RF legs so Navigraph will get the EAG public RNP approaches with RF leg types

[DLH_FRA 0]

Would be nice if PMDG would just conform to the specifications for the FMS, then we could have a choice in which navigation database to use.

[Alec 370]

Did you read from the guy who do the work with the AIRAC at Navigraph that they were going to start implementing RF-Legs into their "products"? Just because it's been offered to them in a more complex way doesn't mean he well adapt his AIRACs to be using RF-Legs, since no addon manage to use that, and it will take some time until someone make one that do.

 

Just curious, I would love a more complex implementation of the database also. Addons like PMDG deserve to be fed with data from the real world.

[JDHK 0]

There is a standard how procedures like approches, SIDs, STARs... are encoded in the NavDatabase. This standard is commonly called ARINC424 that describes a so called Path/Terminator-concept (e.g. fly path XXX° until XXXD is reached). That's the way all modern airliner fly today.

 

PMDG told me years ago they plan to implement an version of the RF function (Radius to Fix). So you could program the AP shall fly a given radius from an artificial fix. Not the very unsatisfying workaround to program every 10° a fix (like for an arc, there is a arc function as well specified in ARINC424).

 

I saw a lot draft versions for new approach procedures utilizing the RF-leg type.

I attach a draft version of a new approach procedure as sample:

 

What does mean the number that is under the MAX speed? I mean, "2.0". And the one that is under "2.0". "2,07 ARC L"

[DLH_FRA 0]

It is the radius to fix information RF, for example if you have an ARC between two waypoints DF1 and DF2 and next to this it says 2.0 ARC left.

 

That would mean the ARC center is located at 90 degrees and 2.0NM from DF1. so if you went with a length of rope 2nm from DF1 and then placed it on a tent peg.. the arc that could make with that rope would be the ARC between waypoints DF1 and DF2. (Hope that makes sense!)

 

This is the bit we need within the PMDG navdata a way of coding the ARC centers then it is easy peasy to make these procedures

[gman1986 14]

It's awesome that pmdg make pretty much a complete simulation of jetliners. Would be even better if someone made it so that we can have the best navigation data in these aircraft too.

[DLH_FRA 0]

The people that need to do that are PMDG, because their FMS does not work like a real FMS... the inner workings are not the same. This is the problem we have that you start with a real navigation database then have to "make it work" in PMDG as opposed to just using a real one.

 

The main problem if my memory serves me right is that PMDG does not use the AIRIC standard legs Eg TF (track to fix) RF etc

 

Because it does not use these we have the problems or having to tweek the data to get it to sort play like the real thing.

 

Other sims such as PSX use something that is much more like the standard ARINC database... Which is very nice because some people (myself) have the ability to download our company navdata base from the flight information viewer :) then i could fly our interesting company approaches to my hearts content :)

 

Instead I have spent many many hours of work getting them to play nice in PMDG

[Alec 370]

Let's hope PMDG is willing to look into it and make their simulation even better! And I also need to learn how to make my own procedures for PMDG, there are lots missing for Brazilian airports

[DLH_FRA 0]

Thats the problem with Navigraph they use the data from EAG which dont have that large of a customer base.

 

From a flightsim point of view the best would be Jeppesen as they cover everything.

 

LIDO is excellent in every regard, but all of their information is custom, so for example within LH each fleet type has its own database that will only contain airports which that fleet will fly to.. Along with airports that we may consider if we need to divert.

 

We also have many of our own procedures in the database which are only available to company aircraft. From custom visual approaches (coded into the FMS for guidence) to the special MD11 approach at Quito.

[JDHK 0]

It is the radius to fix information RF, for example if you have an ARC between two waypoints DF1 and DF2 and next to this it says 2.0 ARC left.

 

That would mean the ARC center is located at 90 degrees and 2.0NM from DF1. so if you went with a length of rope 2nm from DF1 and then placed it on a tent peg.. the arc that could make with that rope would be the ARC between waypoints DF1 and DF2. (Hope that makes sense!)

 

This is the bit we need within the PMDG navdata a way of coding the ARC centers then it is easy peasy to make these procedures

 

Thanks for your answer. Now I have clear that 2,07 ARC L is the lenght in NM. But what is 2.0 (Which is above 2,07 ARC L)?

[DLH_FRA 0]

No Jorge,

 

a RF (Radius to Fix) aka ARC must have a center.

 

Think of a donkey on a length of rope, the length of that rope is the distance that is show on the chart.

 

This is important because the further away the center is ie if the chart said 10nm L that would make for a much shallower turn, a smaller radius would give a steeper turn.

 

The arc center is located at 90 degrees from the fix at the distance specified on the chart, so if you plot this distance out then you can calculate the path the arc will take.. couple this with knowing the distance the aircraft is in the arc and then you can plot the next waypoint.. this is how we can model the RNP (RF) approaches into PMDG for airports where the arc centers are not published.

 

To do this you calculate the ARC center as i describe above, calculate the position of the next fix, then you need to add phantom waypoints along the arc to force the aircraft to follow the ground track...

 

Now if PMDG would just make the FMS like a real one it would make things so much more easy!

 

I have a feeling im not explaing this in a very clear way!

 

Feel free to keep asking until i can think of way to explain it without showing you in person! It's all very simple just hard to decribe in black white without any graphics on here!

[Marc_H 1]

It's only useful if they get real Navdata to go with it. Until PMDG makes a deal with Jeppesen, Lufthansa or such, it wouldn't make a difference if they supported it.

Hi Alec, most of us fly with Navigraph cycles. Navigraph has a contract with the EAG (European Aeronautical Group) now navtech.

They get the whole ARINC424 conform database and Richard "scales" this infomration down to the differen Add-On-File-Formats.

 

If PMDG would decide to implement the full ARINC set, Navigraph could provide us the most real (**THE** real) navdata.

But it would be just fine PMDG implents the arc funtions only.

 

I attach a very prominent approach which utilizes the RF-Function (and which is completely unable to fly with PMDG jets).

I overlayed the way PMDG (LNAV) flys the proc (in red) and in blue the way the aircraft will over- or undershoot:

 

[...]this is how we can model the RNP (RF) approaches into PMDG for airports where the arc centers are not published.

Most agencies publish the RF artificial fix coordinates.

The navdata provider include they into the database. Via Navigraph (EAG -> navtech) we have access to the required information.

[Marc_H 1]

and another example

RF and AF are the two arc functions we'd need :)

[Alec 370]

Wow, those procedures really show the importance of modeling RF-Legs, without it it's suicide trying those approaches!

 

And I always knew Navigraph gets the ARINC 424 set from their supplier, what I just don't believe is that their supplier is going to let them distribute that file to us, since it's exactly the same stuff they sell to the airliners, right?

[DLH_FRA 0]

The problem at present is two fold.

 

Navigraph get there data from EAG / Navtech. A the moment they do not include RF legs in any of their data (at present they don't have any airlines using it

 

The other part of the problem is that many of the procedures containing RF legs are company specific and copyright of their respective owner.

 

However, Navtech / EAG are going to start supporting RF leg types.. This data (for public approaches) will be passed along to Navigraph.

 

EAG already supply Navigraph with a real world database for flight simulator use, it is just not partofthe contract that it can be used for real flight (so EAG don't lose any money)