Airbus Calculation of Final Path Profile
Thread Starter
Joined: Dec 1998
Posts: 36
Likes: 2
From: The Sandpit
Airbus Calculation of Final Path Profile
Hello everyone,
I have to admit that this hasn't been a big one for me as a 'classically-experienced' driver: the approaches I most usually fly are ILS or overlay VOR/NDB, where raw data are available and authoritative.
By that I mean, particularly for the overlay approaches, the not-below heights derive from primary altimeter and raw data fix. If the target profile has put you low against the raw data, well, you don't continue descent. Cold weather and nav accuracy without GPS spring to mind as possible factors.
But, as my new airline starts to do RNAV/RNP approaches, I need to revisit how the aircraft derives its target profile, to achieve the same sort of interdependent 2D/ALT crosscheck. I'm thinking of the old presentation slide where the FMGC defines its end-of-approach point as a fix and altitude and then projects a 3deg slope backward from that point in space.
What I want to know is whether the FMGC takes current primary altimeter QNH into account when calculating the fix and derived profile, or whether the FMGC looks at QNH set in the APP page. (I have my thoughts, but I'd like them confirmed...)
FCOM states that the APP page QNH is used for repressurisation profile, but seems (to my research, anyways) to be silent as to how it derives the target profile.
You can see how this becomes problematic when the GNSS approaches have no raw data fixes to trap errors in altimeter setting. (I know: they should be trapped by SOPs; but, but, but...)
This is actually the first part of a (possible) two part question. Thanks, in advance.
As an aside, it also makes a very good case for compensated altimeters in any Airbus, as of - I don't know - 30 years ago...
I have to admit that this hasn't been a big one for me as a 'classically-experienced' driver: the approaches I most usually fly are ILS or overlay VOR/NDB, where raw data are available and authoritative.
By that I mean, particularly for the overlay approaches, the not-below heights derive from primary altimeter and raw data fix. If the target profile has put you low against the raw data, well, you don't continue descent. Cold weather and nav accuracy without GPS spring to mind as possible factors.
But, as my new airline starts to do RNAV/RNP approaches, I need to revisit how the aircraft derives its target profile, to achieve the same sort of interdependent 2D/ALT crosscheck. I'm thinking of the old presentation slide where the FMGC defines its end-of-approach point as a fix and altitude and then projects a 3deg slope backward from that point in space.
What I want to know is whether the FMGC takes current primary altimeter QNH into account when calculating the fix and derived profile, or whether the FMGC looks at QNH set in the APP page. (I have my thoughts, but I'd like them confirmed...)
FCOM states that the APP page QNH is used for repressurisation profile, but seems (to my research, anyways) to be silent as to how it derives the target profile.
You can see how this becomes problematic when the GNSS approaches have no raw data fixes to trap errors in altimeter setting. (I know: they should be trapped by SOPs; but, but, but...)
This is actually the first part of a (possible) two part question. Thanks, in advance.
As an aside, it also makes a very good case for compensated altimeters in any Airbus, as of - I don't know - 30 years ago...
Thread Starter
Joined: Dec 1998
Posts: 36
Likes: 2
From: The Sandpit
Tough Crowd...
Nearly 300 views and no bites. I'm not really sure what to make of that.
Okay: I'll go first. It's primary altimeter QNH - always was, always will be; for any number of reasons, including the failure cases.
Why I asked the question is that my new airline has recently adopted a procedure at transition where the primary altimeters and ISIS are simultaneously set to QNH extracted from the FMGS Perf App page. Bear in mind that we operate exclusively under radar control, and most if not all destinations provide METAR/ATIS by ACARS or Voice. And, we've been given QNH when cleared to first altitude below transition. And, we could always ask if we're not sure.
So, I wanted to confirm my belief that QNH on the Perf App page was like a kiss from your sister - nice, but ultimately useless.
Essentially, my new lot are using the App page as a scratchpad - to which I say, why not use the QNH you've just received or written down as basis for the crosscheck, and cut out all that extra button pushing. That's a good reason, right there.
But the problem is deeper than that: we're now using an input to error-check another input.
I gather this new procedure is in response to a small number of mis-sets under workload; but I really think that the procedure makes things just that little more complex, doesn't trap the error correctly, and has no basis in system design, anyways.
I leave the floor open...
Okay: I'll go first. It's primary altimeter QNH - always was, always will be; for any number of reasons, including the failure cases.
Why I asked the question is that my new airline has recently adopted a procedure at transition where the primary altimeters and ISIS are simultaneously set to QNH extracted from the FMGS Perf App page. Bear in mind that we operate exclusively under radar control, and most if not all destinations provide METAR/ATIS by ACARS or Voice. And, we've been given QNH when cleared to first altitude below transition. And, we could always ask if we're not sure.
So, I wanted to confirm my belief that QNH on the Perf App page was like a kiss from your sister - nice, but ultimately useless.
Essentially, my new lot are using the App page as a scratchpad - to which I say, why not use the QNH you've just received or written down as basis for the crosscheck, and cut out all that extra button pushing. That's a good reason, right there.
But the problem is deeper than that: we're now using an input to error-check another input.
I gather this new procedure is in response to a small number of mis-sets under workload; but I really think that the procedure makes things just that little more complex, doesn't trap the error correctly, and has no basis in system design, anyways.
I leave the floor open...
Joined: Jul 2006
Posts: 1,100
Likes: 111
From: Somewhere over the rainbow
No it does not look at the QNH set in the perf page and nor the temperature. That’s why when using Final APP you have a low temperature limitation. It’s critical you set the correct QNH on EFIS as a wrong QNH will put you high or low on profile.
The QNH you insert on the perf page is only used for cabin repressurisation segment.
Joined: Feb 2002
Posts: 115
Likes: 1
From: US
Agreed with pineteam. With regards to temperature compensation, unless your airline has the optional FMS landing system approach (FLS approach) installed, the approach is not compensated for cold (or hot!) weather. The chart usually specify a minimum temperature for using LNAV/VNAV minima. If the temperature is below that value, you can fly the approach using corrected LNAV minima and an adjusted vertical path, using NAV and FPA to fly it. Hopefully this helps.
Joined: Nov 2006
Posts: 367
Likes: 0
From: Tropics
I am not well versed with the design criteria of RNP approaches, are there any upper temperature limits? I recall coming across documentation stating there if there’s an upper temperature limit for the approach, it’d be stated but I’ve never seen one.
The region I operate in, OATs are often above 30 degrees celsius, sometimes hitting the 40s. A few RNP approaches flown in FINAL APP it is not uncommon to see 4 whites on the PAPI as we are high (opposite of cold weather). How does one manage this? Imagine doing the approach in inclement weather breaking out of cloud and in rain late at minima only to see 4 whites!
The region I operate in, OATs are often above 30 degrees celsius, sometimes hitting the 40s. A few RNP approaches flown in FINAL APP it is not uncommon to see 4 whites on the PAPI as we are high (opposite of cold weather). How does one manage this? Imagine doing the approach in inclement weather breaking out of cloud and in rain late at minima only to see 4 whites!
Joined: Jul 2006
Posts: 1,100
Likes: 111
From: Somewhere over the rainbow
I’m not aware of high temperature limit.
If you are 4 whites, then just aim for 1000 feet/min ROD which is still acceptable below 1000 feet and you should be back on 2 whites 2 reds in no time. Not a big deal really.
If you are 4 whites, then just aim for 1000 feet/min ROD which is still acceptable below 1000 feet and you should be back on 2 whites 2 reds in no time. Not a big deal really.
Joined: Oct 2019
Posts: 234
Likes: 12
From: SW1A 2AA
Next time you go to the sim ask your mate in the back seat to demo a QNH setting error. Set the sim cloud base at 500’ agl. Set the airfield QNH of 1013 but an “error” between ATC and your ears mean the crew set 1003.
A non radar airfield won’t pick up the fact that you are flying around 300’ below any cleared or procedural altitude. Think small Greek islands. The very clever Airbus/Boeing flies a perfect approach exactly as depicted on the plate. Spot on at every fix. RNP AR, GNSS, overlay. Makes no difference. Your range/altitude checks down the approach are all exactly as on the plate. Until you get visual. It’s a real sobering exercise that demonstrates how important the basics are.
A non radar airfield won’t pick up the fact that you are flying around 300’ below any cleared or procedural altitude. Think small Greek islands. The very clever Airbus/Boeing flies a perfect approach exactly as depicted on the plate. Spot on at every fix. RNP AR, GNSS, overlay. Makes no difference. Your range/altitude checks down the approach are all exactly as on the plate. Until you get visual. It’s a real sobering exercise that demonstrates how important the basics are.
Thread Starter
Joined: Dec 1998
Posts: 36
Likes: 2
From: The Sandpit
Thanks. Jim
That was the hidden thrust of my question. In effort to avoid this exact error, my new mob has come up with the idea of inserting QNH in the PERF APP page and using it as some sort of gross error check at transition. That is, not before...
Only, by that stage, it's likely going to be the same (misheard) QNH and won't alert a ship-coherent mis-set, anyway. In other words, if the (erroneous) source is the same, the error won't be trapped. And, at transition, it's too late anyways.
That's why QNH readback at altitude assignment is now a thing: it wasn't when I started a very long time ago - at least, not in my neck of the woods. Whenever you transition to QNH, then the setting needs to be verified by readback, or by reference to latest METAR or ACARS or similar data - but not from what you or Bloggs has inputted in the box.
If readback procedures are failing, then that's a whole safety of air navigation problem - not just an altimeter problem - and it needs to be addressed with requisite vigour, rather than by imposition of SOP 'band-aids'.
Cheers and thanks everyone, so far...
Only, by that stage, it's likely going to be the same (misheard) QNH and won't alert a ship-coherent mis-set, anyway. In other words, if the (erroneous) source is the same, the error won't be trapped. And, at transition, it's too late anyways.
That's why QNH readback at altitude assignment is now a thing: it wasn't when I started a very long time ago - at least, not in my neck of the woods. Whenever you transition to QNH, then the setting needs to be verified by readback, or by reference to latest METAR or ACARS or similar data - but not from what you or Bloggs has inputted in the box.
If readback procedures are failing, then that's a whole safety of air navigation problem - not just an altimeter problem - and it needs to be addressed with requisite vigour, rather than by imposition of SOP 'band-aids'.
Cheers and thanks everyone, so far...
Last edited by Friendly Pelican; 11th July 2021 at 11:27.
Joined: Feb 2002
Posts: 115
Likes: 1
From: US
Wow, Friendly Pelican... Like you're saying. There is NO WAY to catch that error at, before or past transition level. Garbage in is garbage out... If you're new to the bus it is worth noting that the FMG(E)C has a model of the standard atmosphere incorporated into it. Hence the 36090' for the tropopause on the init page. That's also why ISA deviation is only showing when the Captain's altimeter is set to STD (A320, A330, A340). When descending the level at which the STD box starts blinking is dependant on the QNH input on the PERF page.
Joined: Jul 2006
Posts: 1,100
Likes: 111
From: Somewhere over the rainbow
Rt Hon Jim Hacker MP
Very good point. I never realized that actually. I always preset the destination airport QNH early during the flight to minimize this kind of mistake. At least when approaching the TL and ATC gives us the QNH, I know it will be close to the one I inserted earlier and it’s unlikely to set a wrong QNH of 10hpa. I guess a crosscheck with the RA is the last line of defense assuming the ground is relatively flat below. But just to confirm: If airport QNH is 1013 but the crew set by mistake QNH 1003, they will fly 300 feet too high and not too low.
Very good point. I never realized that actually. I always preset the destination airport QNH early during the flight to minimize this kind of mistake. At least when approaching the TL and ATC gives us the QNH, I know it will be close to the one I inserted earlier and it’s unlikely to set a wrong QNH of 10hpa. I guess a crosscheck with the RA is the last line of defense assuming the ground is relatively flat below. But just to confirm: If airport QNH is 1013 but the crew set by mistake QNH 1003, they will fly 300 feet too high and not too low.
