I’m looking for a “cheap” way to get baro-altitude into my gps/nav/com (i.e. for much less than $5k).
I have a standard setup with normal altimeter and Sandia 5-35 encoder, both not all that old. There are a lot of options for getting baro-alt into the gps/nav/com, but everything I’ve found needs a baro-altimeter plus ADC which together adds up to about $5k not incl installation. I haven’t found anything used in that area that would bring down the cost.
There is some new stuff that looks very interesting, but isn’t (yet) ready for installation in a certified aircraft. E.g. Dynon D10A plus HS34 for about $3k. The Dynon D10A is now certified but the EAA STC doesn’t include the HS34 and they don’t seem interested in adding it. Dynon is focussing their certification efforts on the their Skytrax system which is a completely other dimension… :-(
Any ideas anyone?
Can’t you just pick up a used encoding altimeter emitting gray code?
Why are you so keen on having baro input to your GNS?
Not sure how gray code plays a role. The gps needs baro-alt to auto-sequence “heading-to-altitude” legs of a route. Not a big deal, but a bit of a pain that’s all.
chflyer wrote:
Not sure how gray code plays a role.
Gray code is a parallel data transport standardized shortly before Christopher Columbus set sails. It’s what those old encoding altimeters deliver and the GNS series has input connectors for gray code.
http://www.mstewart.net/Downloads/gns430w_IM.pdf
PS: Gray code is the nice feature that each wire represents an altitude level and if you chafe one wire, your transponder can suddenly jump up to e.g. 35k feet and freak out ATC
Yes, I know what gray code is. The issue is that encoder output is always pressure altitude, not baro-altitude, regardless whether serial (5) or gray code (6). I’ve got serial input to my gps from the Sandia 5-35.
Sure, the GNS manual quote indicates that it will accept all those altitude inputs. However, can you provide documented evidence that if sources 1-4 are not available it will use the pressure altitude to auto-sequence heading-to-altitude legs?
Yes, those too. I was referencing heading-to-altitude legs, such as one will often see in a missed approach or departure procedure, but the situation is the same. The gps needs a baro-altitude input to auto-sequence. Pressure altitude isn’t enough.
achimha wrote:
Gray code is the nice feature that each wire represents an altitude level and if you chafe one wire, your transponder can suddenly jump up to e.g. 35k feet and freak out ATC
No, it’s not. Or you mean something that I don’t understand with “each wire represents an altitude level”. Gray code is a binary code arranged such that only one bit changes between two successive values. The advantage is that if several bits changed they would need to change at exactly the same time to avoid spurious incorrect signals when changing between the values — something which is essentially impossible to achieve if the code is generated by an analogue device.
Any non-redundant binary coding would have the problem that single bit errors could cause major changes in the signalled value.
Airborne_Again wrote:
Or you mean something that I don’t understand with “each wire represents an altitude level”
https://en.wikipedia.org/wiki/Gray_code
It has some builtin protection against errors resulting from broken wires but it can still get it wrong whereas a serial protocol would either be connected or disconnected (if the transport has error correction).
That however is true with both Gray code and straight binary.
Actually I wonder why avionics uses Gray code. Is it something to do with it being easier to generate using mechanical parts, and it ensures no missing codes?