What's new
Van's Air Force

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

Homebuilt Avionics 2.0

Ebbe

Member
Hello again!

Since my last post in 2016, I have re-done the panel from scratch. I was not happy with EFIS and Engine Monitor designs. Audio Panel and Autopilot are still the same, but have new front panels to fit with the modified "form factor". As my skills in miniaturizing have improved steadily, I realized I could/should redesign them from scratch.

The new EFIS weighs less than half, uses 30% less power, 2" deep vs. 3", more powerful graphics, starts in 7s vs. 30s. And parts cost approx $400 less per EFIS. How is that for an upgrade? Only thing I could reuse was the LCD panel, unfortunately.

The upgraded engine monitor uses the exact same LCD, but is less powerful than the EFIS.

By having the boxes build out less behind the panel, I could mount them slightly closer to the left/right edges without them hitting the canopy deck. By using even smaller horizontal spacing, and having the mounting holes go above/below the rectangular opening, I could fit five units -- with some space to spare.

Having the mounting holes that close together was a concern. I used the unorthodox approach of a thick panel and threaded holes. A 3/16" panel (6061) and 6-32 provides 6 threads. I tested with a 3/16 piece, and did multiple tightenings with different torque settings on my Ryobi -- no problem. Total weight of the new panel was still less the previous one. Which in turn was well below the original steam gauge panel.

I plan to post all design notes on a separate website (sorry, no complete software will be posted for now), and will be free to use for anyone as maybe a starting point for a similar project.

Can a forum moderator please chime in if this is OK? I don't want do drive traffic away from this site. We can still discuss designs here, but the repository of files would be on a different site.


See you all at Oshkosh. First time flying in for me, so I'll wait to midweek to arrive.

Ebbe

panel_1s.jpg


panel_2s.jpg



[ed. Jaw. On. Floor. Just stunning!!!! v/r,dr]
 
Last edited:
When it comes to avionics, I am not easily impressed. But this is IMPRESSIVE!!!

:cool:
 
Last edited:
I could imagine replacing your screens with 10-12" touch displays and programming the UI with Unity.

Which servos do you use for the AP and how do you interact with them?
 
Last edited:
Hey... are those Omron B3N-9000 series pushbuttons? If so... PM me, I may have a bunch of surplus stock from a product I used to make.
 
I could imagine replacing your screens with 10-12" touch displays and programming the UI with Unity.

Which servos do you use for the AP and how do you interact with them?

Malte,

I use MGL stepper motor servos. They support CAN and RS-232, my controller uses CAN.

Ebbe
 
For lack of a better name, I created the site www.homebuiltavionics.com that has most of the design documents in the Files section. When I have more time after Oshkosh, I'll update it with more descriptive details.

For the PCB's, you'll need Sunstone's free software www.sunstone.com/pcb-resources/pcb-downloads to view and modify the boards.

Some mechanical drawings are in PDF's, but all original design drawings are DWG, so you need AutoCAD. Other (free?) software can probably at least view that file format nowadays.

Front panel files (.FPD) are viewed using Front Panel Express free software. www.frontpanelexpress.com/front_panel_designer/the_idea/
 
Last edited:
awesome project! a dimension of its own 😜

congratulations!
looking forward to reading more, also on the software side of things...
 
For lack of a better name, I create the site www.homebuiltavionics.com that has most of the design documents in the Files section. When I have more time after Oshkosh, I'll update it with more descriptive details.
When you get a chance perhaps you could make a complete package (.zip) that could be downloaded, rather than having to click through the tree one file at a time?

Also, if the plan is to make this an "open" system, maybe you should get in touch with the guys at Experimental Avionics, who have been building a similar (but simpler) system. They have gone to the effort of putting a storefront up to sell pre-made PCB's for their system. Check them out at: https://experimentalavionics.com/

If the plan is to commercialize this into a complete product, that's another matter... But i'm hoping it will remain a DIY system so others can build on it.
 
When you get a chance perhaps you could make a complete package (.zip) that could be downloaded, rather than having to click through the tree one file at a time?

Also, if the plan is to make this an "open" system, maybe you should get in touch with the guys at Experimental Avionics, who have been building a similar (but simpler) system. They have gone to the effort of putting a storefront up to sell pre-made PCB's for their system. Check them out at: https://experimentalavionics.com/

If the plan is to commercialize this into a complete product, that's another matter... But i'm hoping it will remain a DIY system so others can build on it.

Rob, I added a zip package in the root with all files, but I'm not sure it will be kept updated this week with so much going on. May have to automate it somehow.

Spent this morning moving the site over to Go-Daddys. Up until now, all of it was hosted on my own not-so-powerful server in my office. Well, after Doug promoted the thread yesterday afternoon, all h*** broke loose, and almost brought my internet connection to a halt. Certainly didn't expect this onslaught of traffic :)

No commercializing planned. It will stay a DIY project.
 
ebbe, You say that "no complete software will be posted for now..."

How would someone duplicate any of what you've done with out the software? Or is it just that you haven't put together a package yet?
 
ebbe, You say that "no complete software will be posted for now..."

How would someone duplicate any of what you've done with out the software? Or is it just that you haven't put together a package yet?

Rob,

Pretty much all components are a work in progress as far as software goes, maybe with the exception of the audio panel, engine sensor box and trim/flap indicator panels.
The idea was never to give a turnkey solution, to duplicate it right off, rather as inspiration for similar projects. Then there is the liability too. The hardware was probably the biggest hurdle for me to overcome, it was at least for me. So many tries before I felt I got it right. Putting the intelligence inside the boxes is the easy (well...) and fun and creative part.

But I'll gladly share general design ideas on the software, with all aspects like terrain, nav data collection, ADS-B, etc etc. I went from Windows Embedded and Direct3D in my previous version, to Windows CE and OpenGL in the new one. A bit of a learning curve for me on the graphics side, and it was just a month ago I felt I had surpassed the functionality of my previous panel that I have flown with for 3 years. Though the look and feel are very similar, a lot of both hardware and software changes were done based of my experience of actually using it.
 
That's too bad. I was hoping for an "assemble a kit and then tweak the software to my needs" package, not a "here's all the parts, but you have to write all the software from scratch" package.

Without the software starting point, that's like showing someone a picture of an RV, and saying that it was built from 4'x8' sheets of aluminum to encourage others to come up with their own solution. There's a lot of design that has to go into that and I don't think many people here are that capable on the raw design side. But we are all capable (mostly) of ordering PCB's online, fabricating metal parts, wiring things together, etc.

You have a nice-looking system that could probably compete favourably against MGL, Dynon, GRT on the commercial market, if you wanted to turn it into a product. If you don't want to do that, but you are willing to open it to the community, I think it could build a strong user base quite rapidly... Even more so if the parts cost would come in under the parts cost for an equivalent Dynon/GRT/MGL system. I don't think anyone will even try unless they can see that a complete path is there that would take them to a minimum viable product (ie. some kind of basic functionality before tweaking).

That said, i'm curious about the Radio and Transponder displays on your system... Are you just interfacing to remote radio and transponder, or did you build your own radio and transponder as well?
 
The hardware was probably the biggest hurdle for me to overcome, it was at least for me.

8<...

But I'll gladly share general design ideas on the software, with all aspects like terrain, nav data collection, ADS-B, etc etc. I went from Windows Embedded and Direct3D in my previous version, to Windows CE and OpenGL in the new one.
Of course it's your project. You absolutely get to decide what to do with it. I'd like to suggest maybe putting the source on Github so that others can modify and use it. Otherwise I suspect it will forever be a one-off... which may be fine with you, I don't know. It's an amazingly cool project, though.

It sounds like you and I are on close to opposite ends of the scale. For me, the hardware design and implementation would be the easy part. I have the tools, I have the experience. What has kept me from even starting such a thing is the software. I can bang out non-GUI control firmware in C to run on a PIC or similar platform, and I can write some rank amateur level scripts for Linux. I have absolutely no experience or expertise with higher-level OO or GUI programming (and nothing at all in Windows of any flavor), so even with the best hardware it would take me years to come up with the software. That said, I'm usually able to take something that's already been written and make any minor little tweaks I want to see made, even if it's a language in which I have little experience.

There's a ton of space in between. Publishing the hardware design and telling people in general terms what software needs to be written is about as useful to most people as doing the opposite -- "Here's the software, now all you need to do is figure out what to build to run it".
 
When we first released our Enigma EFIS many years ago I was keen to release it as open source. But "life" intervened. My biggest fear was the level of support something like this needs and that needs a lot of time - a luxury I simply do not have.

In the current MX1 thread I talk about this again - this time the hardware is much simpler and I believe open source is an option again as long as I can find somebody that can head this (Kind of like a Linus Torvalds for Avionics).

Open source effectively means open hardware anyway since in order to create anything meaningful on such a device you would have to have a fair understanding of the underlying hardware or else you will not be able to use it effectively.

I believe there would be far more people interested in open source than open hardware as it is much easier to slap together something to develop software on than dealing with the intricacies of modern electronic surface mount components. Case in point: Nobody really would consider building their own raspberry pie computer boards. You'd just go out and buy one and jump right into the software. To make one of these things yourself is possible but fairly pointless unless you specifically want to base a derivative design on something existing.

There are some legal considerations you would be well advised not to ignore in particular if based in the U.S. if you want to release source code or hardware designs for something that goes into an aircraft. This can become a ready made "interest" to some trawling lawyers looking for some extra income in several ways - no matter how you try and protect yourself. You will need to be ready for this. It can be dealt with but make sure you know how.

I really do believe the time is arriving where one or more open source / open hardware avionics developments should be seeded. I believe the combined talent out there, put to good use will benefit experimental aviation greatly and this will feed right into commercial as well at all levels.

But yes - it needs to be both hardware and software. They go together, you cannot isolate them.

The avionics presented in this thread looks really cool - it would be nice if this comes to something more than just a private project (it would seem like a waste of a good effort). There have been several attempts over the years to get something like this going - so far with little real success. This one could make it I think.

Give Ebbe some space to get a bit further along the road, no rush...
 
I believe there would be far more people interested in open source than open hardware as it is much easier to slap together something to develop software on than dealing with the intricacies of modern electronic surface mount components. Case in point: Nobody really would consider building their own raspberry pie computer boards. You'd just go out and buy one and jump right into the software. To make one of these things yourself is possible but fairly pointless unless you specifically want to base a derivative design on something existing.
I think the popularity of the Stratux ADS-B-in system bears that out. A bunch of off-the-shelf hardware, a couple of custom boards (they're making their own AHRS and SDR boards now) and the user puts them together. A default software load to give basic functionality. Open system so *if you want to* you can tweak and modify (i've added an OLED screen and made my own case, for example). It's an excellent base, from which to build.

The avionics presented in this thread looks really cool - it would be nice if this comes to something more than just a private project (it would seem like a waste of a good effort). There have been several attempts over the years to get something like this going - so far with little real success. This one could make it I think.
I agree.
 
That said, i'm curious about the Radio and Transponder displays on your system... Are you just interfacing to remote radio and transponder, or did you build your own radio and transponder as well?

I mounted an avionics bay behind the baggage bulkhead, that has a Becker CM4201 and a Sandia STX-165R remote transponder. Common for these two is that the protocol was published by the manufacturer, which was not very common at the time I started this project. I will replace the Sandia with a Mode S, most likely a Trig TT22 or a uAvionix.
 
I?ve been off grid for a while, so I am just looking at this thread.... nothing short of brilliant stuff!

I share the challenges of the open hardware community. I have recently been considering bringing a Chinese turnkey manufacturer on line, but the current tariff environment (and potential IP theft) makes this marginally viable. There are a few US and Canadian sources who are production cost competitive, but the setup fees are outrageous.

Protos can be hand assembled and volume production can be economical, but the middle ground less than 100 units is just not viable.

I think that within 12 months this problem of IP secure turnkey manufacturers will solved by DigiKey and others, but right now there is not an end to end supplier of Design/PCBs/parts/assembly that works well.

Imagine using your favorite design tool with a supplier?s complete library of manufacturers? approved libraries, then pushing a button to order assembled pc boards. No database munging or manual editing required.

Check back in 12 months.

V
 
As I left Oshkosh this morning, I had the following NEXRAD image on the MFD. I never saw rain -- in the air or hitting the ground.

As per the recommendations, I don't paint level 0 and 1 (no precip), level 2=dark green, level 3=light green, level 4=yellow. It was definitely darker at my 2-o-clock, where the yellow cell was, but I could not see any rain due to the haze. I remember one airport reported virga though (ORD or possibly MSN).

What's your experience from your "real screens" and Foreflight showing NEXRAD data and flying through the lightest level of echos?

nexrad.jpg


Ebbe
 
I'm absolutely floored by your work Ebbe. Very cool!! I have developed an ESP-32 based engine monitor and know all too well the effort it has taken on both the software and hardware side to get it working. I hope you reconsider opening up the software side of things as I would love to help.
 
I'm so impressed and I'm sure there are tons of people out there that haven't posted here that are just as interested as I am !

I love it when someone comes up with an idea that works just as well as the million dollar companies have out there. I remember I was just a teenager when I designed a car alarm system that honked the horn and locked the doors when it went off. It was as big as a shoe box when commercial ones were a little bigger than a pack of cigarettes but it worked and I was so proud. That was back when Radio Shack actually sold components and my hobby was Amateur Radio (KP4JY here).

If you make this open source I'll sure be one of the pilots who will take a look and try to access all the mildewed electronics info in my brain to see how I could help.
 
Did you Look at the APPENDIX C RS-232 TEXT OUTPUT FORMAT in the G3X install manual. It looks like all is available in rs232 format.
 
The original 'FIX' protocol, adopted by Garmin and Dynon for the G3X and SkyView systems was a merger of two proprietary protocols for serial data streams.

Due to feature enhancements and proprietary interests, the two companies have diverged somewhat, but it is still quite possible to grab serial data and build an EFIS 'repeater' that works with either vendor's EFIS. I've done this with several devices over the years.

I've done this over WiFi and BT as well, so that an iThing can be used... but the app development is for someone with more expertise and time than I have. I think Ebbe is on the right track.

V
 
We saw the same thing leaving Osh Friday morning south bound too on our Skyview/Foreflight displays. No precipitation on light or dark green as we flew through it. We did get a few drops when going through a yellow section on the Skyview, which showed as dark green on Foreflight.
 
As I left Oshkosh this morning, I had the following NEXRAD image on the MFD. I never saw rain -- in the air or hitting the ground.

As per the recommendations, I don't paint level 0 and 1 (no precip), level 2=dark green, level 3=light green, level 4=yellow. It was definitely darker at my 2-o-clock, where the yellow cell was, but I could not see any rain due to the haze. I remember one airport reported virga though (ORD or possibly MSN).

What's your experience from your "real screens" and Foreflight showing NEXRAD data and flying through the lightest level of echos?

It's possible - likely even - that the moisture was well above your altitude. A number of times I've been IMC in rain in the flight levels, for example, while airports underneath are reporting "clear below 12,000".
 
It's possible - likely even - that the moisture was well above your altitude. A number of times I've been IMC in rain in the flight levels, for example, while airports underneath are reporting "clear below 12,000".

Thanks ChiefPilot and rvator51 for the feedback. As days crept closer to Wednesday departure for Oshkosh, I scrambled to finish the drawing of NEXRAD data on the MFD screen, and I wasn't sure how it would turn out. One the way up, I also saw numerous small ground clutter spots even when sky was almost clear.
 
As I left Oshkosh this morning, I had the following NEXRAD image on the MFD. I never saw rain -- in the air or hitting the ground.

As per the recommendations, I don't paint level 0 and 1 (no precip), level 2=dark green, level 3=light green, level 4=yellow. It was definitely darker at my 2-o-clock, where the yellow cell was, but I could not see any rain due to the haze. I remember one airport reported virga though (ORD or possibly MSN).

What's your experience from your "real screens" and Foreflight showing NEXRAD data and flying through the lightest level of echos?

nexrad.jpg


Ebbe


Like you, I've seen rain/moisture on my Garmin many times and found out thqt it wasn't nearly as bad as you would think. Looking at the following picture, you would think that I'd be getting the stuffings knocked out of the airplane, but it was a non event. I was between towering cumulus clouds with some precipitation below, but is was fairly smooth air and good visibility the whole way through. Once I was flying in ND and Center warned me of a "line of level 2,3, and 4 precipitation 45 miles ahead". I said I'd stay i=on course and take a look. Other planes were diverting around, but it was high clouds dropping rain that I flew through with no problems. The worst visibility I saw was 40 miles in the rain!! Of course, if there's lightening and real convective activity, I steer way clear.


1196nhd.jpg
 
Like you, I've seen rain/moisture on my Garmin many times and found out thqt it wasn't nearly as bad as you would think. Looking at the following picture, you would think that I'd be getting the stuffings knocked out of the airplane, but it was a non event. I was between towering cumulus clouds with some precipitation below, but is was fairly smooth air and good visibility the whole way through. Once I was flying in ND and Center warned me of a "line of level 2,3, and 4 precipitation 45 miles ahead". I said I'd stay i=on course and take a look. Other planes were diverting around, but it was high clouds dropping rain that I flew through with no problems. The worst visibility I saw was 40 miles in the rain!! Of course, if there's lightening and real convective activity, I steer way clear.


1196nhd.jpg

Thanks Larry, that's good to know. Is the bottom left corner indicating the age of WX data? I display a counter of mm:ss of the radar data age, based on the created time (not received time). Though I'm not sure where in the chain of events that "creation time" comes from.
 
As You alluded no one (at least, no pilot) knows the actual age of the NWS radar data. The standard FAA line is ?no more than 20 minutes, usually less?. Of course a thunderstorm can move and change a lot in that time, hence the usual warning of using this data for strategic decision making, not close in avoidance.
 
What's your experience from your "real screens" and Foreflight showing NEXRAD data and flying through the lightest level of echos?


Ebbe

Exactly as yours, lots of time I'll see the clouds but no actual rain with the green and yellow displayed on the ADSB.
 
As You alluded no one (at least, no pilot) knows the actual age of the NWS radar data. The standard FAA line is ?no more than 20 minutes, usually less?. Of course a thunderstorm can move and change a lot in that time, hence the usual warning of using this data for strategic decision making, not close in avoidance.

Yes, I never understood why they couldn't pass the creation time along to the end user. There is a field that I'm reading, but it usually shows mush shorter time. Which leads me to believe it's not the actual radar image time, but much later in the processing chain.
 
I have started to add details on the EFIS, how the board and enclosures all are put together: http://homebuiltavionics.com/

I will populate the other sections when I have more time.

Ebbe, it would be great to have a documentation of the architecture of your whole system as well as a description of the subsystems - e.g. which ICs you use for what on every subsystem. :)

Malte
 
Ebbe, it would be great to have a documentation of the architecture of your whole system as well as a description of the subsystems - e.g. which ICs you use for what on every subsystem. :)

Malte

Malte,

That's a good idea. I'll add a high level description of each of the components this coming week. Block diagram style.
 
Ebbe, what's the source of your VFR map and nav data?

Malte,

You are in Germany, right? Maybe this won't be relevant for you, but here it is:

This link is for NASR data
https://www.faa.gov/air_traffic/flight_info/aeronav/aero_data/NASR_Subscription/

- FIX.TXT as fix database
- AWOS.TXT and TWR.TXT are parsed to provide a database for descriptive names for frequencies
- Shape files contain B, C, D and E airspaces. I only render B, C and D.

That package also contains airport and runway data, but I use these files instead:
https://www.faa.gov/airports/airport_safety/airportdata_5010/
You get 4 flat text files: Airports, Runways, Remarks, Schedules. Each airport has one or more runway records, and zero or more remarks and schedule records.



Sectionals charts can be found here:
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
There are georeferencing files included in that package. A batch job in PhotoShop scales these to 70%, and convert them to 256-color BMP's. An application then splits these into 2048x2048 tiles for loading into the EFIS application.

Here is a very good reading on map projections, how to convert a lat/long to (x,y) and vice versa, given the chart projection parameters. It is in the public domain:
https://pubs.er.usgs.gov/publication/pp1395


Obstacles as a flat text file:
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/dof/
When I build my datafile, I exclude obstacles <100' AGL.


Terrain is using SRTM-30 data:
https://dds.cr.usgs.gov/srtm/version2_1/SRTM30/
Processing and drawing terrain is a subject big enough for a whole conference, so don't get me started...
 
ah, I didn't know the FAA publishes everything in a machine readable form. Here in Germany you only get PDFs :(
I think I'll write a plugin for the https://www.openaip.net/ format and X-Plane databases, as there are cheap data providers who derive their data from Jeppesen (e.g. Navigraph, with some hacks you should also be able to get geo referenced approach charts). In the end the avionics are VFR only, so no big issue here.

Thanks for the link to the map projections!

Regarding terrain, I think I'm going to use JAXA AW3D30 data instead of SRTM30. To me it looks like those are of a bit higher quality (see also http://www.imagico.de/map/alos.php). I already wrote some simple code to reformat the data to a flattened matrix of elevation points (int16 for the elevation in meters, resolution 1x1 arcsec - that's 25MB for 1x1° - downsampling should be easy).
For visualization I'm going to take a shortcut: I want to use a Raspberry Pi 4 and OpenGL for rendering 3D and all the UI. The hardware interaction, autopilot control loop etc. will be done on realtime hardware - maybe PICs or STM32 - still have to think about an easy way to reprogram them in circuit via the RPi.
Probably I'll try to build a PFD at first. During development I'm going to feed it with live data from X-Plane.

The only problem: I also have to build the plane while doing that! :D

Malte
 
Last edited:
Back
Top