Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 2025 views
  • Users 0 members are here
Related

Ground Proximity Warning System for my Experimental Velocity Aircraft

davetnelson

I'm working to put together a quasi GPWS (Ground Proximity Warning System) for my experimental airplane... a four seat Velocity.  The purpose is essentially to provide a timely warning (like someone screaming into my headset) that I'm about to land the airplne without first extending the landing gear.

 

My idea so far is this - there is an RS232 output from my aviation GPS receiver that contains latitude/longitude, ground speed, destination & distance from destination, and the GPS calculated elevation (referenced to Mean Sea Level (MSL).  I've got a Raspberry Pi on order... my plan is to use the Raspberry Pi to interpret the GPS serial stream and to run the following test.... If I am within, say, 3 miles of my destination AND I'm below, say, 300 feet, AND I'm below my maximum gear extension speed (120 knots) AND my landing gear isn't extended - WARNING!  WARNING!

 

I'd be interested in the thoughts of this community.  The biggest challenges I see (outside of learning linux and whatever programming language makes sense), are things like:

- How to determine my altitude Above Ground Level (AGL) from the MSL output of the GPS (I'll need a terrain elevation database, or perhaps a database of airports in the US including their altitude in MSL),

- How much should I worry about GPS altitude error?

- Do I need to plan for any Raspberry Pi driven display in the aircraft?

- This won't be my only gear up warning system... but... if it becomes my primary system, what should I be worried about?

 

Thoughts anyone?  My Raspberry Pi should arrive this week... I'm ready to go.

Attachments:
image
Parents
  • 0

    Good points below. I'd like to add that any components you can find with a CAN bus (like what's used in cars) will be more stable and less prone to interference.

     

    Plus I'd agree the things you'd like to do are easily done on a microcontroller, Pi might be overkill. Plus a MCU boots in like what, 1/10th of a second?

     

    -Ben

  • 0 in reply to benheck

    Thanks, Shabaz and Ben - I appreciate the input. 

     

    In thinking about this, I realize that I was originally attracted to the PR for this simple reason - my strengths are in the HW, not in the SW.  I know I can get help from friends and/or forumns on the SW, and I know I can handle the HW myself... I think....!

     

    And I have looked at microcontroller boards in the past (although not to the level of effort I've put into RP).   One thing that's held me back is that whatever solution I use will require a reasonably large sized database that (in theory) should be updated once in awhile.  Here's why... I'll use either the GPS altitude from my aviation GPS, or a pressure altitude that should be availalble on an RS-232RS-232 output from a different instrument (an EFIS - Electronic Flight Instrument System - or in common parlance a "glass panel").  The issue is that both of those altitudes are referenced to Mean Sea Level (MSL), and have no direct way to tell me my altitude Above Ground Level (AGL)... obviously, AGL is what I need.

     

    So, to get from MSL to AGL my idea is to use a database of local elevations.  There are two candidates - one using latitude / longitude to localize area terrain elevation, or one using the international standard identifier for the airport I'm going to land at (for instance, KLGA is LaGuardia). In either case, the algorithm will be to look up the local terrain elevation (in MSL) and subtract that from the RS-232RS-232 altitude (in MSL) which will give me a pretty good approximation for AGL. 

     

    With this in mind, the Raspberry Pi attracted me because of the SD Ram slot.... which would make adding / updating the database in the airplane much easier than having to remove the whole device from the aircraft every time I need either a database or SW update.

     

    I do like your idea of using a CAN bus.  However, good old RS-232RS-232 is pretty much the standard used by these fancy boxes we stick in our planes these days.  I also like the idea of using a microcontroller instead of an RP because, as Shabaz points out, it should be easier to interface to my aircraft. 

     

    While this is a complex project, consider - for me, the hard part (building the airplane) is done.... that was a long struggle.  So, this is kind of "just for fun".  It won't replace any of my existing gear safety systems, it will co-exist with them.  It will live in the cockpit environment, so I'm not too concerned re. temperature swings.  I grew up in electronics (I was a Ham operator at age 12)... so I'm pretty comfortable with handling the signal integrity and noise issues.  This is really just a cool project to keep my brain sharp during the long Minnesota winter. 

     

    Any and all additional input is welcome.  Among the things I've been pondering:

    - I'll need to have the RP begin execution of my SW immediately upon boot, with no external "prompt"... (just like the microcontroller Shabaz recommends!)

    - If I use the altitude from my EFIS (a Dynon D10A) instead of my GPS (Garmin GNS-530W), I'll need to input two seperate RS-232RS-232 serial streams to the RP.  I can add some logic to mux these serial streams -but is there an easier way (other than using one of the USB ports)?

     

    I'm sure I'll have lots more questions as time goes on.  In any case - thanks!

Reply
  • 0 in reply to benheck

    Thanks, Shabaz and Ben - I appreciate the input. 

     

    In thinking about this, I realize that I was originally attracted to the PR for this simple reason - my strengths are in the HW, not in the SW.  I know I can get help from friends and/or forumns on the SW, and I know I can handle the HW myself... I think....!

     

    And I have looked at microcontroller boards in the past (although not to the level of effort I've put into RP).   One thing that's held me back is that whatever solution I use will require a reasonably large sized database that (in theory) should be updated once in awhile.  Here's why... I'll use either the GPS altitude from my aviation GPS, or a pressure altitude that should be availalble on an RS-232RS-232 output from a different instrument (an EFIS - Electronic Flight Instrument System - or in common parlance a "glass panel").  The issue is that both of those altitudes are referenced to Mean Sea Level (MSL), and have no direct way to tell me my altitude Above Ground Level (AGL)... obviously, AGL is what I need.

     

    So, to get from MSL to AGL my idea is to use a database of local elevations.  There are two candidates - one using latitude / longitude to localize area terrain elevation, or one using the international standard identifier for the airport I'm going to land at (for instance, KLGA is LaGuardia). In either case, the algorithm will be to look up the local terrain elevation (in MSL) and subtract that from the RS-232RS-232 altitude (in MSL) which will give me a pretty good approximation for AGL. 

     

    With this in mind, the Raspberry Pi attracted me because of the SD Ram slot.... which would make adding / updating the database in the airplane much easier than having to remove the whole device from the aircraft every time I need either a database or SW update.

     

    I do like your idea of using a CAN bus.  However, good old RS-232RS-232 is pretty much the standard used by these fancy boxes we stick in our planes these days.  I also like the idea of using a microcontroller instead of an RP because, as Shabaz points out, it should be easier to interface to my aircraft. 

     

    While this is a complex project, consider - for me, the hard part (building the airplane) is done.... that was a long struggle.  So, this is kind of "just for fun".  It won't replace any of my existing gear safety systems, it will co-exist with them.  It will live in the cockpit environment, so I'm not too concerned re. temperature swings.  I grew up in electronics (I was a Ham operator at age 12)... so I'm pretty comfortable with handling the signal integrity and noise issues.  This is really just a cool project to keep my brain sharp during the long Minnesota winter. 

     

    Any and all additional input is welcome.  Among the things I've been pondering:

    - I'll need to have the RP begin execution of my SW immediately upon boot, with no external "prompt"... (just like the microcontroller Shabaz recommends!)

    - If I use the altitude from my EFIS (a Dynon D10A) instead of my GPS (Garmin GNS-530W), I'll need to input two seperate RS-232RS-232 serial streams to the RP.  I can add some logic to mux these serial streams -but is there an easier way (other than using one of the USB ports)?

     

    I'm sure I'll have lots more questions as time goes on.  In any case - thanks!

Children
No Data