will the 777 support RF-legs?

[Jockos 6]

This is a long and informative thread.  Thanks to all.

 

However, now that we are in Beta for the T3, can any of the testers, or indeed PMDG, respond to the query as to if there is any change to the code structure to make the T3 more ARINC 424 compatible with Airport Procedures? 

[Tabs 2,790]

No RF yet. Restructuring our FMC code to accept ARINC-424 data is a massive project and I honestly don't know when that will happen. Possibly with the 744v2 but no guarantees. The way the FMC interprets procedures is at the core of everything it does and doing this amounts to scrapping our FMC code and starting over from scratch essentially. Doing it isn't just about RF legs - there's a ton of other things in the real life data - glidepath angles, transition altitudes/levels, turn direction, DME arcs, procedure turns, different definitions for some of the leg types than what we currently use etc. We'll get to it eventually but this is a long term project.

[Jockos 6]

Ryan, thank you for you clear and concise response

 

I understand that the change would be huge for PMDG and that it is not just about if the information is available.

 

Jock McIntyre

Melbourne, Australia

 

(apologies, forgot to sign my last post)

[Ericd 4]

Is anyone using Aerosoft for the PMDG 737 NGX nav database?

 

I am not too happy with Navigraphs service and would like to try something else if that works well!

Yes, I do. 

Both work perfect, but installing new cycles in Aerosoft is a little bit easier (you can do it all at once) and the aerosoft database has much more gates available.

So I prefer the Aerosoft cycles.

 

Regards,

 

Eric

[machine2035 176]

Is anyone using Aerosoft for the PMDG 737 NGX nav database?

 

I am not too happy with Navigraphs service and would like to try something else if that works well!

I am using NDP and love it.

 

I found its greatest advantage was being able to select numerous ILS approaches for the same runway (ILS-Z, ILS-Y etc.). I think since Navigraph changed their data provider they also have similar options now.

 

If in the future PMDG decide the support RF legs, NDP will have huge advantages as I have found it to include almost all the RNP-AR approaches/departures and arrivals in Australia. I do not believe Navigraph provide this data at all.

 

In regards to the current way people are flying RNP approaches in the NGX (by creating numerous fixes on an arc every 2deg for example) will work for me until anything better becomes available. I am currently using Jock's procedures files for NZQN and while the ND and LEGS page may not represent the real flights ND and FMC legs page, the plane still flies the approach as close as possible to the published approach and I have not visited any sheep on the highlands of Queenstown which is always good :yahoo:

[squerble 300]

Great to hear it's in the pipeline. I'll have a look around at the alternate procedures mentioned above on the NGX for now.

[davidz 26]

Thanks for the response, Ryan. Great to hear that this is in the horizon. Keep up the good work!

[Alec 370]

Thank you for being honest and clear with us.

 

It is a massive project, and we ask you so much because we believe only PMDG and maybe one or two other developers are able to bring to the table such features in a proper way!

 

People will get crazy, but I really believe this is worth delaying future releases to get full attention on this feature! That's my opinion however!

[Fabo 213]

I would donate my time if I had any idea it would help PMDG with bringing this to the table

I understand how great an undertaking it is, and I value that PMDG is honest with us in their stance (i.e. that they want to do it, but it is way too much work and will take a long time)

[raddragon 3]

RNP and RNP-AR don't relate to whether the approach uses RF legs. The "AR" stands for "Authorization Required" - these approaches require specific approval (approval for each approach) from the regulator, rather than a general approval.

 

Indeed there are RNP-AR approaches being flown by Qantas and Jetstar which are simply a straight line.

 

Hi David this is correct, RNP-AR only supports RF and TF legs, standard RNP use all types of legs.

[Barbs 2]

nevermind

[Barbs 2]

Posted this question above but then went away and thought about it to make sure it could be done... now I'm back and here it it.

 

I realise this is an old thread but the upcoming 777 SP release got me thinking about RF legs again.

 

A lot of the discussion is about navdata and ARINC etc.  The premise of my question is that navdata and ARINC is irrelevant when PMDG already give us the ability to create our own procedure code.

 

Example:

APPROACH RNPY05 FIX IBABU AT OR ABOVE 10000 FIX OVERFLY QN577 10000 SPEED 220 FIX 300R1 FIX 290R1 FIX 280R1 FIX 270R1 FIX 260R1 FIX 250R1 FIX 240R1 FIX 230R1 FIX OVERFLY QN573 9200 FIX 210R2 FIX 198R2 FIX 186R2 FIX OVERFLY QN571 8200 FIX 163R2 FIX 151R2 FIX 139R2 FIX OVERFLY QN569 7100 SPEED 180 FIX QN565 6300 FIX QN562 5500 FIX OMUBO 3100 FIX OVERFLY QN555 2440 FIX 118R3 FIX OVERFLY 109R3 FIX OVERFLY QN550 2040 FIX 292R4 FIX OVERFLY 304R4 FIX 316R4 FIX OVERFLY QN545 1480 RNW 05 FIX OVERFLY QN547 FIX 131R5 FIX 119R5 FIX 107R5 FIX 095R5 FIX OVERFLY QN551 FIX 070R5 FIX 056R5 FIX 042R5 FIX 028R5 FIX OVERFLY 014R5 FIX 359R5 FIX 345R5 FIX 331R5 FIX OVERFLY QN553 FIX 303R6 FIX 289R6 FIX OVERFLY 275R6 FIX 261R6 FIX OVERFLY 247R6 FIX 233R6 FIX 219R6 FIX OVERFLY QN557 SPEED 170 FIX 038R7 FIX 045R7 FIX 052R7 FIX 059R7 FIX 066R7 FIX OVERFLY QN560 FIX OVERFLY QN878 FIX 074R8 FIX 079R8 FIX 084R8 FIX 087R8 FIX OVERFLY QN882 AT OR BELOW 11000 FIX OVERFLY SUNGU FIX 266RQ FIX 261RQ FIX OVERFLY QN890 FIX NV

This is RNP-Y RWY05 at NZQN (thanks to Jock McIntyre - www.vapap.com).

 

We can already code where the basic fixes are (eg. QN562, QN555) as they are charted.  All these other fixes are "fill-in" fixes that create the radius to fix legs which looks really messy on the ND but gets the job done.

 

My point is, WE can calculate where the aircraft should fly.  All we need is the ability to code it more concisely.  What would be so difficult about the following?

 

Instead of the first part of the missed apch being...

FIX OVERFLY QN547 FIX 131R5 FIX 119R5 FIX 107R5 FIX 095R5 FIX OVERFLY QN551 FIX 070R5 FIX 056R5 FIX 042R5 FIX 028R5 FIX OVERFLY 014R5 FIX 359R5 FIX 345R5 FIX 331R5 FIX OVERFLY QN553 FIX 303R6 FIX 289R6 FIX OVERFLY 275R6 FIX 261R6 FIX OVERFLY 247R6 FIX 233R6 FIX 219R6 FIX OVERFLY QN557

How hard would it be to have the FMS read the following code?

FIX OVERFLY QN547 ARCL 2.6 FIX OVERFLY QN551 ARCL 1.7 FIX OVERFLY QN553 ARCL 2.0 FIX OVERFLY QN557

The waypoints can be declared in the SIDSTAR file, you can even code in the centre points of the arcs if you need to (nt that I think you do).  All we need is an FMS that can read that new bit of code [ARCL|ARCR NN.N].

[Fabo 213]

Well, about as hard as Ryan mentions it a couple posts up there.