When the first waypoint is an airport or runway

[Will]

Whenever the first waypoint is an airport or a runway, I'm always worried about it not sequencing properly after takeoff. And I just found a scenario that confirms my fears.

Position the aircraft for departure on VHHH runway 07R. Load the RASS1E departure, select 07R as the runway and EXEC. Using the Aerosoft 2105 NavData, you'll see the first waypoint is RW07R.

Perform a standard takeoff with LNAV armed. The waypoint RW07R won't sequence, LNAV won't engage, and climbing through about 500' on departure, you see NOT ON INTERCEPT HEADING.

The whole situation can be fixed by just down-selecting the second waypoint (PORPA) and up-selecting it to 1L. The flight profile is exactly the same (as far as I can tell), but LNAV engages at 50' AGL as it should.

So I'm curious about real-world ops. How often is the airport or the departure runway the first waypoint? Does it ever fail to sequence? If you see it as the first waypoint, would you ever delete it and make the second waypoint into the first? Thoughts?

Thanks.

[Britjet]

Will,

I've never seen what you describe for real. It would be unsafe. I'm afraid I can't remember what the first waypoint usually is, though, and it isn't normally checked as such. I vaguely remember it being a track.
Certainly just putting PORPA as the first waypoint would not be sufficient - the aircraft wouldn't track correctly.
It seems to me that RW07R is behind you as you start the take-off, so of course it wouldn't cycle correctly.

Peter

[Will]

Peter, the runway waypoint appears to be 0.1 nm ahead of the aircraft at the beginning of the takeoff roll. I was guessing it doesn't sequence because LNAV is only armed at that point (TOGA is active). By the time LNAV would engage, the runway waypoint is then well behind the aircraft.

But putting the second waypoint in the 1L position doesn't seem to change the track... according to the ND, it's still a departure that's straight ahead (runway heading) until PORPA.

Curious if you have more thoughts about this.

[dhob]

The departure runway should not be a waypoint on the legs page. In the case of VHHH, the NDB uses the runway from the selection on the DEP/ARR page. From that, it builds a course intercept to PORPA. PORPA is the active waypoint on the LEGS page, and is also displayed on the ND it the upper right corner as the active waypoint.

In the US, at some airports when cleared for takeoff, ATC will include the first fix of the RNAV departure:
"Delta 345 RNAV to MPASS, Runway26L, cleared for takeoff."

Our verification is to check the waypoint in the ATC clearance, is the active waypoint in the FMC (upper right on the ND).

[Will]

See above for what I'm seeing on the ND. See below for what I'm seeing on the LEGS page.



Unless I'm mistaken, the arrival end of the departure runway (07R) is the first waypoint. The waypoint is 0.1 NM ahead of the aircraft at the beginning of the takeoff roll; by the time of this screenshot it's already 0.1 NM behind the aircraft.

The navigation database in question is the Aerosoft 2105 NavData set.

If this is in error, and no real-world departure procedure would include an initial waypoint like this, then that's good information to know. If that's the case then I guess I can't ask "how would you handle this?" because the answer would be "we never see anything like this." Is that correct?

[dhob]

Yes, the depiction included is not correct. PORPA should be at 1L, with a 074 course above the fix. PORPA would also be displayed on the ND in magenta as well, with the applicable distance to PORPA. The airplane FMC, whether a departure is selected for not, will not include the runway on the LEGS page.

[Will]

Thanks. In the simulator world, this is trivial to fix: just down-select PORPA, and up-select it to 1L. That leaves the departure route intact, but without the problem of the non-sequencing initial waypoint.

As for real-world ops, I'll just assume this doesn't happen.

I'll also assume this is an issue with the way Aerosoft packages their navdata.

Thanks for your input.

[Hardy Heinlin]

It's not Aerosoft's fault, it's in Lido's ARINC master file which Aerosoft uses in Navburo. Some SIDs in Lido's master file have a runway as the initial fix, followed by a track-to-fix (e.g. PORPA). I don't know why they make this exception. In Navblue's database, however, it starts with PORPA as a course-to-fix. There's nothing to intercept anyway as the runway is already on the target course.

If this problem is consistent, I could implement a filter that eliminates the runway when the SID is being loaded.


|-|

[Will]

Thanks for the clarification, Hardy.

I wouldn't say this is common, but I could only guess what that means in terms of real incidence. Common enough that it's crossed my mind before, but not common enough to see frequently.

[Hardy Heinlin]

Whenever the first waypoint is an airport or a runway ...

Can you give me an example of an airport waypoint?


|-|ardy

[Will]

I seem to remember that you see KORD as a waypoint on at least one of the departures from O'Hare, but I'm not able to test it at the moment. I can look at it tonight.

[Will]

Hardy, the only KORD departure doesn't list the airport as a fix, so I misremembered that, but there's another issue with it. The SID is O'HARE6 departure, and it's a VECTOR departure: "All aircraft EXPECT RADAR vectors to the first enroute NAVAID/fix." Except that it shows up with the first (and only) FMC waypoint as being the CGO VOR, which is located on the field. And there is no VECTORS leg, so following the FMC brings you right back over the airport and then direct on course.

I would expect a vectors leg as the first and only leg, although without other anchors maybe that doesn't make sense. For that matter, maybe there's no point in having a VECTORS departure in the FMC anyway, since it's nothing but vectors...

[Hardy Heinlin]

Regarding the "ORD..." SID: I just compared the ARINC masters of Aerosoft (Lido) and Navblue.

Navblue cycle 2005 with ORD5:
Every runway gets two runway HDG specific legs; first a HDG to altitude 1080 ft, then a HDG vector.

Lido cycle 2105 with ORD6:
Just one common "initial fix" for all runways; no HDG data, just GCO as the initial fix.
I don't know why they don't even include any initial altitude constraint.
I guess I can't apply any trick here. I think you need to depart with HDG SEL.


Regards,

|-|ardy

[Hardy Heinlin]

Undesired SID runway waypoints are now eliminated in PSX 10.148:

https://aerowinx.com/board/index.php?topic=4191.0


Regards,

|-|ardy