Automated SID Entry Causing Incorrect Flight

[mbchatter 3]

KLAX SID VTU7 requires takeoff from RWY 25R to climb to 3,00 Ft on hdg 251 to the SMO 154 Radial, then dct VTU.  (VR,0,SMO,154.0.3,000,251.0) (VM 251.0) (DF VTU).  Left MCD automated entry results in "154", then "Manual", then "VTU", causing the aircraft to pass the 154 SMO Radial without further action to turn toward VTU.  I recognize that the pilot is to turn ("Manual") when reaching or passing 3,000 feet at, or beyond, the 154 SMO radial, but there is no method to determine reaching, or passing, that radial, unless I am missing a setting.  I have created a setting in the VOR section for SMO and the 154 Radial, but the display for the SMO VOR is too small to observe with Departure radio traffic, altitude observance, etc.  Any suggestions would be appreciated.

[mbchatter 3]

The reason for this error is that the automated entry "154" apparently refers not to a VOR radial, but a waypoint hundreds of miles distant.  Therefore, I have deleted this entry in the MCDU and am manually flying the runway heading to an altitude of 3,000 feet until reaching the approximate SMO 154 radial (by setting both #1 and #2 VOR's) to the inbound heading of 334 and watching the display reach that approximate setting and turning toward VTU and finishing my Departure directed climb to 15,000 feet.  Seems to work OK, when it could be done by the autopilot, with a correct radial setting.  Any other suggestions would be appreciated.  John

[mbchatter 3]

The A320 is a fly-by-wire aircraft and is kind of bothersome to fly manually, requiring to pause the aircraft upon reaching the SMO 154 radial and setting "direct to" VTU, then un-pausing to continue the flight.  This is not normal for an A320.

[mbchatter 3]

As no one has a better solution yet, I am offering this workaround that actually works:  Using Jon Masterson's ADE, in KLAX, I ran a 154 radial from SMO past the extension of RWY 07L (the far end of RWY 25R), then ran an elongated line from RWY 25R across the 154 SMO radial to locate a center point onto which to center a new "Waypoint" (gathering the coordinates).  In FSX's BGL Compiler, I created the new waypoint, naming it R1540 and added this new waypoint into Navigraph's Waypoint list, to cause the MCDU to recognize it.  In FSX's Flight Planner, I re-routed my flight plan's SID through this new waypoint by name.  In the MCDU, I deleted both the automated entries "154" and "Manual" and replaced these with the new waypoint and setting a 3,000 foot altitude limitation.  On autopilot, the aircraft negotiates a "fly-by-wire" ascent to the SMO 154 radial at 3,000 feet, then turns toward VTU, continuing on course through the SID and beyond to KFSO, as it should.  Somehow, the MCDU should be able to distinguish radials from waypoints, as SID's will continue to be published with radial acquisition.  If I missed an easier method, please advise.  John

[skelsey 103]

The SID you refer to is a radar vectored departure. Therefore the route is not, as you suggest, direct VTU after the SMO 154 radial: rather ATC will issue you headings and altitudes to fly and eventually send you to VTU. This is reflected in the coding of the departure in the nav database, because automatically flying direct VTU after the SMO 154 radial is exactly what ATC do not expect you to do!

 

The only restriction is that you must not climb above 3000 ft until you are beyond the SMO 156 radial. I would be very surprised if this was not what was coded in the nav database (156 being a point on the 156 radial with a restriction of -3000) but I have not ever flown that departure so I cannot say for certain. 

 

You can quite easily use the FIX INFO page to enter SMO as a fix and enter the 154 radial to draw this on the ND: you can also back up with raw data and the RMI needles as you have done.

 

In any case I am slightly surprised at your struggle: all that is required to get the aeroplane flying to VTU at any point is two button clicks in the MCDU: DIR then select VTU and ensure NAV is annunciated in green on the FMA (push the knob for managed NAV if you need to). Certainly seems a lot easier than the lengths you have gone to?

[DaveCT2003 2553]

46 minutes ago, mbchatter said:

As no one has a better solution yet, I am offering this workaround that actually works:  Using Jon Masterson's ADE, in KLAX, I ran a 154 radial from SMO past the extension of RWY 07L (the far end of RWY 25R), then ran an elongated line from RWY 25R across the 154 SMO radial to locate a center point onto which to center a new "Waypoint" (gathering the coordinates).  In FSX's BGL Compiler, I created the new waypoint, naming it R1540 and added this new waypoint into Navigraph's Waypoint list, to cause the MCDU to recognize it.  In FSX's Flight Planner, I re-routed my flight plan's SID through this new waypoint by name.  In the MCDU, I deleted both the automated entries "154" and "Manual" and replaced these with the new waypoint and setting a 3,000 foot altitude limitation.  On autopilot, the aircraft negotiates a "fly-by-wire" ascent to the SMO 154 radial at 3,000 feet, then turns toward VTU, continuing on course through the SID and beyond to KFSO, as it should.  Somehow, the MCDU should be able to distinguish radials from waypoints, as SID's will continue to be published with radial acquisition.  If I missed an easier method, please advise.  John

 

Simon is correct, this is a Radar Vectored departure, however pilots are required to fly 251 degrees, below 3000 ft until passing the Ventrua VOR Radial 154. You can assume you have to fly this unless ATC intervenes.

 

I believe the NGX will put this into the FMS for you (I know it's one of the airliners), but I'm not sure if the Airbus should - either in real life for the Aerosoft Airbus.  I'll ask one of our bus drivers to check this in the aircraft.  With that said, it's very possible that this capability would exist in one aircraft type and not another, but i don't know how it applies to the Aerosoft or real world bus (again, I'll find out).

 

Best wishes.

 

 

[mbchatter 3]

Thanks for the reply skelsey.  "type=DF" Direct to a Fix or DF Leg."  Besides, the problem is the erroneous automated entry "154" in the MCDU in response to the SID: 

SID,VTU7,25R,1
VR,0,SMO,154.0,251.0,3,3000
VM,0,0,0,251.0
DF,VTU,34.115058,-119.049492

Since ATC is not providing radar assist in this FSX flight, the entry observed in the MCDU was surprising.    I have flown this SID.  With ATC instructions, one simply turns the dials for heading and altitude in a manual flight until the autopilot can be engaged.  Thanks again for your input.  John

 

And of course, DAVE, you are always helpful.  John

[mbchatter 3]

skelsey and DAVE, It just dawned on me that you BOTH are missing the actual point of this post.  It has nothing to do with how to FLY this SID, (Radar Vectored and ATC directed) but rather that the MCDU is misinterpreting a "RADIAL" in this SID for a "WAYPOINT".  Entering a flight into the MCDU as "KLAX/KSFO" then selecting KLAX and DEPARTURE and RWY 25R and VTU7 as the SID and RZS as the Transition, the MCDU's resulting display of  "154" and "MANUAL", occurs by the MCDU having misinterpreted the SID's "RADIAL" as a "WAYPOINT" some 600 nm away, which should not happen (Period).  An unsuspecting simmer, not realizing this error, would try to fly this programmed flight and try to figure out why the aircraft is heading 600 nm in the wrong direction, since there are no "ATC vectoring directions" provided in FSX.

[Mladen 55]

Hello! 

The thing is that the current MCDU does not recognize all ARINC 424 leg types which are used to construct SIDs and STARs. Most of ARINC legs are simplified or substituted with similar legs and this often gives totally wrong presentation of some SIDs and STARs. I hope the NEW Bus will be more ARINC 424 compliant. For this reason I suggest to fly such SIDs and STARs according to Charts using Selected modes (heading, speed, vertical speed, use VORs and NDBs for navigation)

You can get some idea of ARINC 424 Procedural Leg Types here:  http://www.uasc.com/docs/default-source/documents/service-bulletin/3039sv60x-70x.pdf?sfvrsn=b9d6f53_2

[mbchatter 3]

Mladen:  Thanks for the reply.  It makes some sort of sense now.  What I was reporting occurred for the last 3 days, showing "154" to be 666 nm distant.  Today, after all of this fuss, I entered the exact same data and "154" now displayed as 3 nm distant (as before), which is correct.  I restarted and could not replicate the initial error.  My IRAC is current.  It must have been some type of computer glitch at my end.  This problem never occurred prior.  Sorry for all the conversation, if this actually was just a glitch.  If it occurs again, I will post.  Out of old habit, I always fly (now sim) this route, no longer for active pay though and now in an A320  "fly-by-wire" and "turn knobs" (you are supposed to only touch these knobs in flight when directed by ATC) lazy "wear out your fingertips" bus driving. <grin>.  I even have a female Second Officer now <smile>.  John 

 

Dave:  Please mark this solved for now.  John

[DaveCT2003 2553]

12 hours ago, mbchatter said:

It just dawned on me that you BOTH are missing the actual point of this post.

 

Nope. You missed what I said in my post.

 

[mbchatter 3]

Folks:  My original post referred to an apparent glitch, for 3 days in a row, in that the MCDU, when programmed with SID VTU8 (my AIRAC is current), displayed a 666 nm distant "apparent Waypoint", instead of the actual 3 nm distant SMO radial "154", whose cause was most probably explained by Mladen, in his post above, relating to errors in the MCDU.  This "glitch" has since corrected itself by, as of yesterday, displaying the actual 3 nm distant radial.

 

Then, somehow, the conversation changed into how the SID, with radar vectors, was to be flown (in real life), the procedure with which I was, and am still, extremely familiar as a (for years) certificated, but now retired, real life instrument rated commercial pilot and First Officer, instead of my suggestion as to how it could be flown, lacking actual ATC control (radar vectors) in an FSX environment, without such.

 

I was discussing "simming" here, mainly without real and active ATC, and the actual currently published SID is VTU8, not, as I posted in error as "VTU7" (even though there are no actual changes in the SID).   I thank you all for your interest, but I feel that there is nothing more to discuss, as the initial problem has corrected itself and this is still "simming"!  John