Ground Proximity Warning System for my Experimental Velocity Aircraft

Hi Dave,

It sounds an interesting project.

I'm no expert in this area, but I can help with letting you know of some

general considerations, in case you can incorporate into your design.

1. Simplicity - the less to fail, the better. e.g. maybe consider a

barometer, and less code, e.g. a microcontroller running without an OS

2. temperature - worth considering all parts to be at least industrial temp, and

consider how it will be protected from extremes of temp and moisture.

In particular, ensure your sensors, power supplies, etc., work at the expected temperatures.

3. Reliability - rely on locking connectors intended for industrial or military use

4.  Redundancy (I guess you're familiar with this since you mention it won't be your

only system)

5. Some self test/checking mechanism

Personally, I wouldn't use a R-pi for this. I would pick an industrial temp range

microcontroller and write the minimum code needed to interface to the sensors

(e.g. GPS and/or barometer) and provide visual and audio indication). A serial interface

is quite easy with a microcontroller without requiring an OS. Your use-case doesn't

need multiple threads of execution or much shared variables, so a simple interrupt based

scheme is a better idea I think.

A database could be stored in FLASH (many microcontrollers have (say) 128kB or more

of FLASH which is possibly more than enough to store hundreds of airfield locations

maybe). I suppose you're thinking of storing a co-ord, and then using math to figure

out if you are within a certain radius of it.

For a GPS sensor, I would have a redundant one too.

Also, screening (metal case), supply decoupling and filtering against RF on supply and interfaces too,

since I'm guessing you may have a transmitter or there may be some powerful one in the vicinity, and you

don't want them to affect your electronics.

Thanks, Shabaz.

Let me take your points one at a time (and they're all good). 

First - simplicity... you are right on the money - I'm a big believer in KISS (Keep It Simple, Stupid!). In this case, though, I'm willing to tolerate some complexity... part of why I'm doing this is, well, I live in Minnesota, and winter is now upon us.  I've always had a good airplane project in mind for winter to keep myself from going crazy during the "difficult flying" season.  So, tackling this project sounded like fun once I drempt it up.  Regarding using a barometer, that's not foolproof either - it would have to be set before takeoff to the local barometric pressure, and reset during flight as I go.  I've got two altimeters in the plane now, and both have to be set & reset... I'm not really interested in adding a third.  So, I'll stick with the GPS output.  Just for background, I did also do some research  into building a homebrew radar (I am also a HAM radio operator).

Second, temperature - industrial temp will do fine.  Cockpit temperature has to be acceptible to me (and my wife)... won't be a problem.

Reliability - absolutely.  I built the plane (and it's not my first).  I've been building and wiring complex electronics for 40+ years.  I am confident but hopefully not overconfident, that I can build a reliable system.

Redundancy - in an airplane, that goes without saying.

Self testing - great comment - I haven't been thinking about that, but I will.

I've thought about an industrial microcontroller, but frankly I don't know all that much about them... RPi seemed like an easy way out... more off the shelf programming options, etc.  Once I'm knee deep, I may want to reconsider.  But, given the cost, I figured it's a good first step. 

Regarding electrical noise, yes for sure it's a consideration.  I've got some background in that... I think I can handle it.  But again, thanks for your thoughts.

Appreciate your input... keep the ideas coming... in particular, one thing you've got me considering is how to arrange a boot to the program I'll need to write upon power on... every time, without fail. 

Thanks again!

Thanks, Shabaz.

Let me take your points one at a time (and they're all good). 

First - simplicity... you are right on the money - I'm a big believer in KISS (Keep It Simple, Stupid!). In this case, though, I'm willing to tolerate some complexity... part of why I'm doing this is, well, I live in Minnesota, and winter is now upon us.  I've always had a good airplane project in mind for winter to keep myself from going crazy during the "difficult flying" season.  So, tackling this project sounded like fun once I drempt it up.  Regarding using a barometer, that's not foolproof either - it would have to be set before takeoff to the local barometric pressure, and reset during flight as I go.  I've got two altimeters in the plane now, and both have to be set & reset... I'm not really interested in adding a third.  So, I'll stick with the GPS output.  Just for background, I did also do some research  into building a homebrew radar (I am also a HAM radio operator).

Second, temperature - industrial temp will do fine.  Cockpit temperature has to be acceptible to me (and my wife)... won't be a problem.

Reliability - absolutely.  I built the plane (and it's not my first).  I've been building and wiring complex electronics for 40+ years.  I am confident but hopefully not overconfident, that I can build a reliable system.

Redundancy - in an airplane, that goes without saying.

Self testing - great comment - I haven't been thinking about that, but I will.

I've thought about an industrial microcontroller, but frankly I don't know all that much about them... RPi seemed like an easy way out... more off the shelf programming options, etc.  Once I'm knee deep, I may want to reconsider.  But, given the cost, I figured it's a good first step. 

Regarding electrical noise, yes for sure it's a consideration.  I've got some background in that... I think I can handle it.  But again, thanks for your thoughts.

Appreciate your input... keep the ideas coming... in particular, one thing you've got me considering is how to arrange a boot to the program I'll need to write upon power on... every time, without fail. 

Thanks again!

Hi Dave,

With your background it sounds like you know what you're

doing! Looking forward to hearing about it as you work on it.

It sounds like a plan, to prototype first on

R-Pi, and then maybe move to another board for the

final implementation. You could work and test your

algorithms on the R-pi. As an idea, I'd suggest using C, so that

you can (semi-)easily port to another device if needed.

Virtually all microcontrollers have a C compiler.

The reason I say semi-easily, is because on R-Pi, you will

be making use of APIs that are part of Linux,

and they will not exist on a board that is not running Linux.

Still, the core computation method of whether you are in range or not,

and the overall algorithm will remain the same

even if you port to another device, so this is good.

If you need to learn it, two decent (and concise) books

are "The C Programming Language" and "Problem Solving

and Program Design in C".

A microcontroller board that may be worth considering at

some point is this one

https://www.olimex.com/Products/ARM/Atmel/SAM7-P256/

(also available from Farnell).

It has two serial interfaces, and the microcontroller has

a working range of -40 to +85degreesC (storage goes down to -60 degrees C).

It looks about twice the size of the R-pi however (and guessing that space is

a concern in an aircraft). It has 256K of non-volatile storage, but a

512K version is available too. (I've used this microcontroller before, but

I'm sure there are microcontrollers just as good/better too).

It is a prototyping board however, and a smaller PCB could be

laid out. If you've not laid out a board before, it is fairly

straightforward (and I'm sure people would help you).

With the R-pi, since it is running Linux, there may be a few things

that you may want to do. For example, disable all services that you

don't need from starting up. Also, maybe not run it at it's fastest

speed (apparently recent images allow you to select a faster speed

but I've not tried it).

Hi Dave,

I highly recommend purchasing copies of RTCA/DO-254, DESIGN ASSURANCE GUIDANCE FOR AIRBORNE ELECTRONIC HARDWARE and DO-160, Environmental Conditions and Test Procedures for Airborne Equipment before you complete your project  Available from www.rtca.org. They are the current defacto design requirement documents for commercial airborne electronics.  I work for the aerospace group of a Hi-Rel and Military electronics engineering company and we are seeing that even the military avionics jobs are starting to reference DO-254 and DO-160 as requirements.  These documents cover everything from component selection, to EMI/EMC requirements, to mechanical shock and vibe as well as thermal considerations.  If you don't want to shell out that kind of cash, the older, military equivalent of these two specs are MIL-HDBK-5400, MIL-HDBK-454, and MIL-STD-461.  See below for a link on where to obtain these documents

Another good document to obtain would be MIL-STD-704, as it describes the performance of a standard aircraft 28V bus which your power supply must be able to interface with.  This one can be had for free from http://quicksearch.dla.mil/ (*note don't use Chrome to open as it balks at the certificate and wont let you open the actual document).

In addition to the above documents, here are some additional pointers/tips to be mindful of when designing your project.

Component ratings - Industrial temperature ratings are a MUST and full MIL temp ratings are preferred.  Choose parts with the widest temperature range possible.  Verify that all can survive storage between -55°C and +125°C. Choose parts that the manufacturer has designated as MIL/Aerospace, Automotive grade, or "Hi-Rel" in that order for reliability purposes.   QPL parts are not necessary and will most likely be cost prohibitive anyway. You mentioned that operation will be in an inhabited environment; that is not always the case.  You have to keep in mind when the plane is first started on a cold Wisconsin January morning where the overnight temperature dropped to -10°F (-23°C) and the box is at thermal equalibrium, or what about when you've left the plane on the runway all day in August and the box is now 105°C from solar loading.  You need to make sure your components can survive those types of conditions if powered up.

If you are wanting to put a display on your project, standard LCD's will NOT cut it.  That will entail finding a supplier who will cut open the cell and ruggedize the glass for you.  You will also need an anti-glare/anti-reflective coating (1.5% specular and 0.2% diffuse) and possibly an ITO heater applied as well.  Brightness needs to be adjustable over at least 0.05 fL to greater than 150 fL (0.1713 nits to 513.9 nits) and have a high-ambient contrast ratio (8000 foot-candle ambient) of 6:1 or better (sunlight readable).  Design eye and viewing angle will depend upon installiation location but standard TN glass should work ok.  Even with ruggedized glass, most glass will delaminate or the polarizers will become damaged above 85°C.  This can become a problem if the display is mounted in a location where solar loading is an issue so try and place the display where it won't be sitting in direct sunlight with the cockpit closed up tight for an extended period of time.

Wire-to-Board connectors should be jackscrew types and not just latching (don't forget the Locktite).  Board-to-Board connectors should be MIL-C-55302 compliant.  I would recommend using a MIL-DTL-38999 style connector for the connections to the box from the aircraft.  They don't have to be M38999 part numbers (expensive), but the style should be used.  They are waterproof, scoop-proof, rugged, and common in aircraft.

Avoid Aluminum Electrolytic or any other wet-dielectric "Can" type capacatiors like the plague.  What happens is that at altitude, where atmospheric pressure is lower, the dielectric heats up, boils to create steam at a lower temperature, expands and ruptures/explodes the can.  Even vented or fail-safe electrolytics are dangerous.  Yes there are some that are aerospace rated, but those are intended for ground support equipment and not flight.  You are better off just using solid tantalum or ceramic instead.

DERATE, DERATE, DERATE your components.  Resistors should be derated by at least 50% for power.  (i.e. if the resistor will dissipate .22W, use a 0.5W resistor minimum).  Capacitors should have their voltage derated by 60%  (use a 20V rated cap for a 12V circuit).  Semiconductors should limit worst case junction temperature to 105°C for IC's and 125°C for transistors  (remember to calculate using the +85°C ambient).  Inductors must be kept below 40°C temperature rise (copper and core losses).  Saturation current is at the discretion of the designer and no specification exists for derating.

Conformal coat your board when you are done.  Aircraft cockpits are notorious for creating lots of condensation inside the equipment.  Especially ones that use outside air for cooling behind the dash.  You should coat your boards prior to installiation so that moisture/condensation doesn't accumulate on your board and cause problems.  Also consider orienting the board vertically when installed so that water can't pool on it during use.  Also, you should put ventalliation and drain holes in the box but remember to keep them small otherwise you'll have an RF leak.

Use an isolated power supply.  You really should use some form of transformer isolated power supply in your box.  A flyback converter is an excellent choice but it will require significant filtering to meet EMI/EMC requirements.  DO-160 details the exact requirements but if you don't want to pay that much for a spec, look up MIL-STD-461.  It has similar EMI/EMC requirements to DO-160.  All connections going into and out of the box will need a ferrite bead as well as some form of LC or RC filter. <EDIT> Upon further reflection, use of an isolated power supply is a MUST since you are utilizing RS-232RS-232 and not RS-422/485 for communications between your GPS and this box.  This is because RS-232RS-232 is single ended, meaning that both pieces of equipment must share a common reference.  If you didn't use an isolated supply off your DC bus, you will most definately have created a ground loop between the two and will burn something out.  RS-422/485 is less susceptiable to this because it is differential but it can still cause problems.  That is why you must use an isolated converter.  You can then reference your system ground to the aircraft 28V return line by way of a high impedance resistor if you like but this way eliminates the potential for ground loops. </EDIT>

Built-In Test (BIT) is also highly recommended.  I don't think I've worked on a project where BIT wasn't a requirement.  You'll need to include some circuitry to verify that your box is working as expected.  Most boxes include 3 different types of BIT, a Power-Up BIT, a Periodic BIT, and an Initiated BIT.  Typical BIT fault detection coverage numbers are 95% of failures with a 99% accuracy (i.e. no false alarms).  In your case, an A/D monitoring supply voltages, current sensors to monitor supply rail currents, a method for injecting and/or looping back RS-232RS-232 data to the processor, a method for detecting an open/short circuited baro sensor, a method for injecting discrete input signals to test any discretes, and an on board temperature sensor should be sufficient for this system.

I hope this helps give you an idea of what actually goes into designing and building avionic equipment.  Let me know if you have any more questions; I will be happy to help.

Shawn

Attachments:

	MIL-STD-704F.pdf
	MIL-STD-461F.pdf
	MIL-HDBK-5400.pdf
	MIL-HDBK-454B.pdf

Hi Dave,

It looks like the ASSIST Websearch site is not working with IE anymore either.  If you have trouble getting the actual PDF's to open, try searching for the military documents here: http://www.landandmaritime.dla.mil/programs/milspec/DocSearch.aspx This usually works but is not always as complete as the ASSIST site.  It should have the major documents I referenced above though.

<EDIT>  I figured out how to get ASSIST QuickSearch to work with Chrome and IE.  You need to download the DOD certificates so that IE and Chrome will authinticate the connection.  They can be downloaded from here: 

http://militarycac.com/dodcerts.htm

Watch the video on how to install them.  Just be sure to restart your browser after install. </EDIT>

Shawn

Shawn, thanks very much for an intelligent and complete response. 

My professional background is in the server industry, where I am an engineering manager in a major server supplier.  I've got quite a bit of background in both the design end (mostly ASIC and custom logic) and more recently in the supply end where I manage NPI (New Product Introduction) engineering and test engineering for basically all the cards (planar and otherwise) that we use.  I've got quite a bit of background in what I would call Server level quality issues - design for manufacturability and design for reliability included.  If I were to be bold, I'd say that commercial Server quality requirements are somewhere betweeen commodity product (your ipad) quality requirements and what you deal with - Aerospace quality requirements.  For the record, I worked my way through college as a technician constructing space and near space based high energy cosmic ray experimental packages.  This work required NASA certification for soldering and wiring techniques.  That's about as close as I can claim to what you are clearly an expert at - the requirments for the true Aerospace industry. 

I also have over 20 years experience building and maintaining experimental aircraft, and through the years I've wired many aircraft, and even built quite a bit of my own avionics systems (mostly digital engine analysis systems).  I'd lay out the operating characteristics of these kinds of planes as follows:

Altititudes range from 0 - 17,500 feet

Temperatures (in the cockpit environment, where the avionics live) range from maybe 10 - 90 degrees F.

AFA humidity, shock/vibration, corrosion (exposure to high salt environments, etc.) - I can't give a clear range.

Avionics systems, even the off the shelf radios we buy and install are typically use standard "D shell" connectors.  Reliability issues I've had with these radios seldom have been connector related - more commonly issues have to do with bad switches, internal batteries, and sometimes display issues. 

In my current panel (picture attached) you will see off the shelf avionics supplied by Garmin, Apollo (a company later purchased by Garmin), Dynon (a supplier to the homebuilt avionics market), and Century (an autopilot manufacturer).  I've been inside the Garmin boxes - my experienced eye would say they are using what I called Server quality levels of construction (at best... some of the things I saw, especially the way some of the cards and components were mounted, were surprisingly bad from a vibration resistance standpoint).  As I said, all of the boxes, including the Garmin (which are FAA certified for use in what we call storebought airplanes) use d-shell connector systems.  For the record, I use aircraft grade mil-spec wire throughout. 

One of the things I should have clarified at the start was that the GPWS - Gear Up! warning system I'm workinging on is (and will remain) completely redundant to the existing warning system that I've been using for over 1000 flight hours in this plane. 

AFA use of the Pi - in many ways I'm ambivelant re. whether it's a Pi or Ardurno or ARM or whatever.  The Pi appealed (and appeals) to me largely because of the SD card slot and the price.  The price allowed me to easily justify purchase of two Pi's - one for the plane and the other for home development work.  The SD slot provides an easy way to move work (and whatever database I wind up using) back and forth. 

At this point I've got most, but not all, of the architecture worked out and I've started playing at implementation.  The big remaining issue I'm working through is as follows... As I may have mentioned in a prior post, the altitude I have access to in either the RS232 stream from the Garmin GPS or the RS232 stream from the Dynon is referenced to MSL (Mean Sea Level).  What I need is an AGL (Above Ground Level) altitude.  To get from MSL to AGL, I need to know and use the MSL altitude of the ground I'm flying over, and then subtract (Aircraft Altitude (MSL) minus Local Terrain Altitude (MSL) equals how far the aircraft is above the local terrain (AGL)). 

I can think of two ways to get the MSL altitude of the terrain I'm over... one is to try and find a terrain altitude database referenced to Lattitude/Longnitude and use that coupled with the Lat/Long output from the GPS.  The second method is more approximate (but simpler) - use the MSL altitude of the airport of destination.  Either method should be workable, but the second is approximate at best, and in mountainous or even hilly areas I worry it could get me into trouble. 

OK... there's a more long winded insight into what I'm working on.  I really appreciate (and respect) your input.  As this is really more or less a fun winter project, and because this is reduntant to the exisiting warning system, I'm perhaps less concerned about applying mil-spec construction techniques to this "toy" application than I am to ensuring it's a project I can work through before flying season really kicks back in...  having said that, you have given me plenty to think about!

Thanks again! 

Dave