Approach Code

cowpatz · 27 Jul 2008

I have just rekindled an interest in making up approaches for a few New Zealand airports that do not have default ones available in FS9.

1. Jim very kindly sent me some leg definitions a few years ago when I first started out dabbling in this and together with the SDK literature I can work most things out. However in the SDK the acceptable values listed for the attributes do not give any indication as to what they are based on. i.e. for an AF leg you are required to give theta and rho values as well as a magnetic course. As this is an arc to a fix then what are the values measured from?

2. Is there a simple explanation to altitude 1 and altitude 2?

3. Which leg types cant be used together?

4. When I alter the approach I alter the original BGL file (in this case in the Ocen scenery file) but keep an original back up. Is this the correct way to do it or should I have the modified code in another BGL file in another folder. If so which file, should it contain all the data and what is the naming convention required to be?

5. Is there a way to refresh the scenery database without having to restart FS9 all the time. Mine takes an age to crank up.

6. What is the difference between a named and unnamed waypoint?

7. Is there a good site or document that can assist with this side of scenery design? Something like Terry Yingling's "How to make terminal approaches" for PMDG guide?

Many thanks
Steve

scruffyduck · 27 Jul 2008

Jim is the best person to answer and hopefully he will be by

When I alter the approach I alter the original BGL file (in this case in the Ocen scenery file) but keep an original back up. Is this the correct way to do it or should I have the modified code in another BGL file in another folder. If so which file, should it contain all the data and what is the naming convention required to be?

No you should not alter any Bgl file but create a new Bgl. It needs to contain the basic airport header data and in the Delete Record DeleteAllApproaches needs to be set to true. This will stop the approaches from the stock airport being used. If you want them replicated then copy the xml into the new bgl file. That way you retain all the existing approaches and can modify them as required. The Bgl needs to be placed in an Addon Scenery Folder so that is is read after the stock airport.

Is there a way to refresh the scenery database without having to restart FS9 all the time. Mine takes an age to crank up.

Don't think so. I think you can try loading an airport in a different part of the world and then go back to your original but I have heard that this does not always work. The only sure way I know is to start again. Also be aware that FS9 should be shut down before you copy or re-compile the modified Bgl. If it is active (in use in FS) then it will not get updated.

What is the difference between a named and unnamed waypoint?

I asked Jim this the other day and he told me that if you can say the waypoint ident (TOKAY) then it is named. If you can't (T1234) then it is unnamed. As far as we can tell the type is ignored in FS in any case.

Is there a good site or document that can assist with this side of scenery design? Something like Terry Yingling's "How to make terminal approaches" for PMDG guide?

There are some posts on Approach code in the Airport Design Editor Forum here. They refere to FSX of course but I don't think that matters

cowpatz · 27 Jul 2008

Thanks very much Jon.
Should the new BGL file have the same APXXXXXX.BGL name or does it not matter?
Thanks
Steve

scruffyduck · 27 Jul 2008

cowpatz said:
Thanks very much Jon.
Should the new BGL file have the same APXXXXXX.BGL name or does it not matter?
Thanks
Steve

No it must not have the same name. For starters the AP file may contain a number of airports and second, if by chance it got moved to the wrong place it might over write the default file and you would lose all those airports. Just give it a name that makes sense to you.

jvile · 27 Jul 2008

Steve

Name your bgl something that resembles what it is for.

KATL_App_jv.bgl

Tells me the approach is for Atlanta and has my initials. If you use the ICAO code first this will normally keep all your airport bgl's in some sort of order.

I noticed you had a post on AVSIM. The reason you are getting 90 degree line draw is IF/TF is being used and they have no built in turn radius. IF/TF are nomally the leg combinations used for RNAV type approaches. Even when the line draw is set at 90 degree angles the User Plane flys a 'fly by' and not a 'fly over'. Regardless of how we code the fly by or fly over FS only knows the 'fly by' attribute. Based on type plane (airspeed) FS will anticipate the turn with its own radius.

If you still want the line draw radius in a turn from a Waypoint to a Waypoint then use IF/CF Combinations. It is important that Mag Course be set in the CF Leg so the radius of a turn does not swing out too wide.

I have just rekindled an interest in making up approaches

If you are making up approaches then we use the Name/Unname scheme definiton that Jon has already posted on. There are other rules based on Country but the 'I can say', 'I cannot say' is a good starting point.

More to come based on other questions you have.

tyrant · 27 Jul 2008

Is there a way to refresh the scenery database without having to restart FS9 all the time. Mine takes an age to crank up

Hi Steve,

With ref to the above, do you have a lot of installed AI traffic installed? If so, thats what can drag out the restart process. I created another Aircraft folder and just copy the FS default AC into it, So when i'm working with scenery, I rename my AC folder to aircaft2, and rename the new one containing the default AC to aircraft.

This cuts my startup time from a good 4-5 mins to less than 30 seconds.

Regards

Jason

cowpatz · 27 Jul 2008

Thanks for the replies. No I do not have a lot of AI installed but I do have a fair bit of scenery and user aircraft.

Jim I have resolved it by using a code as follows:

<Transition transitionType="FULL" fixType="NDB" fixRegion="NZ"
fixIdent="KT" altitude="3000.00F">
<TransitionLegs>
Leg type="IF"
altitude1="3000.00F"
altitude2="0.00"
ltitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="NDB"
fixIdent="KT"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="KT"
recommendedRegion="NZ" />
<Leg type="FC"
altitude1="1500.00F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="282.00"
distance="15740.74"
flyOver="TRUE"
fixType="NDB"
fixIdent="KT"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KT"
recommendedRegion="NZ"/>
<Leg type="DF"
altitude1="1500.00F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
turnDirection="R"
flyOver="TRUE"
fixType="TERMINAL_WAYPOINT"
fixIdent="IF12"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="IF12"
recommendedRegion="NZ"/>
</TransitionLegs>
</Transition>

It might not be pretty but it works and give a good graphical representation.
I am having probs with the CA leg type but I think from memory this wasn't handled well in FS9.
Thanks
Steve

jvile · 27 Jul 2008

Steve

I do the same as Jason posted to speed up FS9 load times.

When I am working with writing code I also have 2 aircraft folders and 2 scenery.cfg files. One is a default like Jason does with the aircraft and I also take out all 3rd party scenery with a working scenery.cfg.

Your Transition looks fine to me. I would recommend using a IAF12 rather then a IF12 for the Terminal_Waypoint. IF is usually the 'Initial Fix' to a STAR arrival entrance point. IAF is usually the 'Initial Approach fix' to the runway. That way you have a pair that looks like they belong together (IAF12 and FAF12).

The nice thing about the legtypes is you can piece them together one way or the other in order to get a proper line draw. However, I will give a caution that the line draw you see is a pre dll XML line draw. You MUST load the approach in the GPS receiver so the .dll will process it. This is to be sure the dll accepts the type legs you used and can draw the approach once the dll file passes it through to the GPS Receiver.

Once you have look at the line draw as pure XML and then loaded it into the GPS reciever so the .dll can process it (looks ok) you have one more test to complete.

The Approach header

<Transition transitionType="FULL" fixType="NDB" fixRegion="NZ"
fixIdent="KT" altitude="3000.00F">

is the only part that the ATC Engine extracts out of the entire approach code. When you write the Header you must start FS9/FSX and go check to see if ATC recognizes the correct data and passes it through to the ATC Window. Many times the fixtype= and the fixident= is not a valid tag based on airport boundary's in other type bgl files that get processed.

Go fly a short IFR FP. When ATC gives you the default approach select 'standby' in the ATC window and see if your Transition is available under the type approach and runway it is assigned to.

Your question on the altitude 1 and 2 is a step down type approach. Here is a snip from ARINC 424

6.2.10.3 Step down fixes will have altitude codes according to the government source documentation. These altitudes will be assigned altitude descriptions codes indicating the altitude as mandatory, minimum or recommended
and altitudes on the vertical path (Section 5.29 of this Specification). Both Altitude 1 and Altitude 2 will be
used on step-down fixes.

Many many attributes in the approach code are based on ARINC 424 but have no affect or used once the XML is passed to the dll for processing. I can only assume that FS has future plans to use more of these attributes if FS introduces a Jeppesen or Rockwell FMC and not just the GPS Receiver.

I think Jon already covered this but there was no change in the way we write the approach code between FS9 and FSX. The only difference is to use the correct compiler.

jvile · 27 Jul 2008

3. Which leg types cant be used together?

I will make a chart and post which legs go together and which will not work when combined. I think I still have the one I placed on PAI many years ago.

jvile · 27 Jul 2008

Steve

Before I place a chart on leg combinations here is a overview of all leg definitions and the attached .pdf that illustrates the leg line draw used both in the FS9/FSX .dll.

Type 2 Letter Approach codes

"type=IF" Initial Fix or IF Leg. Defines a database fix as a point in space.

"type=TF" Track to a Fix or TF Leg. Defines a great circle track over ground between two known databases fixes.

"type=CF" Course to a Fix or CF Leg. Defines a specified course to a specific database fix.

"type=DF" Direct to a Fix or DF Leg. Defines an unspecified track starting from an undefined position to a specific database fix.

"type=FA" Fix to an Altitude or FA Leg. Defines a specified track over ground from a database fix to a specified altitude at an unspecified position.

"type=FC" Track from a Fix from a Distance or FC Leg. Defines a specified track over ground from a database fix for a specific distance.

"type=FD" Track from a Fix to a DME Distance or FD Leg. Defines a specified track over ground from a database fix to a specific DME Distance which is from a specific database DME Navaid.

"type=FM" From a Fix to a Manual termination or FM Leg. Defines a specified track over ground from a database fix until Manual termination of the leg.

"type=CA" Course to an Altitude or CA Leg. Defines a specified course to a specific altitude at an unspecified position.

"type=CD" Course to a DME Distance or CD Leg. Defines a specified course to a specific DME Distance which is from a specific database DME Navaid.

"type=CI" Course to an Intercept or CI Leg. Defines a specified course to intercept a subsequent leg

"type=CR" Course to a Radial termination or CR Leg. Defines a course to a specified Radial from a specific database VOR Navaid.

"type=RF" Constant Radius Arc or RF Leg. Defines a constant radius turn between two database fixes, lines tangent to the arc and a center fix.

Note: While the arc initial point, arc ending point and arc centerpoint are all available as database fixes, implementation of this leg type may not require them to be available as fixes.

"type=AF" Arc to a Fix or AF Leg. Defines a track over ground at specified constant distance from a database DME Navaid.

"type=VA" Heading to an Altitude termination or VA Leg. Defines a specified heading to a specific Altitude termination at an unspecified position.

"type=VD" Heading to a DME Distance termination or VD Leg. Defines a specified heading terminating at a specified DME Distance from a specific database DME Navaid.

"type=VI" Heading to an Intercept or VI Leg. Defines a specified heading to intercept the subsequent leg at an unspecified position.

"type=VM" Heading to a Manual termination or VM Leg. Defines a specified heading until a Manual termination.

"type=VR" Heading to a Radial termination or VR Leg. Defines a specified heading to a specified radial from a specific database VOR Navaid.

"type=PI" 045/180 Procedure Turn or PI Leg. Defines a course reversal starting at a specific database fix, includes Outbound Leg followed by a left or right turn and 180 degree course reversal to intercept the next leg. A Maximum excursion Time or Distance is included as a data field.

"type=HF, HA, HM" Holding in lieu of Procedure Turn (HF) for Approach Procedures and Mandatory Holds (HA, HM) in SID/STAR and Missed Approach coding. The HA, HF, and HM Leg Types define a holding pattern in lieu of procedure turn course reversal or a terminal procedure referenced mandatory holding pattern at a specified database fix. Leg time or distance is included as a data field. The three codes indicate different path termination types:

HF = Single circuit terminating at the fix.
HA = Altitude Termination
HM = Manual Termination.

Flyover Waypoint is used for the ending leg of all SID (DP), STAR and Approaches including the threshold of the runway if "TF, CF" is used

NOTE: Not required in FS9/FSX

RF legs do require the flyover leg for the arc in the VOR, VOR/DME, NDB, etc. type approaches

Waypoint flyby/flyover requirements:

Setting Position Two of the Waypoint Description field to T or F indicates a Flyover Waypoint; the fix in the record is to be over flown before flying the next leg. Absence of the T or F indicates a Flyby Waypoint; turn anticipation may be used to acquire the next leg.

FS9/FSX uses False as the default tag

The coding requirement of the Flyby or Flyover condition.
The RF leg overflys the terminating fix in all cases.
The RF Leg is to be used only in the following cases:
The CF leg is available as a leg type in RNAV Terminal Procedures only when specifically called out in the government source documentation. When this is the case, the leg data will include a reference from which the magnetic variation for use in flying the CF Leg can be determined. This reference will be provided in the Recommended Navaid field of the procedure record.

cowpatz · 27 Jul 2008

Thank you very much for that Jim. Your time and expertise is really appreciated. I am not sure where the flt sim community would be without the likes of yourself.
I still actually have copies of that information from my previous exploits many moons ago.
I am trying to vary the approach fix names (but to stay as close to the naming conventions) due to the fact that an airport may have several approach types NDB,VOR and RNAV. I will however alter the one above as you mention.
I can understand Theta and rho (as being a bearing and distance from a fix) on an ILS and say a FD leg type but what about say an arc leg type such as the aforementioned AF? or is that theta and rho from the arc center point to the TO fix?
Any reason why the CA leg type flys so poorly. I could put a CF in there to stop an early turn but this doesnt look right on the GPS when comparing it to the approach chart. What I am trying to do is raise the "climb to altitude" so that I get a turn happening at the correct altitude but I am not sure yet how this will work out with different aircraft performance types.
Finally what do you do for say a full NDB approach that has different outbound legs for Cat A&B aircraft and for Cat C. Obviously the transitions will be different but what would be the best way to name the transitions to show this to the user? It is my understanding that only alpha/numerics can be used for naming is this correct?

jvile · 28 Jul 2008

In reverse order

Finally what do you do for say a full NDB approach that has different outbound legs for Cat A&B aircraft and for Cat C. Obviously the transitions will be different but what would be the best way to name the transitions to show this to the user? It is my understanding that only alpha/numerics can be used for naming is this correct?

You would have to make 3 different Transitions. One for each catagory type plane. I would first write the Full NDB vectors to final.

<Approach
type="NDB"
runway="34"
designator="NONE"
suffix="0"
gpsOverlay="FALSE"
fixType="NDB"
fixRegion="K7"
fixIdent="DDA"
altitude="2500.0F"
heading="343.443542480469"
missedAltitude="2500.0F">
<ApproachLegs>
<Leg type="IF"
fixType="NDB"
fixRegion="K7"
fixIdent="DDA"
recommendedType="NDB"
recommendedRegion="K7"
recommendedIdent="DDA"
altitudeDescriptor="A"
altitude1="2500.0F" />
<Leg type="CF"
fixType="RUNWAY"
fixRegion="K7"
fixIdent="RW34"
flyOver="FALSE"
theta="0"
rho="0.0N"
magneticCourse="346"
distance="6.7N"
altitudeDescriptor="A"
altitude1="1001.0F" />

Now I would add 3 Transitions for each Catagory approach Unnaming them DDAC1, DDAC2, DDAC3. You would have to have 3 Terminal_Waypoints Unnamed the same and stacked on top each other positioned for the entrance to the Transition based on type plane Catagory approach.

<Transition
transitionType="FULL"
fixType="TERMINAL_WAYPOINT"
fixRegion="K7"
fixIdent="DDAC1" <<<<<<<-------- C2 or C3
altitude="2500.0F">
<TransitionLegs>
<Leg type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="K7"
fixIdent="DDAC1" <<<<<<<<<<<<--------- C2 or C3
/>
<Leg type="TF"
fixType="NDB"
fixRegion="K7"
fixIdent="DDA"
magneticCourse="0"
altitudeDescriptor="+"
altitude1="2500.0F" />

add a Procedure turn with a "PI" which the turn would have a different radius based on type Catagory plane approach

<Leg type="PI"

and wrap back to the IAF of the NDB DDA ident.

The 3 different Catagory Terminal_waypoints I would place over the airport. That way the Plane flys a reverse final to the NDB at a higher altitude, at the NDB it makes a PI turn and descends to capture the NDB back to the runway.

In most cases it is the PI turn that differs for each catagory plane where as the faster planes turn rate covers a greater distance.

Any reason why the CA leg type flys so poorly. I could put a CF in there to stop an early turn but this doesnt look right on the GPS when comparing it to the approach chart. What I am trying to do is raise the "climb to altitude" so that I get a turn happening at the correct altitude but I am not sure yet how this will work out with different aircraft performance types.

CA legs work very well for a missed published approach and that is where FS uses them for the most part. Different legtypes draw the line from a fix or Runway to a point in space based on a Rho, Distance or Altitude value. The CA leg is altitude. I want a missed approach to climb to 2000 ft on runway heading so I use the CA like so

<MissedApproachLegs>
<Leg type="CA"
magneticCourse="60.00"
altitudeDescriptor="+"
altitude1="2000.000F" />

The higher the altitude the longer the line draw of the CA leg. I have not tested what calculation FS uses for a CA leg but I could guess it is based on 200 - 220Kts climbing at 1800 FPM. Regardless, I must be at 2000 ft prior to or At the end of the line draw based on altitude. Now I can add another legtype such as a VM

<Leg type="VM"
magneticCourse="20.00"
altitudeDescriptor="+"
altitude1="2000.000F" />

which is saying I reach 2000 ft which should be about the end of the CA line draw and now the line turns at a 020 degree heading and ends in space as a manual missed approach termination (see the pdf).

I can understand Theta and rho (as being a bearing and distance from a fix) on an ILS and say a FD leg type but what about say an arc leg type such as the aforementioned AF? or is that theta and rho from the arc center point to the TO fix?

We do not use Theta or Rho to make the first part of the arc but use a <DmeArc tag to tell FS I need a arc. We use the arc to a fix (AF leg) Rho which is the distance from D258N to D198N.

Here is a sample XML

<Transition
transitionType="DME"
fixType="TERMINAL_WAYPOINT"
fixRegion="PH"
fixIdent="D258N"
altitude="3000.0F">
<DmeArc
radial="258"
distance="14.0N" <<<<<<<---- Not mandatory because from HNL to D258N is calculated by the GPS
dmeRegion="PH"
dmeIdent="HNL"/>
<TransitionLegs>
<Leg
type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="PH"
fixIdent="D258N"
/>
<Leg
type="AF"
fixType="TERMINAL_WAYPOINT"
fixRegion="PH"
fixIdent="D198N"
turnDirection="L"
recommendedType="VOR"
recommendedRegion="PH"
recommendedIdent="HNL"
theta="198"
rho="14.0N"
magneticCourse="258"
altitudeDescriptor="+"
altitude1="3000.0F"
/>
<Leg
type="CF"
fixType="WAYPOINT"
fixRegion="PH"
fixIdent="KEOKI"
flyOver="FALSE"
recommendedType="VOR"
recommendedRegion="PH"
recommendedIdent="HNL"
theta="198"
rho="9.5N"
magneticCourse="18"
distance="4.5N"
altitudeDescriptor="+"
altitude1="3000.0F"
/>
</TransitionLegs>
</Transition>

Go to PHNL and select the RWY 04 VOR approach with Transistion D258N. Place your Plane (Cess 172) on the HNL VOR and heading Mag 258 degrees. read the GPS receiver in XML line draw mode and then Load, Activate the approach so it passes through the dll. Study the above XML and you will see how the arc is formed from the HNL out to the D258N and then the arc draws from the D258N around to the D198N (14 Miles) then turns left to attach to the KEOKI waypoint.

What the XML says
.

.
What the GPS shows once the XML is passed through the dll sitting at the HNL Waypoint.
.

.
Now we position the C172 at the entrance of the arc (D258N to D198N). The arc is based on the HNL Waypoint (see AF in the pdf) and if we did not have that in the XML then all we would get is a straight line from those two T_waypoints.
.

hope this helps

cowpatz · 29 Jul 2008

Many thanks for that Jim. I am trying to digest it all. I was sort of hoping I could use an AF leg at the end of the outbound leg for the curve base turn back to the inbound leg. I cant seem to get it to work. If the tear drop is not too wide (think Cat A & B) or the outbound leg not too long then at the end of the FC leg I can pop a DF to get to the IAF point on the inbound leg. The radius seems to match nicely albeit a fluke. For the thicker tear drops it seems to overshoot the turn to final. I have tried different leg types after the outbound FC leg but with no joy. I have to put a lead in waypoint (I called it CI33 as in course intersept for 33....not proper convention I know but it does describe it) on the base turn so that it radius's in nicely.
The other thing I cant seem to get rid of either is that there is a tight circle over the NDB showing prior to going outbound from it. The autopilot does not track it but it does show up as magenta and it looks awful and I get the KK -> KK waypoint sequence showing on the GPS.
Finally is there any way to get the GPS to show distance to a decimal point instead of the whole mile? It is rather coarse for flying the inbound leg.
Here is a pic of the problem:

<Approach type="NDBDME" runway="33" suffix="0"
gpsOverlay="FALSE" designator="NONE" fixType="TERMINAL_WAYPOINT"
fixRegion="NZ" fixIdent="FF33" altitude="2000.00F"
heading="323.00" missedAltitude="3000.00F">
<ApproachLegs>
<Leg type="IF"
altitude1="2000.00F"
altitude2="0.00"
altitudeDescriptor="A"
theta="143.0"
rho="12962.963"
fixType="TERMINAL_WAYPOINT"
fixIdent="IF33"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="IF33"
recommendedRegion="NZ" />
<Leg type="TF"
altitude1="0.00"
altitude2="0.00"
theta="143.0000"
rho="12962.9630"
magneticCourse="323.00"
flyOver="YES"
fixType="NDB"
fixIdent="KK"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KK"
recommendedRegion="NZ" />
</ApproachLegs>

<Transition transitionType="FULL" fixType="NDB" fixRegion="NZ"
fixIdent="KK" altitude="3000.00F">
<TransitionLegs>
<Leg type="IF"
altitude1="3000.00F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="NDB"
fixIdent="KK"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KK"
recommendedRegion="NZ" />
<Leg type="FC"
altitude1="1500.00F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="105.00"
distance="7.0N"
flyOver="TRUE"
fixType="NDB"
fixIdent="KK"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KK"
recommendedRegion="NZ"/>
<Leg type="DF"
altitude1="1500.00F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.000"
rho="0.000"
flyOver="FALSE"
turnDirection="R"
fixType="TERMINAL_WAYPOINT"
fixIdent="CI33"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="CI33"
recommendedRegion="NZ"/>

</TransitionLegs>
</Transition>

I am not sure what the true functions and differences are of fixType versus recommendedType and fixIdent versus recommendedIdent.

Cheers
Steve

jvile · 29 Jul 2008

Those tight circles can be a pain in the rear to get rid of. You have 2 of them (Transition and missed approach). Two things cause them to appear.

1. The Distance or rho is too high a value
2. The heading (105) must be tweaked for the line draw to the FC leg turn.

However your vectors to final needs work on because it is missing some legs. Get that fixed first as per the following XML

<Approach type="NDBDME" runway="33" suffix="0"
gpsOverlay="FALSE" designator="NONE" fixType="TERMINAL_WAYPOINT"
fixRegion="NZ" fixIdent="FF33" altitude="2000.00F"
heading="323.00" missedAltitude="3000.00F">
<ApproachLegs>
<Leg type="IF"
altitude1="2000.00F"
altitude2="0.00"
altitudeDescriptor="A"
theta="143.0"
rho="12962.963"
fixType="TERMINAL_WAYPOINT"
fixIdent="IF33"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="IF33"
recommendedRegion="NZ" />

Need another TF here for the FF33

<Leg type="TF"
altitude1="0.00"
altitude2="0.00"
theta="143.0000"
rho="12962.9630"
magneticCourse="323.00"
flyOver="YES"
fixType="NDB"
fixIdent="KK"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KK"
recommendedRegion="NZ" />

need another TF for the runway data or MAP T_waypoint

</ApproachLegs>

The above is based on the NDB antenna is before the runway. I cannot see where the NDB is located in respect to the runway in your picture (zoom)

Once you get the Vectors to final sequenced then I can help work on the transition. Is this airport in the database so I can look at it?

MS can write an approach with missing legs but when we write the legs we have to follow the standard.

Header = Final App Fix (FAF)
IF = Initial App Fix (IAF)
TF = FAF
TF = NDB <<<<<<------- if the NDB is before the runway
TF = Runway <<<<------- or a MAP T_Waypoint
Missed approach data and NDB data if the NDB is after the runway

NDB and VOR are the hardest type approaches and Transitions to write. Many times it is best to write ILS, GPS, RNAV approaches with Transitions in order to learn the sequence then move on to NDB approaches with PI and FC legs.

cowpatz · 30 Jul 2008

Thanks again Jim. I didn't really want to put in the FF33 waypoint other than in the Approach header because I wanted the distance readout on the GPS to be to the MAP and not the FF33 point (more of a consideration in GPS/RNAV approaches). I did have it in but then took it out. I have still defined a FF33 waypoint though and this shows on the GPS plan view.
The MAP is the KK NDB and is the reason why it is coded as KK NDB and not MAP33. The threshold of the runway really has no application with this approach from what I can see.

This approach is the Cat C NDB/DME approach at Kerikeri (NZKK) in New Zealand and the chart is available here:
http://www.aip.net.nz/pdf/_aNZKK_44.3_44.4.pdf

I have attached the BGL file I have made below.

Cheers
Steve

cowpatz · 30 Jul 2008

Can an arc transition be made with a Co-sited NDB and DME or does the aid need to be a VOR?
Cheers
Steve

jvile · 30 Jul 2008

Thanks Steve

I understand now why you removed the FF33 and that will work. also if the NDB is the MAP you are correct in not using the runway as a IF legype statement.

I have never tried a arc except from a VOR. I would think any type Fix (NDB, Waypoint) would work but it might not.

I have the bgl you attached.

cowpatz · 30 Jul 2008

If the MAP is the NDB should I make it a T/waypoint? The CA leg seems to do funny things especially if I follow it with a VI leg afterwards (which never seems to want to intercept the next leg but just goes direct to the MA hold fix

Perplexing stuff.

jvile · 30 Jul 2008

Steve

It is hard to look at others work and understand the thought process of each designer. You may do things on purpose, by accident or for other reasons. When I look at other XML I have to be very careful and make sure I am not critizing the work that someone else is doing. It is also hard to know at what stage of the XML you are at and if certain areas are not complete by design or missing by accident it is hard to know.

I would like to point out a few things that you may or may not know so bare with me.

I notice there are many airports in your XML. If you have plans to work on these airports then they should be in their own XML file. I stripped out all your airports except NZKK and changed the airport header as follows

<?xml version="1.0" encoding="ISO-8859-1"?>
<FSData
version="9.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="bglcomp.xsd">
<Airport
country="New Zealand"
city="Kerikeri"
name="Kerikeri"
lat="-35.26277795434"
lon="173.911943882704"
alt="491.995F"
magvar="-18"
ident="NZKK" >

<DeleteAirport
deleteAllApproaches="TRUE"/>

<Approach
type="RNAV"
runway="15"
designator="NONE"

You do not need all those delete statements because FALSE is the default as per the SDK. In fact you don't need the one I left in place because there is no approach code in FS9 to begin with. I left the deleteAll blocking statement as nothing more the some insurance.

Like I said you may have plans for all those other airports so it is best to have a seperate bgl for each.

One of the main issues that is causing you problems with transitions is the missing vectors to final approach code. We have to create a foundation that all Transitions attach to and none of the approaches have a correct foundation.

When you open the GPS Receiver you must always have a vectors set of line draws. Example, the following is the NDBDME 33 vectors to final with a missed approach that looks like the approach plate

<Approach
type="NDBDME"
runway="33"
designator="NONE"
suffix="0"
gpsOverlay="FALSE"
fixType="TERMINAL_WAYPOINT"
fixRegion="NZ"
fixIdent="IF33"
altitude="2000.0F"
heading="341.50" <<<<<------- Must be a True Heading value
missedAltitude="3000.0F">
<ApproachLegs>
<Leg type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="NZ"
fixIdent="IF33"
recommendedType="NDB"
recommendedRegion="NZ"
recommendedIdent="KK"
theta="143"
rho="7.0N"
altitudeDescriptor="A"
altitude1="2000.0F" />
<Leg type="TF"
fixType="NDB"
fixRegion="NZ"
fixIdent="KK"
flyOver="TRUE"
recommendedType="NDB"
recommendedRegion="NZ"
recommendedIdent="KK"
theta="143"
rho="7.0N"
magneticCourse="323" />
</ApproachLegs>
<MissedApproachLegs>
<Leg type="CA"
magneticCourse="323.00"
altitudeDescriptor="+"
altitude1="1000.0F"/>
<Leg type="CA"
magneticCourse="323.00"
altitudeDescriptor="+"
altitude1="2000.0F"/>
<Leg type="DF"
fixType="NDB"
fixRegion="NZ"
fixIdent="KK"
flyOver="TRUE"
turnDirection="R"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="KK" />
<Leg type="HM"
fixType="NDB"
fixRegion="NZ"
fixIdent="KK"
turnDirection="L"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="KK"
magneticCourse="131.0"
time="1" />
</MissedApproachLegs>

If you are not going to use a FAF such as the FF33 then you must list the IAF twice as I have done above. The True heading is tweaked by .50 to the right of center line so any AI Plane will execute a missed approach to the right. In some XML tags we have to use True and is some areas we have to use Mag headings for the lines to draw correctly.

Once the vectors to final foundation is written then all Transitions must attach to that foundation. The last leg of any Transition must be the IAF leg of the vectors to final.

Another very critical area is placement of the T_Waypoints. There is not much room for error. I have to zoom the GPS reciever in the the lowext setting. In doing so I moved your IF33 slightly to the right to give an exact 323 heading to the NDB.

<Waypoint
lat="-35.37964"
lon="173.958124"
waypointType="UNNAMED"
magvar="-19"
waypointRegion="NZ"
waypointIdent="IF33">
</Waypoint>

If T_waypoints are not aligned and are offset just a half degree this causes many more problems when writting Transitions and getting lines to connect properly.

The RNAV 15 has no foundation vectors to final. This causes the Transitions to not be able to find the IAF.

The NDB 15 does not have a vectors to final. Now when you look at the Transition KK it looks like the line draw is fine but that is very misleading. 'Load', 'Activate' that Transition and you see what happens with the line draw that the dll file cannot process.

Some of this you may have on your list to work on. However, the T-waypoints must be positioned properly (IAF and FAF) then the foundation vectors to final written with a missed approach. Once you are sure that is sequenced (legtypes) correctly and all arrows draw in the correct direction then load and activate to be sure the dll processes the XML in the order it is written.

Now you write the Transitions always listing the last leg as the IAF that is in the vectors to final. That ties the Transition to the entrance of the vectors to final. Transitions cannot be a stand alone type line draw but must always attach back to the properly written vectors to final IAF T_waypoint.

Only then can you start to work with the radius of other type legs which is based on a Distance or rho of that leg. I can see why you are not getting some line draws because some transitions are ending at the T_waypoint before the IAF T_waypoint (NDBDME 33 KK transition)

If I could make a suggestion, I would remove all the Transitions and work on getting all the vectors to final processed correctly. Then I can assist in other issues you may have with the line draw problems of a Transitions. Right now I cannot be much help with Transitions until vectors to final are in place. Use my XML code above as a template for other type vectors to final if you are not going to use a FAF T_waypoint.

hope this is helpful

cowpatz · 31 Jul 2008

Jim I must apologise as I do not think that was the BGL file that I should have attached (a case of too many windows open....back and forth etc). You would be confused with that one! I have even being working on one approach that was for an adjacent airport, NZKT! A good reason to separate the airports.
I have now made up a BGL file just for NZKK and just the RNAV approaches. It reads as follows:

<FSData version="9.0" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd" >

<Airport ident="NZKK" name="Kerikeri"
lat="-35.262778" lon="173.911944"
magvar="-18.00" alt="491.995F"
city="Kerikeri"
country="New Zealand">

<DeleteAirport
deleteAllApproaches="TRUE"/>

<Approach type="RNAV" runway="15" suffix="0"
gpsOverlay="FALSE" designator="NONE" fixType="TERMINAL_WAYPOINT"
fixRegion="NZ" fixIdent="FF15" altitude="2100.00F"
heading="165.50" missedAltitude="3400.00F">
<ApproachLegs>
<Leg type="IF"
altitude1="3700.0F"
altitude2="0.00"
altitudeDescriptor="A"
theta="327.00"
rho="5.0N"
fixType="TERMINAL_WAYPOINT"
fixIdent="OTAHA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="FF15"
recommendedRegion="NZ" />
<Leg type="TF"
altitude1="2120.00F"
altitude2="0.00"
magneticCourse="147"
theta="327"
rho="5.0N"
fixType="TERMINAL_WAYPOINT"
fixIdent="FF15"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="FF15"
recommendedRegion="NZ"/>
<Leg type="TF"
altitude1="216.67"
altitude2="0.00"
magneticCourse="147"
theta="327"
rho="3.0N"
fixType="TERMINAL_WAYPOINT"
fixIdent="MA15"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="MA15"
recommendedRegion="NZ"/>
</ApproachLegs>
<MissedApproachLegs>
<Leg type="CA"
altitude1="1500.0F"
magneticCourse="147"
altitudeDescriptor="+" />
<Leg type="DF"
altitude1="1500.0F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="TRUE"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE" />
<Leg type="HM"
altitude1="3400.0F"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="327"
time="1.00"
turnDirection="R"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE"
recommendedRegion="NZ" />
</MissedApproachLegs>
<Transition transitionType="FULL" fixType="TERMINAL_WAYPOINT" fixRegion="NZ"
fixIdent="KAROA" altitude="1127.27">
<TransitionLegs>
<Leg type="IF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="TERMINAL_WAYPOINT"
fixIdent="KAROA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="KAROA" />
<Leg type="DF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="YES"
fixType="TERMINAL_WAYPOINT"
fixIdent="OTAHA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OTAHA" />
</TransitionLegs>
</Transition>
<Transition transitionType="FULL" fixType="NDB" fixRegion="NZ"
fixIdent="KK" altitude="2600.0F">
<TransitionLegs>
<Leg type="IF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="NDB"
fixIdent="KK"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KK" />
<Leg type="DF"
altitude1="2600.0F"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="TRUE"
fixType="TERMINAL_WAYPOINT"
fixIdent="OTAHA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OTAHA" />
<Leg type="HF"
altitude1="2600.0F"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="147"
time="1.00"
turnDirection="R"
fixType="TERMINAL_WAYPOINT"
fixIdent="OTAHA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OTAHA" />
</TransitionLegs>
</Transition>
</Approach>


<Approach type="RNAV" runway="33" suffix="0"
gpsOverlay="FALSE" designator="NONE" fixType="TERMINAL_WAYPOINT"
fixRegion="NZ" fixIdent="FF33" altitude="2000.0F"
heading="346.00" missedAltitude="2600.0F">
<ApproachLegs>
<Leg type="IF"
altitude1="1127.70"
altitude2="0.00"
altitudeDescriptor="A"
theta="0.0000"
rho="0.0000"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE"
recommendedRegion="NZ" />
<Leg type="TF"
altitude1="3500.0F"
altitude2="0.00"
theta="147"
rho="5.0N"
magneticCourse="327"
fixType="TERMINAL_WAYPOINT"
fixIdent="FF33"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="FF33"
recommendedRegion="NZ" />
<Leg type="TF"
altitude1="2000.0F"
altitude2="0.00"
theta="147"
rho="4.5N"
magneticCourse="327"
flyOver="TRUE"
turnDirection="E"
fixType="TERMINAL_WAYPOINT"
fixIdent="MA33"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="MA33" />
</ApproachLegs>
<MissedApproachLegs>
<Leg type="CA"
altitude1="1500.0F"
altitudeDescriptor="+"
magneticCourse="327"/>
<Leg type="DF"
altitude1="2600.0F"
altitude2="0.00"
theta="0.0000"
rho="0.0000"
flyOver="TRUE"
fixType="TERMINAL_WAYPOINT"
fixIdent="OTAHA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OTAHA"
recommendedRegion="NZ" />
<Leg type="HM"
altitude1="2600.0F"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="147"
time="1.00"
turnDirection="R"
fixType="TERMINAL_WAYPOINT"
fixIdent="OTAHA"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OTAHA"
recommendedRegion="NZ" />
</MissedApproachLegs>
<Transition transitionType="FULL" fixType="TERMINAL_WAYPOINT" fixRegion="NZ"
fixIdent="KK" altitude="3400.0F">
<TransitionLegs>
<Leg type="IF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="NDB"
fixIdent="KK"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="KK"
recommendedRegion="NZ" />
<Leg type="DF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="YES"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE"
recommendedRegion="NZ" />
<Leg type="HF"
altitude1="3400.0F"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
magneticCourse="327"
time="1.00"
turnDirection="R"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE"
recommendedRegion="NZ" />
</TransitionLegs>
</Transition>
<Transition transitionType="FULL" fixType="TERMINAL_WAYPOINT" fixRegion="NZ"
fixIdent="MARLO" altitude="1127.27">
<TransitionLegs>
<Leg type="IF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="TERMINAL_WAYPOINT"
fixIdent="MARLO"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="MARLO"
recommendedRegion="NZ" />
<Leg type="DF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="YES"
turnDirection="E"
fixType="TERMINAL_WAYPOINT"
fixIdent="MARLO"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="MARLO" />
<Leg type="DF"
altitude1="787.88"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="FALSE"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE"
recommendedRegion="NZ" />
</TransitionLegs>
</Transition>
<Transition transitionType="FULL" fixType="TERMINAL_WAYPOINT" fixRegion="NZ"
fixIdent="NOBIS" altitude="1127.27">
<TransitionLegs>
<Leg type="IF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
fixType="TERMINAL_WAYPOINT"
fixIdent="NOBIS"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="NOBIS"
recommendedRegion="NZ" />
<Leg type="DF"
altitude1="0.00"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="YES"
turnDirection="E"
fixType="TERMINAL_WAYPOINT"
fixIdent="NOBIS"
fixRegion="NZ"
recommendedType="NDB"
recommendedIdent="NOBIS" />
<Leg type="DF"
altitude1="787.88"
altitude2="0.00"
altitudeDescriptor="+"
theta="0.0000"
rho="0.0000"
flyOver="FALSE"
fixType="TERMINAL_WAYPOINT"
fixIdent="OPARE"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="OPARE"
recommendedRegion="NZ" />
</TransitionLegs>
</Transition>
</Approach>


<Waypoint lat="-35.090833" lon="173.860000" waypointType="NAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="OTAHA" />


<Waypoint lat="-35.159722" lon="173.616110" waypointType="NAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="KAROA" />

<Waypoint lat="-35.424444" lon="173.96444" waypointType="NAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="OPARE" />


<Waypoint lat="-35.550556" lon="174.11639" waypointType="NAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="MARLO" />

<Waypoint lat="-35.570278" lon="174.067500" waypointType="NAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="NOBIS" />


<Waypoint lat="-35.171167" lon="173.883330" waypointType="UNNAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="FF15" />


<Waypoint lat="-35.243333" lon="173.906500" waypointType="UNNAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="MA15" />


<Waypoint lat="-35.355333" lon="173.942000" waypointType="UNNAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="FF33" />

<Waypoint lat="-35.281667" lon="173.91833" waypointType="UNNAMED"
magvar="-18.00" waypointRegion="NZ" waypointIdent="MA33" />

</Airport>
</FSData>

All vectors to final work as well as the transitions. I have not tested it with AI. The CA legs I put in just to see if it works as this M/APP is just straight ahead.....I'm not sure how it works but it never seems to perform for me.
I notice on the NDB approach in your last post you have 2 CA legs in the Missed approach legs. Any particular reason for this as they both seem to be on the same course?
Many thanks for your help Jim.

Approach Code

cowpatz

scruffyduck

Administrator

cowpatz

scruffyduck

Administrator

jvile

tyrant

cowpatz

jvile

jvile

jvile

cowpatz

jvile

cowpatz

jvile

cowpatz

Attachments

cowpatz

jvile

cowpatz

jvile

cowpatz