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!

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,

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).