Which AFCAD?

[cowpatz]

In my quest to add GPS approaches to some New Zealand airfields I have struck a number of problems, most of which have been resolved thanks to this forum. One issue I currently have is that different sceneries have different runway positions. Not such a biggy for NDB or VOR approaches as they are not runway dependent. RNAV approaches on the other hand are.
Is there a rule of thumb as to which scenery to use? Should the approaches be specified for use with a particular scenery only or is there another cunning way to deal with this?
Checking some of the various runway positionings, via google earth, has revealed that quite a few are not in the correct position and of course altering them causes other issues.
Cheers
Steve

 

[scruffyduck]

In my quest to add GPS approaches to some New Zealand airfields I have struck a number of problems, most of which have been resolved thanks to this forum. One issue I currently have is that different sceneries have different runway positions. Not such a biggy for NDB or VOR approaches as they are not runway dependent. RNAV approaches on the other hand are.
Is there a rule of thumb as to which scenery to use? Should the approaches be specified for use with a particular scenery only or is there another cunning way to deal with this?
Checking some of the various runway positionings, via google earth, has revealed that quite a few are not in the correct position and of course altering them causes other issues.
Cheers
Steve

OK this seems an obvious thing to say but there should be a real world position for a runway. Any approach that relies on the final runway position (seems important to me) needs to know where that rumway is. If different sceneries have the runway in different places then we have a problem. The approach code needs to match the runway location.

 

[cowpatz]

Yes Jon the problem seems to be from earlier scenery designs or default FS9 runways being in the wrong position. If I realign the runways to their correct position it stuffs up the taxiways and other scenery (like putting an NDB in the middle of a taxiway!). A lot seems to be dependent on how the AFCAD has been incorporated within the scenery package. With one airfield at the moment I can change the AFCAD to the correct runway positions but when I place the aircraft on the runway threshold it does not tie in with the AFCAD position. What is determining the visual position?
Thanks
Steve

 

[scruffyduck]

Yes Jon the problem seems to be from earlier scenery designs or default FS9 runways being in the wrong position. If I realign the runways to their correct position it stuffs up the taxiways and other scenery (like putting an NDB in the middle of a taxiway!). A lot seems to be dependent on how the AFCAD has been incorporated within the scenery package. With one airfield at the moment I can change the AFCAD to the correct runway positions but when I place the aircraft on the runway threshold it does not tie in with the AFCAD position. What is determining the visual position?
Thanks
Steve

I assume that if you move the runways in AFCAD you are also moving the associated taxiways? You can move the NDB in AFCAD by dragging it if necessary - should work. Also you need to move the runway starts to match up with your new runway locations. All that can be done in AFCAD. You then need to re-adjust approaches which can't be done in AFCAD. The start positions of aircraft are determined by the Start elements. If you have not adjuected these then you will need to

 

[cowpatz]

Yes I have moved the runways in AFCAD but they have not moved when flying the aircraft. The NDB's etc have been moved etc.
One scenery has the runway position well out and need everything else moving too! I am OK with AFCAD but moving buildings etc is a different language altogether and something I will learn later.
Steve

 

[scruffyduck]

Yes I have moved the runways in AFCAD but they have not moved when flying the aircraft. The NDB's etc have been moved etc.
One scenery has the runway position well out and need everything else moving too! I am OK with AFCAD but moving buildings etc is a different language altogether and something I will learn later.
Steve

Did you move the start locations for the runway?

 

[jvile]

Steve

You have now entered the world of visual scenery vs the unseen scenery for both FS9 and FSX.

Several of us namely Reggie and myself have ask scenery designers to use a standard of some sort but it goes back to they do what they think is right for them.

You are at a crossroad and must decide what will work the best. You could make a set of T_Waypoints for every airport released. You could go with the most popular airport and then in a uplaoded readme tell everyone which scenery your approach code is for. You could do your own airport scenery too match your approach code.

These problems are not new and continue even today with highend payware that only address the visual aspects of the airport and not the corruption introduced to the approach portion.

Some scenery designers are now turning the corner and asking for help with proper approach code when they move a runway a small amount, change the True Heading by a degree or 2, require a offset approach, renumber runways, etc. But then again there are both low end and high end payware being released right now that does not address the destorted approach code introduced when purchasing their airport.

In most cases I say leave the runway alone and do not move it. Even when you overlay a runway to Google Earth Plus it is not always perfect in position. Moving a runway a small amount will cause other problems.

It appears that Jeppesen does not have a set of published approach plates for most of the New Zealand Airports. FSX did not get any approach codes added just like FS9 and we have to build them ourselfs. I have run into this problem in the past where the Goverment issues the approach plates such as Argentina and Jeppesen does not have access to them. If Jeppesen cannot get the approach plates then the approach code is not pushed into FS prior to release. Factor in different scenery designers that felt the need to move runways and you are starting to see the problems.

Yes I have moved the runways in AFCAD but they have not moved when flying the aircraft.

Those airport scenery's have their own runway texture designed and cannot be moved with AFCAD. AFCAD can only move default FS9 runways. Only the scenery designer would have the ability to move the runway within his bgl and the tool he used to lay the runway down with.

 

[cowpatz]

Thanks Jim and Jon for your explanations and assistance. A lot of provincial airports within NZ are now being equipped with GPS approaches and I was hoping to produce a freeware GPS approach package for the local sim community and if OK then a wider release via AVSIM etc. I dont have all the scenery packages so that raises an issue and the other is using charted positions versus positions from within FS9. This can cause the final approach path to be out of alignment with the runway unless I change the co-ordinates of the IF point to be in alignment. The problem here is when using an INS such as CIVA or an FMC whereby the chart entered lats/longs will be in disagreement with my moved IF point. It also distorts the transitions unless all the IAF points are moved a corresponding amount. I guess this is something that I will have to find a way around.

On a different matter I am a little dismayed at the poor attempt the autopilot makes when entering holding patterns.
The direct entry is not good as it leads the turn and has to swing out again to pick up the curve. The offset entry was hopeless so I have fixed that with IP legs to create the offset. The parallel entry however seems to totally confuse it with it not being unusual to even turn the wrong way! I have attached a PDF of the one I am having probs with at the moment at Nelson (NZNS) with the missed approach holding pattern on the BRAVO approach as well as a BGL file I created for Nelson. Another issue is this approach is not runway specfic. It is just called Bravo. There appears to be no facility to call it just Bravo as there needs to be a runway entry and all I can do is add a single letter suffix. As this approach would probably be used for runway 20 most of the time I have called it RNAV20-B.
Do you have a method of improving the parallel entry into a holding pattern? I can see some upset controllers on VATSIM otherwise!
Cheers
Steve

 

[jvile]

Steve

The parallel entry however seems to totally confuse it with it not being unusual to even turn the wrong way!

You cannot use the TASMN as the go to Waypoint for a parallel entry. You have to make a fake T_Waypoint looking at the .pdf in the lower right or left corner of TASMN and then attach the PI in series from that point back to the TASMN entrance to hold.

FS will go into hold sometimes and skip other legs defined. Be sure you place a T_waypoint far enough away from TASMN so the User Plane GPS line draw sees the TF, PI, TF legs before the hold leg.

Holding patterns must be flown at less the 220 kts per FAA. I use 180 Kts IAS but we have to live with the over banking that you see when coupled to the autopilot. I normally uncouple the autopilot in the turns and hand fly the hold.

 

[cowpatz]

Thanks Jim,
I have attached the correct BGL file if you used it you would have been confused. I put an earlier one on by mistake.

 

[cowpatz]

Can anyone tell me why I have true tracks showing on the GPS instead of magnetic? It still says degrees magnetic but the tracks are actually true values. The airport header has the correct variation as do the waypoints. I have no delete statements in the code if that makes any difference.
Rgds
Steve

 

[jvile]

Most of the track data will be the mag heading which is in the XML. However one of the headings is alway True which looks out of place but it is not.

If memory serves me correct it is the track that is to the runway from the last T_Waypoint.

 

[cowpatz]

I think I know what you mean but all of them are indicating the true track value but have an M after the trk. For example the required track might be 040 mag but it is showing as 066 M with a variation of E22. The aircraft still flys the mag course.
Rgds
Steve

 

[jvile]

The M shows after any heading in the load screen of the GPS. You keep using a lot of DF leg types which is a present position to a fix. That legtype does not require a magcourse tag to compile so the GPS calculates it as a True heading even though the M is always present.

You will notice that the TF and CF has a magcourse tag in the XML and if that exist then the GPS uses its heading on the load screen.

It is best to use as many TF or CF legtypes when going from a waypoint to a waypoint (ILS, RNAV, GPS, missed approach, etc) so the mag heading will display correctly in the GPS load window.

 

[cowpatz]

The M shows after any heading in the load screen of the GPS. You keep using a lot of DF leg types which is a present position to a fix. That legtype does not require a magcourse tag to compile so the GPS calculates it as a True heading even though the M is always present.

You will notice that the TF and CF has a magcourse tag in the XML and if that exist then the GPS uses its heading on the load screen.

It is best to use as many TF or CF legtypes when going from a waypoint to a waypoint (ILS, RNAV, GPS, missed approach, etc) so the mag heading will display correctly in the GPS load window.

Where possible I will use the TF and CF legs but in some cases I prefer the radius offered by DF leg. i.e. like a base turn. I have used a DF leg in the holding parallel entry after the created T_point at the end of the parallel leg (as you suggested) before the turn back to the fix. I found the the TF just gave a sharp line back to the fix and the PI leg would not work as the turn would be the wrong way to the hold or the T_point would have to be well outside the holding protection area to be effective. The appearance on the GPS is more representative of the approach chart and therefore probably easier for the user to follow.
Cheers

 

[jvile]

Where possible I will use the TF and CF legs but in some cases I prefer the radius offered by DF leg. i.e. like a base turn.

I understand having a nice looking radius by using the course to a fix but once you are in a straight line T_waypoint to T_waypoint the CF works which will also give you a Mag heading in the 'Load' window of the GPS. The GPS Mag heading is not a calculation but whatever you use in the CF/TF Legtype MagCourse as a value.

I am not sure I follow the problem with the entrance to a hold using the parallel scheme. Sometimes both MS and myself has many fake T_Waypoints as needed to get the line to draw properly. It does not matter how many fake T_waypoints you add to accomplish the correct line draw. The User Plane does not care about the T_Waypoints but only the line that was made from the T_waypoints.

I will work on and show how I use the parallel entrance to a hold in the next day or so.

 

[cowpatz]

Is there a way to have T points but not have an ident for them show on the GPS? In otherwords invisible waypoints (to the user).Wherever possible I try to keep the points the same as those on the chart.

Here is the hold in question.

This is the code for it:

<MissedApproachLegs>
<Leg type="DF"
altitude1="1850.00F"
altitudeDescriptor="A"
theta="0.00"
rho="0.00"
flyOver="FALSE"
fixType="TERMINAL_WAYPOINT"
fixIdent="DUMMY"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="DUMMY"
recommendedRegion="NZ" />

<Leg type="TF"
altitude1="4000.00F"
altitudeDescriptor="A"
theta="0.00"
rho="0.00"
magneticCourse="068"
fixType="TERMINAL_WAYPOINT"
fixIdent="TASMN"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="TASMN"
recommendedRegion="NZ" />
<Leg type="DF"
altitude1="4000.00F"
altitudeDescriptor="A"
theta="0.00"
rho="0.00"
flyOver="FALSE"
turnDirection="L"
fixType="TERMINAL_WAYPOINT"
fixIdent="TAS1"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="TAS1"
recommendedRegion="NZ" />

<Leg type="DF"
altitude1="4000.00F"
altitudeDescriptor="A"
theta="0.00"
rho="0.00"
flyOver="FALSE"
fixType="TERMINAL_WAYPOINT"
fixIdent="TASMN"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="TASMN"
recommendedRegion="NZ" />
<Leg type="HM"
altitude1="0.00"
theta="0.00"
rho="0.00"
magneticCourse="180"
time="1.0"
turnDirection="R"
fixType="TERMINAL_WAYPOINT"
fixIdent="TASMN"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="TASMN"
recommendedRegion="NZ" />
</MissedApproachLegs>


Thanks Steve

 

[jvile]

Is there a way to have T points but not have an ident for them show on the GPS? In otherwords invisible waypoints (to the user).Wherever possible I try to keep the points the same as those on the chart.

In a simple word, No

FS adds a lot of fake T_waypoints to get a line drawn correctly that are not charted. When you do this set them as Unnamed if you do not use a word. I set all my fake T_waypoints with a unique letter/number so I recognize them as added T_waypoints.

Can you list your vector to final code? I would like to work with that and draw a parallel entry.

 

[cowpatz]

In a simple word, No

FS adds a lot of fake T_waypoints to get a line drawn correctly that are not charted. When you do this set them as Unnamed if you do not use a word. I set all my fake T_waypoints with a unique letter/number so I recognize them as added T_waypoints.

Can you list your vector to final code? I would like to work with that and draw a parallel entry.

I guess I am conditioned by my real world flying to checking that the displayed waypoints correspond to the charted points and this is what I am essentially trying to achieve with my approach constructs. The SDK is very slight on detail as to how to construct the code and nothing at all on the theory behind it. I have trawled the forums and learnt a lot, however some of it is specific to a localised problem. I realise that FS9 has limitations so a compromise is needed. I could draw in a whole series of T points for a really nice parallel entry but it would be difficult to check from another users perspective or the track would go well outside the holding area. I guess really I am trying to learn how the various legs interact with one another and so gain a better understanding.
Here is the vectors to final and approach code:

<Approach type="RNAV" runway="20" suffix="B"
gpsOverlay="FALSE" designator="NONE" fixType="TERMINAL_WAYPOINT"
fixRegion="NZ" fixIdent="FAF20" altitude="1700.00F"
heading="200.0" missedAltitude="2200.00F">
<ApproachLegs>
<Leg type="IF"
altitude1="2200.00F"
altitude2="0.00"
altitudeDescriptor="A"
theta="220.0000"
rho="7.0N"
fixType="TERMINAL_WAYPOINT"
fixIdent="TASMN"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="TASMN"
recommendedRegion="NZ" />
<Leg type="TF"
altitude1="2200.00F"
altitude2="0.00"
altitudeDescriptor="A"
theta="00.000"
rho="0.00"
magneticCourse="180"
fixType="TERMINAL_WAYPOINT"
fixIdent="FAF20"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="FAF20"
recommendedRegion="NZ" />
<Leg type="TF"
altitude1="1850.00F"
altitude2="0.00"
altitudeDescriptor="A"
theta="00.000"
rho="0.00"
magneticCourse="180"
fixType="TERMINAL_WAYPOINT"
fixIdent="MAP20"
fixRegion="NZ"
recommendedType="TERMINAL_WAYPOINT"
recommendedIdent="MAP20"
recommendedRegion="NZ" />

Many thanks
Steve

 

[jvile]

Steve

Can I get the associated T_waypoints you placed for both vectors to final and the hold?