Runway Position Update

[Driver170 42]

If performing a runway intersection takeoff and with GPS enabled (GPS update didables TOGA update) will i still need to enter the RWY REMAIN. Or will the GPS account for intersection distance?

[pcubine 143]

Another bizarre question. Try the intersection takeoff and see what happens. Use the default panel state so you don't spend a lot of time setting up a flight that might crash. Start the flight at the end of the runway and taxi to the intersection you want to try.

[scandinavian13 5,192]

 

 

If performing a runway intersection takeoff and with GPS enabled (GPS update didables TOGA update) will i still need to enter the RWY REMAIN.

 

This is the sole purpose of this feature.

 

 

 

Or will the GPS account for intersection distance?

 

It will mix in, but the IRS position error will remain, I believe.

[Driver170 42]

I just can't find any reference to add TO SHIFT or RWY REMAIN if GPS is updating.

[scandinavian13 5,192]

I just can't find any reference to add TO SHIFT or RWY REMAIN if GPS is updating.

 

Hyperfocusing again - not a big deal if you don't do it (and the lack of mention in FCOMv2 is an indicator of this), but why not get into a good habit of it for the times GPS is MELd?

[Driver170 42]

But thats not the answer i was looking for? Does GPS auto update the intersection in the FMC POS?

[flyultimate 13]

More to the point, if you are flying jets, don't get into the habit of accepting intersection takeoffs. This will solve your issue and provide you with an extra element of safety. When flying, always keep your options in your back pocket for those times you will need them.

 

Remember:

 

Runway Behind You,

Altitude Above You,

Fuel You Left At The Gate,

And, You Only Have Too Much Fuel When You Are On Fire

 

Revert to your manual for the required numbers whenever you find that the GPS will not provide you with the required information. As was stated by Kyle, if your GPS fails, you have to have an alternate method of data retrival.

 

If, though, you find yourself accepting an intersection departure, plug in the departure runway, set up your initialization, obtain your "full length runway performance data", and compare that data to the available runway distance from the intersection departure point. If there is an issue with the data and a performance issue manifests itself, don't perform the intersection departure.

 

Cheers,

Jim Wilkerson

But thats not the answer i was looking for? Does GPS auto update the intersection in the FMC POS?

 

Vernon, unless something has really changed in the past couple of years in regards to GPS, GPS will not update performance data from a position update. GPS knows full runway length data and doesn't provide performance data for anything but full runway length available. The only variables I am aware of will be takeoff weight, flap setting, runway slope, and runway contamination.

 

I personally haven't seen a GPS that will recalculate runway available from a positional update with regards to a particular runway selected to be used for departure in the GPS. Almost every database for GPS provides only the runway selected "Full Length" data. I don't know of any GPS that will extrapolate remaining runway available, and provide "updated" takeoff performance numbers from a positional update.

 

Cheers,

 

Jim Wilkerson

[scandinavian13 5,192]

But thats not the answer i was looking for? Does GPS auto update the intersection in the FMC POS?

 

The earlier post kinda does.

 

Remember that we're using MIX data here. Go to the POS page to see all the individual positions being used. They're all usually different, though the GPS positions are usually pretty close. The IRS position, once aligned, is never updated until it is turned off and back on again (one of the reasons it's recommended to do so on the turn).

 

Is this a problem?

As long as you have GPS and/or DME/DME updating, no. The GPS is has the highest priority when feeding position updates, so as long as it's working just fine, then the TAKEOFF entry is relatively moot. If it were to drop, however, you're left with a compromised IRS position by however many feet was cut off of the runway using the intersection departure. That isn't much, but disasters are usually a chain of events, and by not entering the change, you're consciously operating with a bent link. We do that all the time in aviation, honestly (see MEL items), but those are calculated risks. For such a simple entry, though, I'd argue that regardless of the magnitude of risk, you might as well just do it.

[Stearmandriver 2,235]

More to the point, if you are flying jets, don't get into the habit of accepting intersection takeoffs. This will solve your issue and provide you with an extra element of safety. When flying, always keep your options in your back pocket for those times you will need them.

 

Remember:

 

Runway Behind You,

Altitude Above You,

Fuel You Left At The Gate,

And, You Only Have Too Much Fuel When You Are On Fire

 

 

Excellent private pilot level advice. The next time you're taxiing out at O'Hare and you're assigned 28R at MM or EE, and you see the line of 20+ aircraft ranging from RJs to 747s waiting to take those departures, you go ahead and advise ground you'll require full length in your 737. Enjoy the penalty box... But hey, MAJOR overs! :-D

 

Intersection departures are a reality of airline ops at many large airports....

[Driver170 42]

Thanks kyle and also to the rest! But, the runway coordinate in the FMC Nav data base and EFIS map runway symbol is the landing threshold!? So departing other than the landing threshold surely this will introduce an FMC position error even with working GPS or DME/DME. Hence entering RWY REMAIN regardless....

[kevinh 409]

Thanks kyle and also to the rest! But, the runway coordinate in the FMC Nav data base and EFIS map runway symbol is the landing threshold!? So departing other than the landing threshold surely this will introduce an FMC position error even with working GPS or DME/DME. Hence entering RWY REMAIN regardless....

It isn't necessary with GPS Updating. Just remember why the TOGA position update is there at all. It's a feature that dates from before GPS. TOGA position update was meant as a way to remove any position error that might have been there before departure. Incorrect initial position entry for example. When TOGA is selected, the FMC position gets a position correction to the runway threshold plus any intersection shift you entered. If you have GPS updating installed then this is completely irrelevant. FMC position will be updated by GPS corrections throughout the flight. You also have DME position update.

[scandinavian13 5,192]

Excellent private pilot level advice. The next time you're taxiing out at O'Hare and you're assigned 28R at MM or EE, and you see the line of 20+ aircraft ranging from RJs to 747s waiting to take those departures, you go ahead and advise ground you'll require full length in your 737. Enjoy the penalty box... But hey, MAJOR overs! :-D

 

Intersection departures are a reality of airline ops at many large airports....

 

Yeah - I'm a huge proponent for safety, but I'm also very outspoken about black and white safety rules boxing people into some operations that may actually be detrimental to the operation, and in some cases, even less safe. There's no shortage of it in the industry, which is somewhat worrisome, if only for the fact that regulated safety takes the conscious safe decision-making out of the mix, which is really what we need as pilots.

 

As a recent example, I know a bunch of the flight schools in the area have policies restricting pilots from intersection takeoffs. Manasty (KHEF) is going through some growing pains (taxiway and run-up area resurfacing/widening), so when the field is in South Ops, it's 16L at B2 (unless full length is requested). That cuts a significant portion off of the runway, but it's still just about as long as 16R, which the school regularly uses. Having operated on much smaller runways (2000x40 is the smallest, I believe, and the shortened 16L is nearly double that), I took the lowly Skychicken out on 16L at B2 and got out of there.

 

It saved me time, saved the controller time, and left me with less exposure to departing/arriving traffic (what people seemingly fail to see when they unnecessarily require full length in certain operations is that being on the runway is an exposure to the risk of being hit by arriving or departing aircraft - back taxiing greatly increases this exposure at both controlled and uncontrolled fields).

 

Thanks kyle and also to the rest! But, the runway coordinate in the FMC Nav data base and EFIS map runway symbol is the landing threshold!? So departing other than the landing threshold surely this will introduce an FMC position error even with working GPS or DME/DME. Hence entering RWY REMAIN regardless....

 

Earlier, my points were more related to getting into the habit of doing it just to avoid any time where you set yourself up for a bad position update if GPS were MELd. The reason for this, as mentioned, is the nature of the mix. IRS position will never change, but the position update will help the FMC use the IRS position and correct what it provides when coming up with an FMC position "solution" (regardless of GPS availability). GPS being available simply takes a higher priority (because it is considered more accurate by itself), but to increase the accuracy of the position and provide verification/redundancy, the GPS position is mixed with the other positions (individual IRSs and DME/DME). The fact that GPS has a higher priority in the mix means that, as long as GPS is available, the position error introduced in not using the RWY REMAIN function is negligible.

 

To put it in perspective, if the runway were shortened by 1500 feet, and your position was based solely off of the position update taken on hitting TOGA, you'd still theoretically be able to maintain RNP 0.3 (assuming no position drift over time). Given that this position update is actually mixed in with the provided IRS positions (remember, it doesn't overwrite them), along with DME/DME, the actual error is much less than 1500 feet as the IRS positions and DME/DME positions will show a position closer to "reality." Adding GPS back in, particularly given its higher priority in the mix, means that the position error from the RWY REMAIN is nearly flat out ignored (since there are better sources of information available: IRS, DME/DME, and GPS all somewhat disagreeing with the TOGA value).

 

So, again, it's something that's nice to be in the habit of just in case the GPS is out of service, but it's not something to be incredibly concerned about.

[kevinh 409]

 

 

Earlier, my points were more related to getting into the habit of doing it just to avoid any time where you set yourself up for a bad position update if GPS were MELd.

I'm confused now. Are you saying that the FMC records the TO shift anyway when TOGA is activated but doesn't use it if GPS update is enabled? That's the only way it could introduce the shift later in the event of a GPS problem. Yet FCOM v1 says you should use radio navaids to manually update FMC position in that case.

 

It may be a good habit to get into, but I'm not sure it actually achieves anything, even if GPS goes U/S.

[scandinavian13 5,192]

I'm confused now. Are you saying that the FMC records the TO shift anyway when TOGA is activated but doesn't use it if GPS update is enabled? That's the only way it could introduce the shift later in the event of a GPS problem. Yet FCOM v1 says you should use radio navaids to manually update FMC position in that case.

 

It may be a good habit to get into, but I'm not sure it actually achieves anything, even if GPS goes U/S.

 

Speaking from a pure data perspective, and I'm not sure of the actual intricacies here, but:

 

Say we're in an IRS-only mode (no GPS, no DME/DME):

• You spin up both IRUs. Both are devoid of assumed position until you enter the location on POS INIT. Both IRUs will use this position, though they will both diverge naturally through the natural inertial errors. After that initial entry, no actual updates to the position are accepted on the IRUs, which means that any updates are mixed in to correct any IRU errors, and not to reset the position of the IRUs.
• The FMC will pull the runway threshold when TO/GA is pressed and enter it into the calculated FMC position. Again, since the IRU positions are never overwritten after the initial alignment, this pulled value is simply mixed in with the IRU-provided positions. My thought is that, when TO/GA is pressed, the value is used to check against each IRU-provided position to assist in generating an initial error value (figure of merit) for each.
• As the FMC single position is calculated from the IRUs, the FMC will use the these metrics to determine a more accurate assumed position.

Now, add in DME/DME:

• Assuming all of the above, DME/DME updating adds more position data to the mix, in addition to the individual IRU positions.
• This bias, in this case, is about 80:20 in favor of the DME/DME data, because it is based on fixed, ground-based navaids.
• IRU positions remain independent, so the initial FoM is still factored into the IRU mix.

Now add in GPS:

• Assuming all of the above, GPS updating adds even more position data to the mix, in addition to RADIO and IRU.
• The bias with GPS available is nearly entirely GPS, from what I can tell, with the other positions simply relegated to standby.
• IRU positions, again, remain independent, so the initial FoM is still factored into the IRU mix, but has no effect as long as GPS is active.

 

 

So...from what I understand, it's "used" in the sense that the value is taken and stored until the IRUs are reset, but it's not of any real importance as long as GPS is in use.

[Driver170 42]

Very well informative answer there kyle! Good stuff