![]() |
WCollins
The altitude readout from a GPS is normally the vertical portion of the 3D GPS solution. Over the last 200hrs I have always found it (KLN94B) within 100ft of the altimeter - whenever the altimeter was set to a known good QNH; "regional QNH" is frequently well out. This is at few thousand feet or lower; above that the error is bigger but that's most likely due to altimeter errors due do deviations from ISA. The QNH setting, and the altitude encoder, which an "IFR approved" GPS has is for RAIM purposes. It does not affect the displayed altitude. For what it's worth I always check the GPS altitude against both altimeters before an instrument approach. It's never been out, but if it was, and both altimeters read the same, I would have to suspect something potentially dangerous with the altimeters. I understand why "GPS altitude" is unofficial; I am merely saying what I know about it. |
Our GNS430 for sure has an input from the altitude encoder that feeds the transponder - because if I power off the transponder, the GPS throws up a warning flag "no altitude input". I don't know if it's supposed to do that, mind.
|
Keef, It is!
You are required to connect an altitude encoder to an IFR GPS. In the event of an encoder are static failure you can switch the Garmins 430/530 back to GPS derived altitiude. |
bose-x
Are you 100% sure that the altitude displayed on a GNSx30 / KLN94B is anything to do with the altitude encoder connected to the GPS? As I posted higher above, the encoder is a RAIM requirement, and should generate a RAIM warning if there is something like a 200ft diff between the GPS solution altitude and the output of the encoder. For this to work the encoder needs to know the QNH, which is why the QNH has to be entered. My GPS ('94B) doesn't display the GPS altitude unless it gets a signal from enough satellites, more than 3 I think, and even then it fluctuates by say 50ft until it picks up more of them. If it was derived from the altitude encoder it would not do that. |
For an Installation to be IFR certified the GPS has to be connected to an altitude encoder. The GARMIN 430/530 will use the encoder data as the primary altitude indication.
If the encoder failed it would flag up that it has no altitude data and you can then enter the settings menu and switch it back to GPS derived data. The unit is then no longer certified for IFR flight. You don't need to set QNH or otherwise as the encoder encodes at 1013mb. |
bose-x
Due to the importance of this I have just checked it with a Honeywell/Garmin avionics distributor technican who I know knows the stuff, and unfortunately you are incorrect both on the GNS430 and the KLN94B. The displayed altitude is derived solely from GPS satellite signals. (The GNS430 can display the altitude encoder output in one of its maintenance pages but that's it) The purpose of the altitude encoder is solely for RAIM checking. RAIM checking is a requirement aof an IFR approved GPS. The GPS compares the altitude encoder output (corrected for the QNH which on the KLN94 you enter manually) with the GPS-derived altitude and if there is an error exceeding a certain figure it will flag a RAIM warning. The GNS430 should have a QNH setting too. So, if the static system failed, the GPS altitude would still work the same. You would get a RAIM warning though. |
Curious, not what my avionics guy told me but I am willing to check!
|
bose, IO540
I don't know which of you is right, but I do think that it is vitally important that we all understand this...there won't be time to find out in an emergency. I'll look it up in the manual (which I have downloaded) if I get the chance later, and post the relevant text, but if anyone gets a definitive answer first (and, I am sorry, but I don't think we can rely on an avionics engineer for a definitive answer) please tell us all! Will |
Interesting thread with a few arms and legs to it.
When in 3D Mode, the Altitude displayed on the 430 and 530 is GPS-derived. Only when degraded to 2D mode by inadequate satellite coverage does the GPS fall back to display externally serialised altitude (such as from a transponder or blind encoder). It is this need for a fallback under conditions of poor satellite reception that drives the BRNAV requirement. There are plenty of references to this in the Flight Manual Supplement, the Flight Guide and the Installation Guide. RAIM and RAIM prediction on the 430 and 530 does not appear to rely on any form of external altitude signal (that I can find). A RAIM error is caused by actual or predicted integrity problems caused by the anglular position of GPS satellites in the sky. It is absolutely not generated by disparity in external versus derived altitude. RAIM is computed based on the Satellite Almanac contained within the GPS and occasionally downloaded from the satellites. It is calculated with respect to the position which is being FPLed/DIRECTed to and the ETA, or the current position at the current time as appropriate. Barring external factors such as hangars, a RAIM error will of course tend to occur when the satellite reception downgrades to 2D anyway, so that RAIM and the reliance on the external altitude source are occasionally linked... but not quite in the way being implied above. Hope this helps 2D |
2D's
Thats basically what I understood the situation to be with and there is certainly no QNH setting on my Garmin. I am busy scouring the manual! |
2donkeys
When in 3D Mode, the Altitude displayed on the 430 and 530 is GPS-derived. Only when degraded to 2D mode by inadequate satellite coverage does the GPS fall back to display externally serialised altitude (such as from a transponder or blind encoder). It is this need for a fallback under conditions of poor satellite reception that drives the BRNAV requirement The KLN94B is IFR approved and according to Honeywell UK is also BRNAV approved and it doesn't work as above. In the absence of a good enough GPS signal, no altitude at all is displayed. Do you have a reference for the fallback of the GPS altitude to show the output of the altitude encoder instead, to enable BRNAV approval? The general idea is to use an altimeter for that purpose :O |
IO540
You are absolutely right about the KLN94B and the KLB90B. In fact both devices resolve altitude in 100 foot increments from an external source and it is this which is displayed by default. This explains the need to enter or confirm the QNH on startup. However the business of which altitude is displayed is not key to question of BRNAV certification. BRNAV is effectively a European manifestation of RMP-5. Mostly this deals with required track accuracy, but where this accuracy is met by GPS receiver, it requires a minimum of either: 4 Satellites to be received, or 3 satellites plus an external altitude source. The reason for this is nothing to do with giving you an accurate altitude readout. Rather, with only 3 satellites, your altitude provides the only acceptable means of unambiguously determining your position. Cast your mind back to your GPS notes and the intersecting spheres of position that are involved in position determination. BRNAV since it permits flight by reference to GPS is therefore concerned with belt-and-braces nav capability, and the installation standards were set accordingly. Therefore, your GPS requires an external altitude source to be RMP-5/BRNAV compliant. This has nothing to do with the displayed altitude which is something of a red herring. The BRNAV standards document is to be found on the Eurocontrol site, although it takes a little hunting down. Each member country published their own documents specifying required avionics fits. 2D |
2D
I have a feeling we are talking cross purposes In fact both devices resolve altitude in 100 foot increments from an external source and it is this which is displayed by default. This explains the need to enter or confirm the QNH on startup The external source altitude is NOT displayed by default. What is displayed is the altitude from the GPS receiver (AUX1 screen). The output from the altitude encoder is not displayed. The GPS altitude (displayed) is patently obviously not from an altitude encoder because they return the data in 10ft or 100ft steps. The displayed altitude varies in 1ft increments. Its availability is also related to satellite reception so you don't see anything for some minutes after startup and it gets more accurate as more sats are picked up. I can sit there and watch it, and have done so many times, on the KLN94B and also on the Skymap 2. The current KLN94B user manual does reveal a somewhat obscure feature of the KLN94: altitude alterting (which I have never used and which on mine is disabled in the maintenance pages; I get altitude alerting from the KFC225 autopilot whose altitude reference comes simply from the P1 altimeter) - which does use the altitude encoder and for that the QNH must be set. Furthermore the QNH must be set when doing a GPS approach - you get prompted to enter it 30 miles out, it says. These KLN94B features really need an air data computer to work well and I've never used them. I believe the GNS430 has the same issues. As far as I can tell, NO KLN94 function uses the GPS altitude; it is merely displayed in the AUX1 screen. This is as one would expect given that air pressure is used for altitude officially, not GPS. RAIM integrity checking works by comparing the altitude portion of the GPS solution against an encoding altimeter; the idea being that if the GPS computation is wrong in lat/long then it will also be wrong in altitude and this method will pick up the error - this is a fair enough assumption unless the signal is being jammed is a very sophisticated manner. |
We may be at cross purposes, but the RAIM calculation method you are suggesting is at odds with the Bendix King manual I have sitting in front of me.
Ordinarily, RAIM is predicted in respect of the waypoint to which the GPS is navigating, and is predicted effective the ETA at that waypoint. Current altitude is only incidentally a feature of that calculation. By contrast though, altitude is consulted for instantaeous RAIM integrity (that is, when no destination waypoint is being navigated towards). Failure of the altitude encoder will raise the probability of a RAIM warning because the GPS is denied one of the means of fixing GPS position, however, where 4 or more satellites are received, disabling the altitude encoder will have no effect at all on RAIM warnings. Try it and see. You'll be surprised. There is much more to RAIM than comparing real altitude with GPS-derived altitude. 2D |
2D
It sounds like the current version of the (Honeywell) KLN94B manual has been dumbed down relative to the Bendix King one you have. You are probably right in that if receiving >3 satellites, a RAIM error is unlikely to get flagged. Which is probably why bose-x, never having set the QNH, has never seen anything untoward, because most of the time you receive at least 4 satellites (usually >6). What I don't agree with is where the displayed altitude comes from. It comes from the GPS, purely and entirely. The altitude encoder output is not displayed directly. I can't speak for the GNS430 but I am told it works the same way. |
IO540
We are in complete agreement on the 430/530. I own and use both of these devices so what I wrote earlier, I can say with complete confidence. On the Honeywell kit I can only quote from the manual, and a little experience using them. Your description is at odds with the manual - but that doesn't prove anything. :D 2D |
Pure speculation on my part, but I imagine that the requirement to enter the QNH for a GPS approach is because of more stringent precision requirements for RAIM in an approach situation.
|
| All times are GMT. The time now is 17:42. |
Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.