• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Help with RNAV approach

squawkingvfr

squawkingvfr

Messages
6
I'm working on adding RNAV approaches to an airport I made (KIOW), because they don't exist in MSFS for some reason. Anyway, I'm wondering if someone else can vet this XML and make sure I'm actually accomplishing what it should be, relative to the approach plate.

XML: 
<Approach type="RNAV" runway="25" fixType="WAYPOINT" fixRegion="K3" fixIdent="GRAFY" altitude="2300.0F" heading="252.0" missedAltitude="992.0F">
    <ApproachLegs>
        <Leg type="HF" fixType="WAYPOINT" fixRegion="K3" fixIdent="BUCKA" turnDirection="R" magneticCourse="252.0" distance="4.0N" altitudeDescriptor="+" altitude1="3300.0F"/>
        <Leg type="IF" fixType="WAYPOINT" fixRegion="K3" fixIdent="BUCKA" altitudeDescriptor="+" altitude1="3300.0F"/>
        <Leg type="TF" fixType="WAYPOINT" fixRegion="K3" fixIdent="HEWRI" flyOver="FALSE" magneticCourse="252.0" altitudeDescriptor="+" altitude1="2800.0F"/>
        <Leg type="TF" fixType="WAYPOINT" fixRegion="K3" fixIdent="GRAFY" flyOver="FALSE" magneticCourse="252.0" altitudeDescriptor="+" altitude1="2300.0F"/>
        <Leg type="TF" fixType="RUNWAY" fixRegion="K3" fixIdent="RW25" flyOver="TRUE" magneticCourse="252.0" altitudeDescriptor="A" altitude1="663.0F"/>
    </ApproachLegs>
    <MissedApproachLegs>
        <Leg type="CA" magneticCourse="252.0" altitudeDescriptor="+" altitude1="1100.0F"/>
        <Leg type="DF" fixType="VOR" fixRegion="K3" fixIdent="IOW" flyOver="FALSE" altitudeDescriptor="+" altitude1="2600.0F"/>
        <Leg type="HM" fixType="VOR" fixRegion="K3" fixIdent="IOW" turnDirection="R" magneticCourse="352.0" distance="4.0N" altitudeDescriptor="+" altitude1="2600.0F"/>
    </MissedApproachLegs>
</Approach>

Link to the plate: http://aeronav.faa.gov/d-tpp/2010/00682R25.PDF

Any help anyone can provide here would be awesome. I'm new to this and if I can get this one right, I'll have a good model for the others. The thing that's really hanging me up is the hold at the IAF and I don't know if I got that right or not.
 
Hi there:

This mostly looks good! However, your key problem here is that you're not allowed to start a set of ApproachLegs with an HF leg. That's forbidden in ARINC424 and the FS compiler will also refuse it. It absolutely, 100% has to be an IF for an Approach!

However, what you can do is to move the HF into a Transition after your MissedApproachLegs.

XML: 
<Transition transitionType="FULL" fixType="WAYPOINT" fixRegion="K3" fixIdent="BUCKA" altitude="3300.0F">
<TransitionLegs>
<Leg type="HF" fixType="WAYPOINT" fixRegion="K3" fixIdent="BUCKA" turnDirection="R" magneticCourse="252.0" distance="4.0N" altitudeDescriptor="+" altitude1="3300.0F"/>
</TransitionLegs>
</Transition>


You might also want to add verticalAngle=357 to your descending legs, but that's going to be the default anyway.

Good luck!
 
If the approach is in FSX, you might also export it to XML using ADE. I know that's cheating, but, just a thought. :)
 
I’m modelling an airport that has implemented an RNAV approach, so I will need to do it from scratch. Could you share a bit of info about the process?
 
I'm no expert on the process. However, one approach to creating it would be to create the airport in ADE for FSX, create the approaches there using the tools in ADE, including creating any fixes, RNAV points, and navaids you might need that aren't in MSFS already, and export the result to XML and copy and paste it into your airport XML for MSFS. Doing it that way will fill in a lot of the information you'll need, like fixregion, etc.

The post by @Szpike has a lot of the information you'll need to reference to figure out how to write it. I just did a quick google and found the ARINC424-17 spec (it's at 18 now) and went to FAA and found a coded version of the latest set of procedures... can't understand it with a quick perusal, but I bet with some googling you can find the procedure you need to help code it.
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/cifp/download/

I will point out that if you're using the FSX route, you'll likely have to add some fixes and RNAV points, as procedures have likely changed a lot since the database FSX is using was released.

One source of info of course is www.Airnav.com
 
Last edited:
@FlyingsCool Great point about the CIFP!

For reference, this is what the approach that @squawkingvfr is working on looks like in that file:

Code: 
SUSAP KIOWK3FR25   ABUCKA 010BUCKAK3PC0EE AR   HF                     25200040    + 03300     18000                 A JS   161971808
SUSAP KIOWK3FR25   R      010BUCKAK3PC0E  I    IF                                 + 03300     18000                 A JS   161981310
SUSAP KIOWK3FR25   R      011HEWRIK3PC0E    010TF                     25200040    + 02800                           A JS   161991808
SUSAP KIOWK3FR25   R      020GRAFYK3PC1E  F 010TF                     25200031    + 02300                           A JS   162001808
SUSAP KIOWK3FR25   R      020GRAFYK3PC2WALPV       ALNAV/VNAV ALNAV                                                   JS   162011310
SUSAP KIOWK3FR25   R      021ROLOCK3PC0E S  031TF                     25190025    V 0148001493        -300          A JS   162021808
SUSAP KIOWK3FR25   R      030RW25 K3PG0GY M 031TF                     25190025      00694             -300          A JS   162031808
SUSAP KIOWK3FR25   R      040         0  M     CA                     2519        + 01100                           A JS   162041808
SUSAP KIOWK3FR25   R      050IOW  K3D 0VY  L010DF                                 + 02600                           A JS   162051808
SUSAP KIOWK3FR25   R      060IOW  K3D 0VE  R   HM                     35210040    + 02600                           A JS   162061808

The FS coding of procedures is remarkably well aligned to the ARINC424 format. If you compare and contrast the above with the XML in this thread, you can get a pretty good primer as to how to take this data and use it to build new procedures.

Hints: First line is the "BUCKA" transition, which I explained in my post. Lines 2-7 are the remainder of the approach, the ALNAV line can be ignored for our purposes. Then lines 8-10 are the missed approach instructions...
 
Szpike said:
@FlyingsCool Great point about the CIFP!

For reference, this is what the approach that @squawkingvfr is working on looks like in that file:

Code: 
SUSAP KIOWK3FR25   ABUCKA 010BUCKAK3PC0EE AR   HF                     25200040    + 03300     18000                 A JS   161971808
SUSAP KIOWK3FR25   R      010BUCKAK3PC0E  I    IF                                 + 03300     18000                 A JS   161981310
SUSAP KIOWK3FR25   R      011HEWRIK3PC0E    010TF                     25200040    + 02800                           A JS   161991808
SUSAP KIOWK3FR25   R      020GRAFYK3PC1E  F 010TF                     25200031    + 02300                           A JS   162001808
SUSAP KIOWK3FR25   R      020GRAFYK3PC2WALPV       ALNAV/VNAV ALNAV                                                   JS   162011310
SUSAP KIOWK3FR25   R      021ROLOCK3PC0E S  031TF                     25190025    V 0148001493        -300          A JS   162021808
SUSAP KIOWK3FR25   R      030RW25 K3PG0GY M 031TF                     25190025      00694             -300          A JS   162031808
SUSAP KIOWK3FR25   R      040         0  M     CA                     2519        + 01100                           A JS   162041808
SUSAP KIOWK3FR25   R      050IOW  K3D 0VY  L010DF                                 + 02600                           A JS   162051808
SUSAP KIOWK3FR25   R      060IOW  K3D 0VE  R   HM                     35210040    + 02600                           A JS   162061808

The FS coding of procedures is remarkably well aligned to the ARINC424 format. If you compare and contrast the above with the XML in this thread, you can get a pretty good primer as to how to take this data and use it to build new procedures.

Hints: First line is the "BUCKA" transition, which I explained in my post. Lines 2-7 are the remainder of the approach, the ALNAV line can be ignored for our purposes. Then lines 8-10 are the missed approach instructions...
Click to expand...

That's awesome :)
Thanks for pointing that out... I glanced through the file and my brain exploded... but your example makes it make sense. I'm starting to wrap my head around how to write these.

Turns out Asobo didn't include the approaches for my airport, KASH, so I've been working on understanding how to add them....

Of course, I imagine as soon as I do, when they release the USA update they're talking about, they'll probably be in there, haha!
 
Last edited:
@Szpike I'd like to hear your opinion...

I'm redoing my local airport KASH (I already released an update to the hangars which were wayyy too tall, I don't know what their predilection for huge hangars is?). I got about halfway through my instrument training there back in the late nineties. The NDB I used to use there, however, (CHERN) has been decommissioned. I'm thinking of adding it back in and creating the procedures that used it. I like using ADF and VOR sometimes anyway just cause I learned to fly before GPS and I'm a history buff and love the golden age of aviation, and I enjoy the mental gymnastics.

So I figured I'd release two versions, one with the NDB and one without...

And then, as I write this, I realized perhaps why the procedures for KASH have changed so much... I thought it was just the move to RNAV; then I remembered the runway was moved over and lengthened by 500'... that move over by 1 or 200' being the key here. I wonder if that's another reason they decommissioned CHERN since it's not lined up with the runway anymore? Hmm, I'll have to check that. So maybe I'd redo the airport to the old runway configuration, too... Hmmm

Anyway, my question is, do you think it's worth it to bring back old NDB and VOR procedures that have been deprecated?
(I'm going to add the new one, too, since there are none for the airport, anyway)
 
I think there's no harm in producing "historical scenery" as long as it is well flagged as such!

I'd definitely make sure you're working on two separate projects though, one in terms of the current positioning of KASH with its current procedures, and one which reinstates the historical positioning of KASH with the old NDB / VOR procedures.

I don't think I would add an NDB/VOR procedure for an airport with a runway in a different location to where it is in MSFS, if that makes sense.
 
Szpike said:
I think there's no harm in producing "historical scenery" as long as it is well flagged as such!

I'd definitely make sure you're working on two separate projects though, one in terms of the current positioning of KASH with its current procedures, and one which reinstates the historical positioning of KASH with the old NDB / VOR procedures.

I don't think I would add an NDB/VOR procedure for an airport with a runway in a different location to where it is in MSFS, if that makes sense.
Click to expand...

Yep, that makes sense :)
 
Hi @Szpike ,

It was a lot of work, but I think I properly created a set of procedures for KASH. In the zip I've included the plates, an xml file of the procedures I created, and the latest CIFP for KASH. Would you mind perusing my procedures and tell me what you think? I have checked them in the latest ADE and they seem to work. And I compiled them into my latest version of KASH, and the airport turned green, so it knows it has procedures.

Some Issues I have questions about...

1. ADE seems to ignore Altitude Descriptor unless it's none, plus or A. I had a couple at V, J, and H (from the CIFP), but when I read in the xml to ADE, it just sets them to plus. Is this a known issue?
2. ADE doesn't seem to let me create some legs and stuff I want (like CA), I'm wondering what I'm doing wrong in that it won't let me add legs like that, like a CF to a Runway, too. To get around it, I just added the cards to an XML file of the procedures, and imported them to ADE, and it takes those cards just fine.
3. On importing these procedures into the airport I'm building for MSFS, included the waypoints in the build, thinking they'll be the "Terminal_Waypoints" my procedures are using (according to somebody, Waypoints are for enroute charts, and Terminal_Waypoints are owned by the airport. But mine already exist in MSFS as waypoints and RNAV locations. Should I have left them out? When I'm in the VFR map in sim, some of the points I added flicker in the map, as if they are duplicates.
4. I don't know how to check if the procedures are usable in MSFS. It does recognize the airport now has approach procedures, so that's hopeful...
5. In the CIFP, the VOR's MHT and GDM on for instance the R32 RNAV are listed as Initial fixes for Transitions. Should I have included them in my Transitions as an IF? Granted, in the CIFP, they have an altitude of 18000. I just started those Transitions at the first RNAV node in the Transition
6. Is there any way to test the quality of the approaches in sim?

Thanks!

Tom
 

Attachments

  • KASH_Approach Procedures.zip
    965.6 KB · Views: 183
Last edited:
The code for approaches in ADE was created a long time ago and is unlikely to be updated in the foreseeable future. Most of the functionality was defined by Jim Vile who is sadly no longer with us and greatly missed

I know there are some issues with approaches in P3Dv5 related to SID?STAR. Of course MSFS should be based on FSX. We have not looked at the actual formats for approaches in MSFS yet, This is the list from the XML Schema for Approach Leg Types

1602484706004.png
 
Hi Jon,

I'm sorry, I hope you didn't think I was complaining about ADE. Super wonderful amazing tool it is. I just went from zero knowledge on understanding approaches besides understanding the what a nav fix is in Flightsim to 4 completed ones in 2 days from scratch, and I wouldn't have been able to do that without ADE. Thank you.

I was more worried that perhaps I was doing something wrong.

I've searched, not super hard, but I haven't been able to find a schema description of the whole Approach xml for FSX. Does it exist online anywhere? I assume it doesn't exist yet for MSFS?

Thanks,
Tom
 
I didn't think that you were complaining. The schema xsd for MSFS is in the SDK. Something like XmlPad will make it easier to read and create some diagrams
 
Szpike said:
bglcomp.xsd is in the Flight Simulator folder as of 1.9.3, as some minor changes occurred with that patch.
Click to expand...
Excellent....

And then I walked away confused... I notice under WaypointType, I have several different choices for value. Problem is, what the Waypoint is depends on the Approach... Should I create a different xml file for each approach? Waypoints fall under Runway, not inside an approach. So for an ILS Approach, a waypoint can be an intercept, it can also be a FAF or IAF. In an RNAV, the same waypoint name can be used for an RNAV type waypoint... How does MSFS handle that?

Currently, I just call them named.. the other problem being, all these fixes already exist in MSFS... should I bother creating them at all?
 
Yeah, Waypoints type is misleading. "Named" is the right way to do it.

Also the types shown relate to the type of the waypoint rather than its function in the current context, so to speak. FAF's inclusion there is particularly misleading!
 
I couldn't find any way to document the FAF in the Approach options, so I assumed you don't. Is that correct?

And really, the more important question I have, given that all the waypoints already exist in MSFS, should I or should I not create them with my airport?
 
You must log in or register to reply here.
Back
Top