What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Homebuilt Avionics

Ebbe

Member
Hi all --

I'm new to this forum, even though I have flown my 7A for a few years, after buying it from the builder. I have seen some talk about homebuilt avionics, so I thought I'd throw my hat in the ring...

Over the last few years I have been designing the different components. It all really started out with an idea of building an autopilot controller and using MGL's servos. As I didn't really have much panel space available on my original steam gauge panel, I realized I had to design a completely new panel from scratch. Steinair cut the panel after I provided an AutoCad drawing.

Boxes are simply mounted by four screws through the panel flange. The EFIS weighs just under 3lbs and has a modest depth of 3" behind the panel, so this way of mounting is good for many more g's than the airframe.

A short description of the different components:

EFIS
A wide angle, high brightness LCD plus an industrial grade single board computer was used, together with controller board that handles front panel controls, brightness, temperature sensor, data bus communication etc. So far, it shows terrain, obstacles, all US airport and runway data, Highway-In-The-Sky to any runway, MFD with airspace, airports, NEXRAD, traffic, sectionals, TAC's.

AHRS
Invensense based IMU, uBlox7 GPS, sensors for static and dynamic air pressure, inputs from a wingtip mounted Honeywell magnetometer and an OAT probe. All processed to produce 60Hz attitude and position, plus 10Hz airdata. A second AHRS will be added later, which will have different components and architecture just in case.

Engine Monitor
A box mounted on the subpanel collects data from EGT, CHT, OP, OT, FP, MP and RPM sensors. I reused Van's existing sensors and had to do a bit research to find out the characteristics on some of them. I had to stoop to some reverse engineering too. Also, a Flowscan provides the fuel flow.

Engine Display + Control Head for Comm & Transp
Displays data from the engine monitor, and also controls a Becker CM-4201 VHF and a Sandia STX-165R transponder. These are mounted behind the baggage bulkhead, together with the AHRS. A COMM2 will be added later. The EFIS sends regularly a frequency list to this display, so that a descriptive name can be displayed next to the frequency ("STP TWR").


Audio Panel
This is a simple two-place intercom, with common functionality for two COMMs and isolation, etc. Automatic squelch level. It also has a voice annunciator for common alerts, like traffic, engine and nav related. I used audio transformers on inputs and outputs to avoid those illusive ground loops. When powered off, pilot's headset and PTT is directly connected to COMM1.
It also records all COMM and intercom audio, engine and AHRS data onto a SD card, all synchronized into one file. A future Windows program will play it all back for post flight analysis....


Autopilot
Two-axis, using MGL's stepper motor servos. This is the part that is not fully completed yet. The plan is to have the standard functionality, such as approaches, holding etc. The AHRS is used as reference. The EFIS will provide guidance for NAV and VNAV features, using the data bus. Without data from the EFIS, the autopilot will fly a heading and maintain or climb/descend to an altitude. It also has outputs for elevator trim, since these servos report back the torque being used.


Other

  • A Pathfinder ADS-B receiver with serial output is mounted on the subpanel, and feeds the four EFIS. It outputs GDL90 format data. So far, the EFIS displays TAF, METAR and NEXRAD. Traffic, winds aloft and NOTAM's will be added when I have time...

  • Two simple LED ramps display trim and flap position. I used the existing Ray Allen potentiometer for trim pos, and installed a conventional linear position sensor for the flaps, right at the flap motor. They are connected to the databus, reporting back position.

  • The databus is CAN, and keeps things in sync between all units -- such as brightness (common for all components), heading and altitude bug, altimeter setting, waypoint data etc.

  • An RC Allen 2600 horizon is used as a backup, with a switch that powers it from a small backup battery. A future miniature airspeed/altimeter/gps box will also use this emergency bus.

  • I have strived for sound designs from the start. All boxes are either steel (0.04), or alodine Al for radiation and RFI shielding. All components are rated for industrial temp range, down to -40C, with exception of the EFIS LCD that only functions down to -25C. Oh, well. So far, no vibration related issues. I guess over 30 years of electronics tinkering has paid off...

- Ebbe

 
Very Impressive!

I am at KANE up north and would love to see your setup! Thinking about doing it is one thing, DOING it is a whole 'nother level.

Great work!
 
That is incredible! I can't begin to imagine the work that went into this, and it looks amazing!

KSGS is my home field, and I have my 10 there. I'd love to check your plane out some time!

Email me if you'd like to meet up, ed.kranz@gmail
 
I'm impressed!

Have you thought of tackling building a GPS navigator that meets the TSO (I think it's 145/146?) requirements for IFR use? There's a real market there for the right box at the right price.
 
Thanks Dan, as the panel looks now, maybe around 6k. But I have gone through a lot of iterations on most of the units to get it where I'm comfortable.

- Ebbe
 
Unreal. Did this guy actually "roll your own" glass cockpit? including sectional map? Haven't seen this before. Very impressive, I imagine by now you've already gotten a couple job offers.
 
This is amazing. I've seen lots of attempts in this space, but you seem to be the first to really pull it off.

Would you mind sharing more details about the construction?
For example: I'm very curious about where you sourced those nice green LED displays and how you handled the mechanical components like the faceplates, buttons, knobs, etc.

Way to go.
David
 
This is amazing. I've seen lots of attempts in this space, but you seem to be the first to really pull it off.

Would you mind sharing more details about the construction?
For example: I'm very curious about where you sourced those nice green LED displays and how you handled the mechanical components like the faceplates, buttons, knobs, etc.

Way to go.
David
David, the square push button switches are all Omron B3W-9002, backlit. LEDs are plain 2mm, flat top. All front panels, including switch and CB panels, are from Front Panel Express. They have an excellent user tool for designing panels, and prices are very reasonable. I know they make the panels for at least one of the big avionics players.

What is really nice with their designs is that you can specify threaded standoffs on the back side, which makes mounting PCB based controls VERY easy.
 
Thanks, Ebbe. I'll have to download their design tool and explore it a bit.

I did a poor job of describing the LEDs I was most curious about. These displays look very neat:

Screen%20Shot%202016-03-24%20at%2012.17.48%20AM_zpsfpr5fn1d.png


Where did you find them? I've always had trouble sourcing nice LCD/LED displays like that in small quantities.

David
 
David, sorry, I didn't read your question fully. They are 5x7 matrix alpha numeric displays from Avago, HDLG series if I remember right. They are readily available from Digikey, and have a parallel interface, which makes interfacing with a micro controller very straight forward.

You may want to check in Newhaven Display too. They have some very nice LCD & OLED modules that can also display graphics. What are you building?

- Ebbe
 
Have you thought of tackling building a GPS navigator that meets the TSO (I think it's 145/146?) requirements for IFR use? There's a real market there for the right box at the right price.

Someone please correct me if I'm wrong, but I believe if there's a TSO requirement, like for IFR GPS navigators or Transponders, then you have to document TSO compliance. That means testing with equipment that most don't have access to.

Having said that, hats off to Ebbe -- that's an awesome panel!
 
...It all really started out with an idea of building an autopilot controller and using MGL's servos...
...
Autopilot
Two-axis, using MGL's stepper motor servos. This is the part that is not fully completed yet...
As an engineer, I can fully appreciate how a project can balloon well beyond its initial purpose, but to go from this to a complete EFIS system? :)

Regardless, this is an amazing accomplishment. I'd love to know how it compares cost-wise to some of the big names (Dynon, GRT, Garmin, MGL) and if you intend to sell kits or plans for the system!
 
Very cool!! :eek: :D We have "kit engines..." How awesome would it be to have "kit avionics" for electronics enthusiasts?
 
Ebbe I also base a RV-8 at KSGS. Remind me to never show you my panel unless you are willing to "tinker" with it.:) You are sir a very talented gentleman.
 
Very cool!! :eek: :D We have "kit engines..." How awesome would it be to have "kit avionics" for electronics enthusiasts?

A modern version of the old Radio Systems Technologies (RST) avionics kits.

One difficulty now is competing with cheap (really cheap) Chinese assembly costs.

The RST stuff did work, I still have a working 6 channel comm. radio (20+ years old) used as a glider base station. :)
 
Someone please correct me if I'm wrong, but I believe if there's a TSO requirement, like for IFR GPS navigators or Transponders, then you have to document TSO compliance. That means testing with equipment that most don't have access to.

Having said that, hats off to Ebbe -- that's an awesome panel!

Yes, according to AC 20-138A which is based on FAA regulations contained in parts 21, 23, 25, 27, 29, 43, 91, 121, and 135 which are regulatory. Of these regulations, only part 91 applies to homebuilt aircraft. So the AIM authorization (which I know is not regulatory) to conduct any GPS operation under IFR requires that:

(a) GPS navigation equipment used must be approved in accordance with the requirements specified in Technical Standard Order (TSO) TSO-C129, or equivalent, and the installation must be done in accordance with Advisory Circular AC 20-138, Airworthiness Approval of Global Positioning System (GPS) Navigation Equipment for Use as a VFR and IFR Supplemental Navigation System, or Advisory Circular AC 20-130A, Airworthiness Approval of Navigation or Flight Management Systems Integrating Multiple Navigation Sensors, or equivalent.

So for our experimental airplanes, GPS equipment must meet the performance requirements of the applicable TSO (in this case, C129), but there is no specific requirement for the equipment to be built under a TSO authorization. However, if the equipment is not built under a TSO authorization, it is up to the owner/operator to verify and document that the equipment performs within the required specifications. It is also the owner or operator's responsibility to document the necessary flight-test data showing that the installation performs within the required accuracy parameters.

THIS is the "Catch-22" that prevents, on a practical basis, someone from providing an equivalent non TSO's GPS navigator. Properly verifying and documenting the necessary test data showing that the installation performs within the required accuracy parameters acceptable to the FAA as "equivalent" to TSO-C129 would be a HUGE and costly undertaking.

But oh how I dream of somebody doing it and releasing us from the grips of big avionic companies.

:(
 
Last edited:
As an engineer, I can fully appreciate how a project can balloon well beyond its initial purpose, but to go from this to a complete EFIS system? :)

Regardless, this is an amazing accomplishment. I'd love to know how it compares cost-wise to some of the big names (Dynon, GRT, Garmin, MGL) and if you intend to sell kits or plans for the system!
Rob,

there are considerable savings to make here. But the driving force for me has always been to have full control over what's going on. Features, looks, ergonomics. Not to mention the shear fun of it.

I'm still debating whether to take it to a commercial level, or just let it all out in the public domain. I wonder what the vote would be here on the forum.... :)


- Ebbe
 
With electronics, a small error in the construction somewhere could lead to an error in the output and might be difficult to pin down. Might not even show up as an obvious mis-indication.

So if you do release plans, I hope that it would include a comprehensive test and debugging section.

Dave
 
With electronics, a small error in the construction somewhere could lead to an error in the output and might be difficult to pin down. Might not even show up as an obvious mis-indication.

So if you do release plans, I hope that it would include a comprehensive test and debugging section.

Dave

RST handled this by having the builder return their assembled kit to get fully tested and get an "FCC Approved" (for the Comm. radio) sticker applied.
 
I want to hear about the underlying software!

Linux core? Some other RTOS? What kind of bus is it? CANBus presumably, but configured how? Industrial-rated components or better? C, C++, ADA, other?

Is the EFIS board COTS? Which one?

If you want to take this "commercial", I certainly hope the experimental kit model of plans & parts would be how it could be sold ... though of course there's the software question ... I think OSS + plans & kits hardware would be a neat way to go ...
 
I want to hear about the underlying software!

Linux core? Some other RTOS? What kind of bus is it? CANBus presumably, but configured how? Industrial-rated components or better? C, C++, ADA, other?

Is the EFIS board COTS? Which one?

If you want to take this "commercial", I certainly hope the experimental kit model of plans & parts would be how it could be sold ... though of course there's the software question ... I think OSS + plans & kits hardware would be a neat way to go ...
JF,

it's currently running under XP Embedded. This was just to get things up and running, and allows for an easy port to CE. All software is written in C. Hardware is an industrial Atom N455 in PC/104 form factor, mounted on the main EFIS board which uses Microchip MCU's for CAN, PWM (brightness), debouncing hardware, level converters (RS-422) etc.

CAN bus is running at 250kb/s. Not sure what you mean by "configured" -- with 20ppm clocks and <1m node lengths, the tq/segment setup is simple. A higher level ACK/NAK protocol is used for critical messages, but most are not, so they are just fired off "one-way".

- Ebbe
 
I am at KANE up north and would love to see your setup! Thinking about doing it is one thing, DOING it is a whole 'nother level.

Great work!
Hi Pete,

Just shoot me an email when you are ready to come down to Fleming. I'm at the north end of the field, right behind the beacon. There most weekends.

- Ebbe
 
Have you thought of tackling building a GPS navigator that meets the TSO (I think it's 145/146?) requirements for IFR use? There's a real market there for the right box at the right price.
Bob,

Help may be on the way. The more I read about it, the more doable it sounds. Another good challenge, not that I need it....

- Ebbe
 
JF,

it's currently running under XP Embedded. This was just to get things up and running, and allows for an easy port to CE. All software is written in C. Hardware is an industrial Atom N455 in PC/104 form factor, mounted on the main EFIS board which uses Microchip MCU's for CAN, PWM (brightness), debouncing hardware, level converters (RS-422) etc.

CAN bus is running at 250kb/s. Not sure what you mean by "configured" -- with 20ppm clocks and <1m node lengths, the tq/segment setup is simple. A higher level ACK/NAK protocol is used for critical messages, but most are not, so they are just fired off "one-way".

- Ebbe

Windows! That's an option ... licensing costs however (They don't seem to sell licenses through their store also) ... but does simplify things greatly ... My efforts in this area have been focused on sticking with "openness" (Linux on Intel with open-source everything) ... it's been a challenge but I am getting closer. Finding a board that does everything COTS is also a challenge. but i did find ways to use PC/104 with the right daughter boards ... not sure how such a setup will endure shock/vibrations though ...

I was wondering whether you used "real-time" canbus (Forget the spec right now ...) ... but looks like no one really bothers.

Anyways, very nice ... that's a whole lot of time spent away from your actual build also ... or was the plane already built when you undertook this challenge?
 
On a different note, I really like the airliner like PFD/MFD/EICAS-like layout ... the screens are far less cluttered ... but it's a tight fit!
 
I contemplated building my own avionics once but gave up when I couldn't find enough vacuum tubes.

FYWJGKNHAWBWLAW.MEDIUM.jpg
 
Last edited:
Wow! You've certainly raised the bar on designing your own panel :)

How well does the AHRS work? Do you use pitot/static or GPS inputs to stabilize the attitude algorithm, or does it manage to maintain stability without any assistance? How well does it realign in flight, if needed?
 
dude! that's impressive. I bought a PLC display a year ago so that I could make an engine monitor but it's been on the back burner. I think there is some opportunity here for the experimental group to benefit.
 
Not so, I have benn flying with a distributed power,trim and flap system for the last few years based on CAN. AIRINC 825 and CANaerospace specs are out there.

Here is the paper I presented at Osh a few years back.
http://jadsystems.com/CANaerospace_OSH_2009_Paper.pdf

I know CAN is used, I meant the scheduling model ... most applications I've seen so far do NOT use the fully deterministic, real-time, scheduling model, but instead just put data on the bus at a slow enough amount that no major contention is expected (The main model I've seen is described in ARINC 825).

I was playing around with a way to schedule and program things to have each node putting things on the bus with fully deterministic timing ... turns out the chipset I used didn't support it ... it's been a while since I played with that though ...

EDIT: There's also the MGL published specs on their CANBus config ...
 
Last edited:
real time can

RT automation on CAN is not difficult. I use markers and timeslots in some other designs but it wasn't really needed given the low data rates for the average GA aircraft
 
Rob,

there are considerable savings to make here. But the driving force for me has always been to have full control over what's going on. Features, looks, ergonomics. Not to mention the shear fun of it.

I'm still debating whether to take it to a commercial level, or just let it all out in the public domain. I wonder what the vote would be here on the forum.... :)


- Ebbe

Hi Ebbe. Awesome work. There is, in fact, a clearing house for open source avionics. MakerPlane provides open source avionics, kits and assembled. products. I licensed my avionics products to them under open-source hardware licensing and I receive a modest royalty on kitset and product revenue.

There is an ongoing open-source EFIS project that is applicable to what you are doing.
 
Not so, I have benn flying with a distributed power,trim and flap system for the last few years based on CAN. AIRINC 825 and CANaerospace specs are out there.

Here is the paper I presented at Osh a few years back.
http://jadsystems.com/CANaerospace_OSH_2009_Paper.pdf
Jim, that's an interesting application you did. Yes, the CAN bus utilization in my case is very low, a few percent at most. And of that, only a fraction is "unsolicited", meaning not initiated by pilot action such as interacting with the user interface. Latency is certainly not a concern here.

- Ebbe
 
Wow! You've certainly raised the bar on designing your own panel :)

How well does the AHRS work? Do you use pitot/static or GPS inputs to stabilize the attitude algorithm, or does it manage to maintain stability without any assistance? How well does it realign in flight, if needed?
Hi Kevin,

oh, boy, could I use a seasoned test pilot of your caliber when testing the autopilot... Having a newly put-together piece of electronics take over the control stick is unnerving.

Yes, the AHRS uses aiding for long-term correction. This particular IMU is not in any way aviation grade, I first got it for experimental purpose. But it had remarkable low noise and good stability, even over large temperature range. Much better than I expected. Introduce the vibration during flight, things deteriorate quite a bit. With turn rate from GPS, and TAS from the airdata, bank is held very accurate. I believe it's the accelerometers more than the gyros that suffer from vibrations. My future, second, AHRS will use a higher end IMU that would need much less "trickery", and maybe even provide acceptable position data for an extended time of GPS outage.

- Ebbe
 
Hi Kevin,

oh, boy, could I use a seasoned test pilot of your caliber when testing the autopilot... Having a newly put-together piece of electronics take over the control stick is unnerving.
- Ebbe
At least the software engineer of your autopilot is exceptionally motivated to design a safe system :)

I assume that the autopilot servos are sized so you can overpower them if required. If not, you should chose different servos, or add some sort of slip clutch between the servos and the controls.

Another thing to think about is the means to disconnect the autopilot. If your normal disconnect switch is working via software, it is wise to have a means to easily kill the electrical power to the servos, in case the software disconnect doesn't work.

Do you have any envelope protection in the autopilot? I.e. maximum and minimum airspeeds that it will stay within, g limits, AOA limits, bank angle limits, etc? If so, it is useful to do the initial testing of the envelope protection with the limits set to values well within the aircraft envelope - e.g., if the max airspeed envelope protection is intended to be at 200 kt TAS, do the initial testing with it set to 180 kt TAS. Once you have validated it works correctly at 180 kt, then reset the threshold to 200 kt for the real test.

Good luck with the testing. If I ever end up in the Saint Paul area, I'll try to track you down (my wife grew up in Green Bay - maybe we'll come up for the Vikings/Packers game).
 
At least the software engineer of your autopilot is exceptionally motivated to design a safe system :)

I assume that the autopilot servos are sized so you can overpower them if required. If not, you should chose different servos, or add some sort of slip clutch between the servos and the controls.

Another thing to think about is the means to disconnect the autopilot. If your normal disconnect switch is working via software, it is wise to have a means to easily kill the electrical power to the servos, in case the software disconnect doesn't work.

Do you have any envelope protection in the autopilot? I.e. maximum and minimum airspeeds that it will stay within, g limits, AOA limits, bank angle limits, etc? If so, it is useful to do the initial testing of the envelope protection with the limits set to values well within the aircraft envelope - e.g., if the max airspeed envelope protection is intended to be at 200 kt TAS, do the initial testing with it set to 180 kt TAS. Once you have validated it works correctly at 180 kt, then reset the threshold to 200 kt for the real test.

Good luck with the testing. If I ever end up in the Saint Paul area, I'll try to track you down (my wife grew up in Green Bay - maybe we'll come up for the Vikings/Packers game).
I wonder how common it is for the control engineer to be strapped on to the system he is tuning...

The servos can fairly easy be overridden, even with the torque setting at the highest value. As soon as I had the servos installed a few years back, I actually tested them with a very rudimentary controller hooked up to a commercially available AHRS -- of not so good quality. In fact it had a bug giving momentary erroneous roll data, which caused my controller software to command close to 100% aileron deflection. At cruise in the RV, it rolled fairly quickly to 90 degrees before I overpowered the servo. Right about that point, I realized that envelope protection would be a great idea.

I have limits to bank, pitch, min and max airspeed that are very conservative since it will be used for instrument flight, which means very gentle flying. Also excessive sink rate will disconnect, but I guess that would be because of an "upstream" software error. No AOA sensor (yet). Also, at the very output I limit the allowable servo deflection to maybe half of the available span -- past those limits would only be used in aerobatic flight, or at very low airspeeds.

There are several ways to disconnect. Disengage switch on stick, and front panel controls, which are software. Power switch to the servos, with a cap color that stands out in the row of switches. Then there is the CB to the servos. Lastly a soft iron shear bolt on the servo arm, which I really hope will never come into play.

- Ebbe
 
Ebbe, I love what you've done and it seems to be leagues above amateur level. Arguably, the engine monitoring system is the single most important avionics to promote safety and reliability of a flying experimental aircraft. Yet, even the non certified EMS units out there are far more expensive than I think they need to be. So, my question is that given your experience with your DIY EMS, how inexpensively could such a system be built? If you were going to open source any of your components, my priority interest would be for an EMS (that can also record the channels).
 
Wow. I hope you do release more information about components, connections, and how you got it all working. This looks AMAZING.
Mind posting a video tour of the setup?
 
Back
Top