Thanks, Phil, for everything - I'm still in awe at how cool MakerPlane is. I appreciate your encouragement and all of the answered questions and the help with CAN libraries, writing the spec ... all of it.
I developed a CAN bus driven auto EFI display using a Teensy micro. Now I have an interest in Aviation and this was one of the first things I looked up. This looks great!
Welcome to the world of aviation. I got into the CAN stuff because the engine I'm planning to mount on my airplane is based on an automotive engine that uses a MegaSquirt ECU. When I talked to the owner of the company, he said they didn't really have an engine monitor, but he did send me some documentation about the MegaSquirt CAN protocol. My plan was to make my own Arduino-based engine monitor, but when I saw that there was already a nice, open source display I decided to just use it instead. I'll basically have to have an Arduino that listens to the MegaSquirt messages and then translate them to the CAN-FiX protocol and push them to the MakerPlane service.
@dan_der_flieger yes I am very familiar with the MS hardware myself. It gets really fun when you get into your own board design if you aren't there yet.
@@1972challenger Hah. It's interesting that you say that. Over the past month or so I've designed a couple of PCBs - one that's a CAN Bus hub (you can connect 10 CAN devices to a single board hub with DB-9 connectors) and another that holds an Arduino Nano, a 12V to 5V power regulator, an air pressure differential sensor (for airspeed - or - angle of attack), and a CAN board. I had to learn an open source PCB design software called KiCad and a process for etching the boards for prototyping using household chemicals (vinegar, hydrogen peroxide, and salt). It all works surprisingly well together. And, like you said, it really is fun! Sort of a game to see how I could make all of the traces go where I needed them on a single sided board.
@dan_der_flieger I was going to recommend Kicad lol. I use OshPark for my board manufacturing. They are a little expensive but they can get small prototype quantities out quick. Another thing to note is sometimes the power supplies can be tricky in the auto/plane world esp during cranking up. That's what I found the most tricky. Good luck and maybe we can cross up on a project.
Thanks Dan for pointing me to your video of connecting to stratux. Cleared up a lot. Keep the videos coming as you connect different devices to system.
Dan, thank you sharing this... All this has lit a fire in me to learn more. Currently I fly an IFR certified, experimental Velocity, and I would have no issue running this as PFD but, with battery backed up G5s running in the of a failure go back to G5. Like any instrument at anytime they can fail so backup systems and plans are paramount. However, I am looking to actually using this in a KR2 as a PFD in VFR only conditions with steam gauge air speed and altimeter and if DIY EFIS fails, I continue looking out the window NBD. Certification is just a process not the end all be all.
Thanks for watching, Gabe. Sounds like you have a solid plan to add redundant systems and not rely on any single one (which is a good idea). I'm still not sold on actually using this in my airplane yet, but I've learned a LOT from dabbling with all of the components and that's a good enough reason to play around with it IMO.
It's part of an open source package called MakerPlane (makerplane.org/). Specifically, most of what you see in this video is the pyEFIS project. Here's a link to another one of my videos that describes how to use it and, in particular, how to get AHRS data from a Stratux ADS-B receiver: ua-cam.com/video/AJPfOm8xwjs/v-deo.html And here's another one demonstrating some printed circuit boards I designed for use with the project: ua-cam.com/video/cIsv_dQTMyo/v-deo.html Note that the pyEFIS project was recently updated and has changed a little since I made those videos. I haven't had a chance to play around with it very much yet, so I can't answer any questions about the new version.
Well good for you. Build it and fit it to your plane that would be great to see The only recommendation id have is to make the panel cut out and connector pinout the same as some popular commercial unit which would make it better for if the plane ever gets sold. Good on you for doing this. Its great to see
What are you going to use for the attitude gyro and heading indicator? Is that display sunlight readable? Some of the inexpensive displays wash out in sunlight conditions. Thanks for the video, nice project!
I'm still working on AHRS sensors. I haven't found one that I'm satisfied with yet. But here's a video I posted later that talks about my foray into printed circuit boards, and it includes data from a Bosch BNO055 IMU mounted on a home made PCB. It works pretty well on a bench top, but some people have said the BNO055 can drift a bit. I haven't tested it in flight to verify one way or the other yet. Here's a link to the video I mentioned: ua-cam.com/video/cIsv_dQTMyo/v-deo.htmlsi=ujyPPMq0ijNM-Nq5 As for the display, you are correct. It's not sunlight readable. MakerPlane sells a 5" display that IS sunlight readable for about $100US. I bought this one more for prototyping.
In my case, no. I'm building my own aircraft, called an Experimental Amateur Built (EAB). But that doesn't mean that I'm interested in cutting corners on safety. Before flying with any of this equipment (if I use it) it will be thoroughly tested. I'm still a long way away from building out my panel, which will give me time to determine whether or not I'm happy with how the project is going.
@@dan_der_flieger Me too. FYI we also have sunlight readable 5" LCD displays for Raspberry Pi's that you might be interested in using that would be brighter than your 7". There are also 3D print files available for the cases for various mounting options.
@@johnnicol5009 - yeah, I saw that but I bought the 7" display before I did. So I decided to test it all out with the 7" one I had on hand. When I'm ready to start building out my actual Sonex panel, I'll likely buy the 5" display. I'd prefer a little bigger than 5", but a larger screen that you can't see in the sunlight is just useless weight in the cockpit. :)
The MakerPlane GitHub repository is where I started. There's an Arduino/CAN library (look for CAN-FIX-ArduinoLib) that has example files. github.com/makerplane/CAN-FIX-ArduinoLib My code is based on that, but modified for the hardware I'm using. I have it forked on my GitHub, but that repository is not public right now - it's very much a prototype and I don't want to put that code out there as is. I'm taking a short break from the avionics stuff for a little bit and working on my actual airplane. I'll be back at it soon, though. I don't want to burn myself out so I switch back and forth between the two. Is there a specific code sample you're looking for?
@@dan_der_flieger all understood and very many thanks for the information. I’m just looking to get basic temp and/or pressure data from a sensor module such as a BPM280 via CAN to the EFIS to get me started. I’ll have a good look at the MakerPlane git. Thanks again my friend and I hope all goes well with your projects.
Very attractive displays for the garage. Don't you have to get FAA approval to build it into your aircraft? Where I live the airworthiness certification depends on all components being also approved. Not where you are? I'm curious. Best, Rob in Switzerland
For certified aircraft, absolutely. Even then you can legally add extra solutions under certain circumstances. Usually things that are easily removable like additional tablets do not need approval. I suppose you could leverage that even on certified aircraft to add sensors and displays as long as you leave the certified avionics untouched. As Dan is working on a homebuilt airplane, I suspect he will be operating in the Experimental category of aircraft. And there you can do almost anything. In the U.S. there is the EAA that provides resources on what can work and what won't. In Germany we have something similar in the Oskar Ursinus Vereinigung. For Switzerland I just looked up EAS (Experimental Aviation of Switzerland).
You are correct. My aircraft will be categorized as Experimental Amateur Built (EAB), which allows for non-certified equipment. Obviously, all of this needs continued development and testing before use. I'm only demonstrating the possibility of homebuilt avionics here.
@@dan_der_flieger ... and doing a great job by the looks! 🙂 My background: avionics for Harrier (/AV-8B) and Airbus A-300 and subsequent models' fuel systems while at Smiths Industries (now GE Aviation), ZFT flight simulators from Rediffusion and Thomson-CSF (now L3 and Thales) and most recently Swiss defence radar projects for RUAG AG with Hensoldt & Thales. All the best, Rob in Switzerland
Dan, this is awesome! However, I do have a question for you -- how are you going to connect those circuits in such a way as they remain good and are vibration proof? If you install this in your home built, it will also be subject to temperature extremes. Will that be a problem?
Hey Jeff. Great questions. In another video I posted later I discussed using printed circuit boards and DB-9 connectors for the CAN bus connections. I also added a few other sensor boards to the mix (air speed, angle of attack, and a simple AHRS sensor): ua-cam.com/video/cIsv_dQTMyo/v-deo.html This video was more of a proof of concept showing that it's possible.
Hello Dan, I’m from France and I like very much the way you explain your work. I had installed the pyefis and everything opens fine. I have a BMP280 sensor on an Arduino Uno and I get the data on a Raspberry Pi 4 via a USB connection . In a Thonny script I have the data temperature, pressure, altitude and it’s working fine. My question I want to ask you, in which file of pyefis I have to make changes to display the data from the sensor. I will do the same with the other sensors, but I’m a Little newbie in this and I want to understand this manipulation. Thank you for your response and your projects.
@cosscd7683 - Bon jour. I haven't tried to directly connect any sensors to the Raspberry Pi. I've only attached them to Arduino devices and used CAN bus connections. And I haven't used Thonny (I've heard of it, but no experience with it). I'm not sure that pyEFIS/FiX Gateway support what you want to do out of the box. But you'll probably want to do this in the FiX Gateway. Look under the plugins area and to find some code that does something similar to what you want to do. For example, look at ~/FIX-Gateway/fixgw/plugins/demo/ to get an idea how to get data into the FiX Gateway. The FG database key "ALT" is used for altitude. "CHT11" is cylinder head temperature for your 1st cylinder, "CHT12" is your second cylinder, etc. You'll have to look through the spec to figure out which database keys to use for the data you want to use.
Thank you for your response. You just connected sensors to Arduino and the Can connexions and the pyEfis program starts showing your sensors data on the screen without any other manipulation, is it? Can you give me an exemple of how did you do it for the altimeter sensor for exemple? Or can you guide me how can I connect my bmp280 to have data on my efis screen simple without any complications? Best regards@@dan_der_flieger
@@cosscd7683 That's mostly correct. I have a sample program for Arduino that I'll post to my GitHub repository in the next few days. I used an Arduino Leonardo board with a built-in CAN transceiver: a.co/d/ai5J6or And on the Raspberry Pi running the FiX Gateway and pyEFIS, I used a USB CAN interface: a.co/d/e9XDWXj I had to wire the two can interfaces together (two wires - High and Low) and write code on the Arduino that created the CAN messages in the format that the FiX Gateway was expecting. MakerPlane has a useful library for Arduino/CAN/FiX messaging that simplifies it: github.com/makerplane/CAN-FIX-ArduinoLib
@cosscd7683 - Sorry for how long this took to complete, but I have posted my demo code to my github repository: github.com/danderflieger/mcd_can_simple_demo/ Hopefully it's helpful for you.
Dan thanks for your video , how can i connect AHRS ttl module, its better do through gpio or can-interface or usb? and what additional stuff i need ? and how its be may programming for connect pyEfis
The AHRS module I connected was a Bosch IMU that won't work on a fixed wing aircraft. I connected to it with a CAN bus module. You can add an AHRS chip/IMU to a Stratux (using the Raspberry Pi's GPIO pins) and that is more likely to work. That's as far as I've gone at this point - I'm working on my airplane now rather than the EFIS stuff.
@@VVV-AVIATION - I feel the same way, but that's as far as the pyEFIS project has gone at this point. There is another gentleman who is making many improvements to pyEFIS right now. He has integrated an RC aircraft controller which can give attitude indications. See his video here: ua-cam.com/video/ljyaHKs1s2E/v-deo.htmlsi=EQncFiL_lwJpgRu1 He is working on a lot of really good improvements and making very good progress.
Sorry for the question, is this a GUI? Or a full-fledged device with its own ACRS? If with AHRS, then how do you compensate for centrifugal forces in flight?
Hey Ivan. Thanks for watching. This video covers the MakerPlane pyEFIS (yes, the GUI), but also the underlying data transfer components. It uses a CAN-bus derivative called CAN-FiX (also developed and maintained by MakerPlane). Regarding AHRS (I'm not familiar with the term ACRS) ... I don't have an AHRS sensor on the device in this video. But if you watch another video I posted more recently, I have been learning how to design and etch my own circuit boards and one of the boards I made holds an Arduino Nano microcontroller, an Adafruit BNO055 Absolute Orientation Sensor (which is supposed to combine readings from three, 3-axis sensors - an accelerometer, a gyro, and a magnetometer - to determine its heading and attitude), and a CAN bus module. The Arduino gets pitch, roll, and magnetic heading data from the BNO055 sensor and converts it into MakerPlane CAN-FiX formatted messages, which are then pushed to this EFIS screen. As for the compensation for centrifugal forces, the BNO055 is "supposed" to be able to figure that out (e.g. "absolute orientation"). But I haven't yet tested that and I hear it might not work reliably. So I would say that, no, it's not ready for use yet. But if you have a line on a good 9-DOF sensor and solid example Arduino code to combine the readings into accurate, absolute orientation data please let me know. That's probably above my skillset at this point.
You probably could use SDRs for receiving those broadcasts. Transmitting would be a different story, though. You'd need FCC approval to broadcast in anything but publicly available frequency ranges. I'd love to be able to build a my own ADS-B transponder and save a bundle of money, but it doesn't take much effort to imagine how easily someone could use it maliciously and cause all kinds of trouble for others in the NAS by broadcasting false data.
Thanks for this. I always wondered if this was possible. I am not very tech savvy, as a matter of fact, I could be considered tech illiterate, but I am going to try and learn. I cannot say it is impossible for me to do if I never try it.
Pressure differential is commonly used for slip-skid input, with matched port and starboard static ports just forward of the tail [depends on where clean flow is on the particular airframe design]
Pressure differential certainly can be used for slip/skid. My original design for the AoA sensor had two pressure differential sensors (AoA and slip/skid). The second had two wind vanes. Then I realized that the Arduino I was using had a built-in accelerometer that I could use similar to the ball in a general aviation slip/skid indicator, without the mechanical nuances of the wind vane. It's an interesting consideration. Thanks for mentioning it.
@@dan_der_flieger Now I'm curious why the G-5 equiped airplane I flew bothered with static-port based slip-skid. An accelerometer seems far more simple and reliable to implement. Solid state, no plumbing or clogging. Initial calibration would be simpier for the pressure differential, just set it to zero inside a hanger with no fans turned on. The accelerometer would need to very accurate mounting in both the roll and yaw axis.
The flying club I fly with has two airplanes with dual G5 instruments. The G5, as far as I know, only has ports for pitot/static pressure (airspeed, altitude, and vertical speed), not for slip/skid. Everything else is done with an AHRS sensor. If the one you flew used yaw vales from a pressure differential sensor, it was external to the G5 and probably reported its values over the serial connection. There are a few avionics manufacturers that claim to be able to figure out angle of attack with AHRS data. I think that's a stretch and is very specific to the airframe and under normal flight conditions. Flying through the mountains on a windy day, for example, could produce updrafts and downdrafts that, while your attitude indicator shows straight and level flight, might not coincide with actual angle of attack against the relative wind. Seems like the same could be true with accelerometer-based readings during a slip/skid. But I'm not sure I can think of a specific example of when it would be different from a swaying ball.
@@dan_der_flieger AoA is a different problem. [Accurate] AoA without pressure or vanes would basically require integration of a complete inertial reference system. But even Airbus and Boeing choose a vane or two over all that fuss. Yaw coordination is more of a simple coordinated or not type of information, and transient changes from a gust have little practical importance. AHRS still needs to get its information from somewhere. It was a few years ago. That plane also had an autopilot that may have used the yaw pressure differential, but I don't recall it having a rudder servo (C172N only have ground adjustable yaw-trim tabs). It had a real wide mix of separate avionics upgrades being forced to work together anyway.
That's a very interesting project! One that is connected is flight computers, have you played with the idea or seen some opensource project? I mean like flight computer like Sporty's Electronic E6B Flight Computer, not like autonomous flying.
I use an electronic fight book (EFB) called FltPlan Go that I use for moving digital sectional maps and it includes several E6B functions as well (weight and balance, etc.) It runs on a phone or tablet and it's free on either Android or Apple devices. I'd use for those functions on my tablet and just save this project for in-flight data only.
The simple answer is because of Electromagnetic Interference (EMI). CAN is used in automotive, nautical, and in many cases aerospace applications because it's not as susceptible to EMI as most other data transfer standards. So your signal has a better chance of arriving at its destination without interference. It also allows you to have several sensors and gauges on the same network at the same time (all able to listen to everything going on) which means you can easily add redundant components.
One question I have is about the display, specifically about sceen brightness. A year or two back I investigated the available displays and found that the rating in nits wasn’t that impressive compared to the ratings of the commercial EFIS units on the market.
Yeah, this screen is for prototyping only. MakerPlane sells a 5" sunlight readable one for about $100, which is the best price I've seen for anything sunlight readable. I'm hoping that by the time I'm ready to build out my panel, someone has produced a 7" outdoor screen for about the same price. I'm probably a couple of years away from that.
Have a look at the Orange pi 5 plus. It is much faster than the Rasberry pi 4 and variants can be had with as much as 32GB of lpDDR4 RAM, a pair of M.2 interfaces in addition to an eMMC and micro SD. Further, there are a pair of USB interfaces entering thru different buses that would allow for a pair of each device and CAN bus for redundancy all the way up to the computer. Oh, and they are cheap, $140.00 to the door.
I actually purchased An Orange Pi 5 plus just after making this video. It was really good apart from one issue: After about 8 hours of fighting to get it to recognize the 7" HDMI monitor in this video on the Linux distro (actually ALL of their Linux distro) I gave up and sent the OPi back. It did work flawlessly on the Android image, though, so that inspired me to start developing an Android-based EFIS that is compatible with the MakerPlane message format (FiX). So far I have just a heading indicator and an attitude indicator working. Using an Arduino, I connect to the CAN Bus thru a CAN transceiver, convert each message to a byte array that gets passed to the serial port on the Arduino, which is connected to an OTG adapter on the Android device, where the EFIS app listens for incoming data on the USB/serial port and updates a graphical rendition of the data on the HI/AI screen. I bought a Raspberry Pi 4 once the prices came down a few weeks after playing with the OPi. The RPi works really well, so I may or may not continue development on the Android EFIS.
Bummer you could not get the video sorted! I have one on the way now. Likely won't have an issue like you since I will use a 1080p or 4k monitor. @@dan_der_flieger
@@mikeiver yeah, it has a weird resolution. I think it was 1024x600 or something like that. I plugged it into a normal computer monitor and it worked fine. Just not the little screen.
Hello Flyer Dan, great video thanks for taking your time, you spoke about different sensors for dynamic pressure or tempeature for oil or coolant.. what would those sensors be? Can you use a sealed housing for dynamic pressure on the bmp580 sensor? What about the chinesium temp sensors for egt and cht?
This video is meant to be an example of what's possible. I posted another video a couple of weeks ago demonstrating my foray into printed circuit boards (ua-cam.com/video/cIsv_dQTMyo/v-deo.html). On that video, I showed how I added a couple of air pressure differential sensors (MPXV7007dp) to sensor boards to gather two types of air data: air speed and AoA. The Arduino has several GPIO pins that can be programmed for analog or digital use. In the case of the MPXV7007dp pressure differential sensor, it uses 3 wires - Positive Power (5V), Ground, and an analog reading pin. There are two nipples that you can use to connect pitot/static tubing and the sensor basically gives you a reading of what the difference in pressure between the two lines is. the 7007 denotes that it can read +7 kPa to -7 kPa. If the sensor is reading +7 kPa, the third wire outputs about 4.75V. If it's reading -7 kPa, it outputs about 0.25V. And anywhere between is some number. If there's no pressure difference, it puts out about 2.5V on the reading pin. The Arduino takes that value and does some math to convert it to knots and then pushes it to pyEFIS screen over the CAN bus. There are other sensors that are a better fit for barometric pressure and temperature. The pressure/temperature sensor I used here was just being used as a demo to show that you can collect data from just about any kind of sensor (as long as you know what to expect from it) and convert it into some kind of CAN message to send over to pyEFIS. As far as I know, EGT/CHT sensors would output analog data like the pressure differential sensor I talked about (MPXV7007dp). Probably some range of voltage that increases as the temperature rises, which you would read on some some pin on the Arduino and then convert to a CAN message. Hopefully that's helpful. 🙂
@@dan_der_flieger I really like your videos man!!! continue doing them, specifically about the Linux based EFIS and EMS, the MPXV7007dp sensor is quite more expensive but I guess reliability is something we shouldn´t be cheeping out - I find it hard to follow up all the makerplane github repository I guess is a steep learning curve; you also mentioned that these systems should be as secondary and not primary, you sounded a bit hesitant on having them as primary, you´ve got to remember that the "mechanical" steam gauges we are using today are far less reliable than any electronics- for electronics so long you have a good source there are no moving parts- the accelerometers are quite genius devices - since they are not that expensive you can have parallels sensors ruining for redundancy-
@@Wolves200- I totally agree that the MakerPlane documentation is a little hard to follow. It took me a couple of weeks to get stuff working. I was hoping to take some of the mystery away from a simple installation. Regarding the pressure differential sensor, depending on where you purchase the MPXV7007DP, it's not too expensive. I've seen them on AliExpress for about $15 (www.aliexpress.us/item/3256805054885075.html). By the time you purchase two BMP580s to get a differential reading between the two, you've probably spent that amount already. Regarding primary vs. secondary - the FAA here in the US put out an advisory circular a few years ago that made it easier to install an aftermarket AoA sensor. Instead of needing to be a Supplemental Type Certificate (STC), a certified mechanic can install one and sign off on it - however, the indicator has to be marked with "Not for use as a primary instrument." I agree - solid state electronics are certainly more reliable than mechanical gauges. Parallel sensors do give you redundancy, but can also introduce another problem: if one fails, how do you know which one to trust? What if one of the pressure differential sensors, for example, starts to leak a little from one of the nozzles? It's not easy to know which nozzle on which sensor is reading higher/lower than the other one. So unless you have 3 sensors that you can compare, you might actually be using the wrong data and put yourself in danger that way. Personally, I'd prefer to have a single sensor fail (because it's easier to detect) than to not know which sensor to trust.
@@dan_der_flieger Dude! this is super helpful the info you are sharing it seems you were struggling with same thing I am right now, I super excited to start a project like this-
The cost with EFIS is not based on the price of components and software, they are pretty cheap and even free when it comes to software. The true cost is incurred in calibration of the sensors, repeatability of the design, and reliability. The calibration process requires expensive traceable sources which are certified and checked at regular intervals. The software also needs to be checked by a third party to ensure there are no errors that might cause the system to display erroneous readings or fail at a critical stage of flight. For example, the software must continue to work even at “impossible” aircraft attitudes and speeds. The fact that an aircraft is not designed to exceed certain flight parameters is no guarantee that this cannot happen. So if you are selling a system to consumers, it must work flawlessly 100% of the time, or fail gracefully with full warnings and an in flight reset capability. Obviously developing such a system at a hobbyist level does not need to meet such high standards, and accuracy and reliability are whatever the builder requires to get the job done. Commercial EFIS are not over priced when you consider the requirements they have to meet.
Sure, there are plenty of steps to certification, if that's your goal. This is for those of us that find enjoyment in the creative process afforded to the homebuilt experimental community. If I was interested in paying gobs of money for someone else to do it for me, I'd buy a certified airplane. Or even a Sonex that someone else already built - they don't hold value very well. But that's not why I'm building my own. It's the satisfaction I get from doing something myself and learning from the process. I agree that the components are (relatively) inexpensive, particularly for big names (like Garmin) who can purchase them in bulk. And they have invested heavily in up front engineering costs (as they should). But at this point, you're spending money on a name and their advertising/marketing costs. The certification process is complete, as is the difficult up-front engineering. That egg has already been cracked. At this point it's mostly just software updates. Which (as a professional software developer) isn't free. Admittedly, I'm still not convinced that building my own avionics is the best route. I can buy a nice, well-equipped EFIS from GRT for my Sonex for about $2k that includes moving map, synthetic vision, etc. But every time I open my Kitplane magazine and see a Garmin ad that says that you buy their stuff "for less than you might think" I cringe. They're probably right - I don't think I can afford to. They've convinced us that it's expensive to equip a plane with avionics. But smaller players in the scene prove that it's mostly advertising hype that Garmin and others sell and we're lapping it up. Anyway, I encourage anyone that prefers to buy certified to do it. Aviation is a hobby with inherent risks and everyone has a different level of risk aversion. For my part, I only fly day VFR and I'm not convinced that a Garmin will keep me any safer in that environment than anything I can build on my own.
Nice video Dan, but I agree with Michael comments. We have to be very transparent with the flight community and do not transmit the idea this could be used for real use without strongly alert that the risk is high. Including on certified software and hardware bugs happens and the consecuencies could be catastrophic. I am the first who accuse Garmin and others to have a monopole with overpriced product but they are doing a great job for aviation safety.
True, you can't argue with the safety record. To me, the avionics are not the most dangerous part of an experimental aircraft. You can still fly an airplane if you lose your airspeed indicator (for example). We're trained to use secondary indicators in a situation like that (an AoA for example; or a combination of tach, AI, and VSI). I plan to only fly day VFR, so losing the horizon on my EFIS doesn't matter. I can look out the window and see the actual horizon. But this system is also redundant. I can add a second, 100% independent display that reads all the same sensors for about $150 to ensure that if a screen fails I still have all of the data in front of me. And there's an option to spend another $150 to have a complete set of redundant sensors for the second display. I'm not trying to minimize your and Mike's comments. I really do appreciate them. I just think that for my particular mission, a $20K set of avionics is ridiculous. And like I said to Mike, I'm looking very hard at GRT's stuff. For the amount of time I'm spending on homebuilt avionics, their $2k entry fee for a nice turnkey solution is very appealing. Unfortunately, they don't support ECU data from the engine I'm considering (no one seems to) which is why I started down this road in the first place. Anyway, thanks for your comments and concerns. I appreciate other points of view.
Yes. It's not for certified aircraft. I can fly my ultralight without any instruments in an emergency, but I want certified and maintained instruments. I'm in two minds about an uncertified glass cockpit. It looks cool, but I don't want to rely on something I can't depend on.
Interesting side note. There have been quite a few situations where airliners have crashed and the warning and safety systems have not worked properly. This is because the airplanes have gotten to conditions such as high speed or angles that were implausible so the system would basically just shut down assuming it was in an error state.
Awesome! Would be great if those sensores and arduino/esp32/stm32 would be on one single PCB each which could be ordered at PCBway & co. Making it full redundant with 2 seperate CAN busses and 2 sensors each and 2 independent displays it would be more thrustworth. For Raspberry PI there are extreme expensive SLC SD cards which extreme durabe. Also tuning raspian to avoid logfile writes to SD card could upmthe realibility. Old raspberry PIs are better because you don’t need CpU coolers, which can get loose (glue softens when getting warm) and create a short.
Hi Olaf. I did start playing around with PCBs and demonstrated it in a later video: ua-cam.com/video/cIsv_dQTMyo/v-deo.html It's fun to design and etch the PCBs and it's even more fun when they actually function. 🙂
2:56 With an ambient temp of 88°, that's pretty low! Seriously, now, is there a way to show all four temps on the main display (on one graph)? 'cause you want to catch that 63° one right away
It's open source software, so you have access to the code. You could edit the code on the PFD screen to include different engine information if you wanted to. Personally, I'd just add a second display so I had a backup PFD and/or engine management screen. That way, you have everything in view, but also a backup in case one of your screens dies.
Now if we could design an efficient comms unit based on a software defined radio module with the proper filtering for the output feeding a power amplifier to bring power up to the 5-10 watts needed for aircraft radios. This unit should be capable of transmit as well as receive. Anyone out there have something on the bench yet?
The best one I have found is the MPXV7007DP. www.nxp.com/part/MPXV7007DP It has two ports - one would be used for pitot and the other for static pressure. It can sense up to 7kPa from either nozzle. It's an analog sensor, so you would use an analog port on the Arduino to read the value. The sensor has 8 pads, but you only use 3 of them: +5V, GND, and the output. The output will send a voltage between 0V and +5V, which is read by the Arduino. * 0V = -7kPa of pressure * 2.5V = matching pressure on both nozzles * 5V = +7kPa of pressure Just make sure your Arduino uses 5V logic. Many are 3.3V logic and putting 5V on that GPIO will fry your board. If you have an Arduino with 3.3V logic, you can step the voltage down using a "voltage divider" circuit. It's built using two resistors. Here's a calculator that you can use to figure out which resistors to use to step from 5V down to 3.3V: ohmslawcalculator.com/voltage-divider-calculator But if your Arduino uses 5V logic, you can use the sensor directly - no need to use the voltage divider.
@@dan_der_flieger Thanks a lot for your answering and time, and two more question 1. This all work throw CAN interface correct? (i mean true Air Speed sensor MPXV7007DP) 2. pyEfis work with Stratux and CAN interface (all sensors) at the same time (simultaneously) or not
1. That's how I set it up - air pressure differential sensor to an Arduino with a CAN interface. Then the CAN data is received on the RPi. 2.Yes, it should all work at the same time. The FIX Gateway is designed to collect data from many sources and present it to pyEFIS to display.
@@dan_der_flieger Matek ASPD-4525 i got this, what you think can it work? And what part of arduino i need buy for connect this aspd-4525 to can interface
@@VVV-AVIATION- I've never used that sensor before, but it looks like it would probably work. It seems like it uses an I2C connection, which pretty much all Arduinos support. As far as the Arduino goes, none of them (as far as I know) support CAN directly. You need a CAN transceiver to pass the CAN data. However, Adafruit has two microcontroller boards that have a CAN bus transceiver built in. I've played around with them and they work pretty well. Here's one with an RP2040 microcontroller: www.adafruit.com/product/5724 And here's one with a Cortex M4 (better chip): www.adafruit.com/product/4759 Adafruit also has Arduino libraries and code samples to get you started: learn.adafruit.com/adafruit-feather-m4-can-express
Probably, but I don't have any experience with the Pi 4s. They're hard to come by right now. I'm looking forward to when we can buy them for under $100 again. 🙂
@@georgemellen3026 - they do have a moving map project. I haven't looked at it yet, but once I get to the point where I'm ready to really dig into my panel, I'll look harder: github.com/makerplane/pyAvMap I'm not sure about auto pilot, but here's an old article that says they used to support a servo controller, so I have to think it's possible: www.avweb.com/press-releases/makerplane-and-vx-aviation-introduce-auto-trim-controller-for-dynon-skyview/
I posted another video a few months after this one showing my foray into printed circuit boards. I'm using a Raspberry Pi 4 in that video and it performs much better: ua-cam.com/video/cIsv_dQTMyo/v-deo.html I didn't realize that the RPi 5 could run NVMe. That might actually move me to use one.
I haven't finished watching the whole video yet, but one quick comment for your consideration. I am not an avionics engineer, but I did get my hands a little dirty on a recent work project and learned some things the hard way. I would give a hearty recommendation towards placing your electronics in your airplane and doing some basic EMI/RF interference testing with your transponder and some basic radio calls. Do this early in the project and test this along the way as you make changes and updates. The I2C bits can be especially susceptible to EMI, and the 2-way I2C protocol doesn't lend itself to robust recovery when bits get corrupted, it is even possible to hang your whole bus so badly the only possible way to recover is to reboot (or maybe even power cycle) the host. Even converting I2C to a differential protocol and back (for longer wire runs) leaves you susceptible at both ends. SPI has similar issues, but I think can be more recoverable after corruption. Don't just assume you can buy your way out of EMI issues with better shielding. At this point in my career I just expect that any I2C device or code that depends on I2C data will immediately quit working and never come back the moment the pilot presses the push to talk button. Of course everyone's mileage may vary with this stuff ... EMI is pretty mysterious most of the time. CAN is good.
Interesting. Definitely a good caution. I posted a video more recently that goes over my foray into printed circuit boards. The run for I2C is very short (just a few mm) and I use CAN for the long runs to the peripherals. Obviously, shielded twisted pair will be the wiring of choice to minimize EMI. And even the "long" runs will likely be less than 3ft. But you make a good point ... Testing and moving of components as necessary will need to be done. Thanks for watching.
I agree 100%. Always go slightly nose heavy to make sure it shows a stall when there's not enough relative wind to show a correct angle. If you look at the latest version of my angle of attack sensor, you'll see that the counter weight/wind vane shaft is adjustable so that it can be properly balanced: ua-cam.com/video/qBw1O5ASWJQ/v-deo.htmlsi=nQtAt9RVMFasZ0d_
A lot of (greek to me) words, yah I've heard the words before, but have little idea what they are or how they interact.....I like tech stuff and have learned car tuning programs, PLCs, and such-this is probably not hard to learn, I guess a basic fundamental knowledge may get me started. Just wish I had the time learn it all..... maybe someday, right now need to stay focused on just getting my PPL! Thank you for sharing, has sparked my interest.
It was all Greek to me when I started, too. Lots of reading and trying things out until I found something that worked and then I moved on to the next thing ... and so on until I got to this point. I still have lots to learn before I even consider relying on it for anything. Good luck with the PPL. It'll be the best decision you've ever made.
This is cool but my concern with it wouldn't necessarily be something like having an improper reading on your artificial horizon. My concern would be a situation where it suddenly incorrectly shows that you have no oil pressure and you make a decision to make an emergency landing based on erroneous data. I feel like there are enough things in a cockpit to be concerned with that unreliable instrumentation really shouldn't be one of them.
That's a fair point. I appreciate the comment. How would you mitigate that with any other system (e.g. a steam gauge or a high priced engine monitor)? Or why would this one be any different? I'd use the same oil pressure sender as I would with any other system. It's just a screen that displays the data. And you can add several redundant screens to ensure that if one fails you can still see the same data on another (which is not the case with a steam gauge).
@@dan_der_flieger while a commercially available avionics set up is still susceptible to failure It's probably a lot less likely to fail than a bunch of arduinos and homespun code. As long as the sensor that you use is high quality, even if it's an automotive sensor, it probably is fairly reliable. Overall I think my main concern would just be that when things start going wrong in a cockpit it can cause task saturation and confusion pretty quickly and the amount of unpredictability for failure in a homespun system like that feels pretty vast. A lot of aviation accidents are at least somewhat attributable to pilots simply failing to fly the plane because they're trying to deal with some sort of failure going on. I think the more chances of failures occurring there are the more likely that sort of thing is to happen.
Yeah, I hear you. All good points and I hope others are reading this. While I have been writing this code at home, my day job is to write similar code to collect data from various types of sensors and display that data on multiple types of screens (e.g. injecting data into someone's already existing graphical software - just like I'm doing here). The MakerPlane code base is really well thought out. Arduinos are pretty solid little devices, not much different from what you might find in a high-end avionics device. They just also have other peripherals on the board that make them more accessible to less tech savvy people. And because they're open source hardware, they are fairly inexpensive. But they're pretty bulletproof as long as you don't overpower them or introduce short circuits or whatever. But that's the same with any electronic device. I appreciate your comments.
@@dan_der_flieger Yeah I get that. I Don't do it professionally but I have been messing with electronics including arduino's raspberry pies and what not for many years now and in general they do seem to be pretty robust. And I also understand the concept of an experimental plane. It's experimental for a reason. My dad and I built a KR2 when I was a teenager and there was plenty of stuff in that plane that was one off and of interesting design. Ultimately it's your plane and you're avionics. If you are comfortable with it that's all that matters.
@@DoRC that's cool. I bet that was a great experience to have with your dad. I had to look up what a KR2 was. Looks like a pretty cool little airplane. Did you have to do the fiberglass layup work or did it come as a kit?
This is a very nice project. I dont know if this has been flight tested. Do not underestimate the electrical noise, from all those USB devices and power supplies.
Thanks for watching. It has not been flight tested yet. This is a very early proof of concept. I published another video after this one when I started to design printed circuit boards to hold all of the components. For each board I designed, I included a way to power it from the aircraft's electrical system: ua-cam.com/video/cIsv_dQTMyo/v-deo.html The main reason I like the MakerPlane echo system is that it's designed around a CAN bus network. CAN much less susceptible to EMI than, say, serial or I2C. And it's easily made redundant as well - because all nodes talk to all nodes, it's very easy to just add another node as a backup (a second EFIS screen, for example, in case one fails).
@@dan_der_flieger yes, i know. can bus is pretty much the standard in avionics. my comment was mostly regarding the EMI that can get into the radio coms themselves. still, very nice project. will keep it on my follow list.
Oh, I see. Yeah, it would all be powered from the avionics bus (and grounded to a block), not from USB cables. So hopefully the EMI would be very limited? I'd definitely be thankful to hear other/better options if you have any. 🤔
Good video. Please make a video detailing the install of code onto raspberrypi. Details like which version of Pi OS being used. Use of Python PIP and how to avoid the "pip externally managed environment" message when attempting to load the "geomag" package. Some detail about file structure such as where in home directory files are placed. Makerplane documentation gives basics of install but not much else.
Have you watched my video titled "Connecting a Stratux to the MakerPlane EFIS?" I kind of go over some of that, but I did it on a Ubuntu computer rather than a Raspberry Pi. Here's a link in case you haven't watched it yet: ua-cam.com/video/AJPfOm8xwjs/v-deo.html
Dan, I've watched your video multiple times and have found it so helpful in demystifying CAN Bus. I have a Pulsar XP with steam Gages and would like to have a secondary EFIS. I have two questions, 1-Will this system ultimately take into account the confusing issues produced between inertia and gravity in cheaper EFIS? 2-Do RC flight controllers such as the SpeedyBee F405 with numerous external sensors feeding it data accomplish our objective of EFIS, OBD autopilot etc.?
Hi Ivan. Thanks for watching. I really didn't do a very good job of explaining how all of this works together, so here's an attempt to do so: In the video I connected several Arduino devices to CAN interfaces. The Arduinos were generating CAN messages according to a specification designed by Phil Birkelbach and other people contributing to the MakerPlane community. That specification is called the Flight information eXchange (FiX) specification. The FiX spec takes into account basically every function, sensor reading, etc. you can think of on an airplane. There's a specific message for airspeed. Another for pitch. Another for roll. One for gear position, flap position, etc. I was just looking at the auto pilot commands section of the FiX spec and there are several parameters that FiX allows: Engage, Disconnect, VS Mode, Alt Hold Mode, Alt Select Mode, Heading Increment, Heading Decrement. Additionally other parameters could be sent BY the Autopilot out to servos controlling the aircraft, such as Pitch Trim, Roll Trim, Yaw Trim, Pitch Trim Motor Speed, Roll Trim Motor Speed, and Yaw Trim Motor Speed. What I'm doing in this video is generating mostly mock data (though I'm also pushing some actual sensor data as well) and converting each of those data into a corresponding FiX message. Then I'm publishing the messages over the CAN bus where there's a piece of software called the FiX Gateway (this is one of the many MakerPlane open source projects). In this case, the FiX Gateway is listening to the CAN messages and then publishes those messages to the pyEfis software running on the same computer as the FiX Gateway. Of note, the FiX Gateway can ingest data from other sources too (e.g. not just CAN bus). For example, you can connect it to XPlane and see your simulated aircraft's EFIS data on a separate screen. You can also connect it to a Stratux. If you're not familiar with Stratux, it's an open source ADS-B in device to which many people add an AHRS chip. I have a Stratux with an AHRS chip, but I haven't attempted to connect my FiX Gateway to it yet. I should try that and see how well it works ... hmmm. Anyway, all that said, as long as you can get a data stream from your SpeedyBee, you should be able to fairly easily translate that data to a message that the FiX Gateway can interpret and push to pyEfis. You'll likely use an Arduino to connect to the SpeedyBee's serial connection (assuming it has one for output) and then translate the various bits of data into FiX messages that you would then send down the CAN bus for ingestion into the FiX Gateway. From there, the pyEfis screen will display the data graphically. Hopefully, that's helpful.
@@dan_der_flieger Dan, thank you for your helpful response as I continue expanding my understanding of the subject. I have a Stratus wit AHRS that I put together so I'm a bit familiar with it and have flown some with it. Stratux was my first experience with the world of open source and I'm hooked :) Im quite sure Flight Tech has applied a RC Flight controller to achieve some of the same functions but I'm not familiar enough with the subject to understand the advantages and limitations. In the long run we have very similar goals for our experimental aircraft so I look forward to seeing your progress. Thanks again for sharing your journey.
@@ivanhoyt7757 sure, no problem. After work I connected my laptop up to my Stratux and told the FiX Gateway to listen to it. My pyEfis attitude indicator followed it as I moved it around. Maybe I'll do a quick tutorial covering how to set up a basic EFIS attached to a Stratux if you think it would be worthwhile.
I have always been a bit wary of the idea of using a RPi for an EFIS (or using Linux for it in general) because with most distributions there's so much stuff in there you don't need. I don't like the idea that your EFIS might crash because some process related to printers started filling up a log file and then suddenly you're out of storage. There probably are stripped-down Linux implementations that do target this kind of application, though.
I use a Debian-based distro (Ubuntu) every single day as my primary workstation, and I have for years. Raspbian is another Debian-based distro specific to RPis and it works pretty well. I don't think Linux isn't the issue here, especially on a computer that's disconnected from the internet (and consequently doesn't perform automatic updates that can change things in unexpected ways). In my experience, Raspberry Pis are solid until the microSD card becomes corrupt. And SD cards are notoriously slow compared to other storage types (onboard eMMC for example). So I totally agree - a single Raspberry Pi probably isn't a good idea for real-world use. Using two of them redundantly is a better option, but still a potential failure point (though everything fails eventually). One good thing about microSD cards is that you can have a spare one (or two) tucked away in the airplane that you could simply replace in the event of a failure. But there are also plenty of really good SBCs out there these days that would be a better choice. If I end up using any of this homebuilt stuff for real (which I'm still not 100% committed to yet), I'll be looking in that direction. I still have plenty of aircraft to build before I need to make any decisions about avionics.
You can build your own with Yocto Project. I would definitely do it instead of using the regular RPI distros. I wouldnt use an RPI either for the already mentioned reasons. There are several SBC's with built in memory flash, certainly more reliable, such as the OSD32MP1-BRK.
Is this meant to be a rhetorical question? If not, I genuinely would love to hear the answer to your own question. And please be specific about which components you wouldn't trust and why. If you fly a certified airplane, obviously this isn't an option for you. It's for the experimental homebuilt folks who enjoy designing and building things. I gather you probably aren't interested in that aspect of aviation, though. And I'm 100% OK with that. If you want to pay someone else to do the R&D for you, go for it. There's nothing wrong with that. Please DO buy certified if that's where your comfort level is. But you do realize that every single modern EFIS in existence went thru an experimental phase, right? Somebody had to have an idea, develop it, and then test it in an experimental aircraft before it became certified. This is literally the same thing. I'm just doing it on my own dime because I enjoy the challenge. It's all open source software designed by people that have experience in the industry who have also donated hours upon hours of their time to a worthwhile cause. I'm building up on their gracious effort and suspect that others will build on mine.
@@dan_der_flieger No quote is necessary. It's obvious you're being extremely condescending. The OP said he didn't trust it. Pretty clear to me. I'm not seeing that the OP said anything wrong at all. He didn't attack you or put you down in any way yet you dig into him pretty good and YoU got your undies in a knot and couldn't take it. I wouldn't trust it either. Perhaps something is also wrong with me? Hmm? I think you need to get over yourself chum. Maybe you're just expecting all of your comments to agree with you and stroke your ego. Sorry we didn't follow the strict protocol on that there.....
All good mate youve made a screen display some data, and these days, thats not too hard for a person to do if that person is knowledgeable. To get that to the mainstream you can do viacexperimental aircraft. But ti have a product the average joe will buy takes a whole organisation and support system.
You are 100% correct. I have no intention of selling anything in this video. I'm building a Sonex aircraft from a kit. It is an experimental amateur built (EAB) aircraft. This system would ONLY be for experimental use. And I'm not even committed to using it myself yet. I'm just demonstrating the art of what's possible here in case there are others that have an interest in learning. I work as a software developer collecting sensor data to display on various screens, so this is not new territory for me - the thing that I find really cool is the use of the MakerPlane open source projects/libraries I'm demonstrating here. They've done a good job of designing a standard from the ground up for others to use in their own projects.
Excellent and fun project. BTW it's pronounced like sea-fish or EEFIST. Secondly, there's no way you want screw terminals , USB plugs, or pin headers in your avionics. You might be able to replicate the functionality, but reliability and durability is the hard part. There's a reason avionics are so expensive. Open a Bendix radio up or a garmin nav-comm and have a look at how they're built. Home made is probably just fine for VFR around the pattern but if there's even the slightest chance of inadvertent IMC you'll really want commercial electronics. ( I know I'm g
Hah, yeah, I realized I was mispronouncing it the day after I posted the video. I blame it on having trained with steam gauges I absolutely agree that using bread breadboards and USB connectors is in no way practical in real life. This was only the first step in a long road. I've been working on designing printed circuit boards and posted a video about it shortly after this one. You'll be happy to note that I pronounced EFIS correctly in that one 🙂: ua-cam.com/video/cIsv_dQTMyo/v-deo.html
Yes, it's open source, meaning the code is freely available for anyone to download and manipulate for personal use. Go to MakerPlane.org for more info.
I build similar systems for sim avionics and I just skip CAN and use a serial bus. I still wouldn't trust a RasPi or some of those SBCs even though none of that will ever leave someone's garage or basement let alone the ground. Avionics should run on a dedicated RTOS, not python.
Sounds like some fun stuff. The president of my EAA chapter runs a non-profit STEM program for high school kids and was asking for some help putting together a realistic panel for the simulators. There are some really incredible projects out there to add actual buttons and potentiometers to control a GPS, for example (or whatever), including Gerber files, parts lists, code, etc. Really cool stuff. Anyway, I'm sure you already know this, but in case anyone else is reading this: The beauty of CAN is two-fold: 1. it's less susceptible to EMI noise compared to serial. It uses two separate signal lines - one high, one low - to differentiate between an actual signal and an erroneous one caused by EMI. Serial does not filter that noise very well, which is why CAN is used in vehicular industries. With sims, serial is definitely fine because you're not dealing with anywhere neat the EMI that you will get with an engine spinning an alternator and coils firing spark plugs, etc. 2. it's designed for a many-to-many connection so you can build in as much redundancy into the system as you like (e.g. two SBC EFIS's that ingest the same data in case one EFIS fails) - OR - build several smaller displays that show a single data point (an AoA sensor, for example, or an oil pressure gauge) running on RTOS hardware - OR - (preferably) some combination of both. Redundancy is the answer to the Swiss cheese effect where everything has a potential to fail. The possibilities of failure are holes in the Swiss cheese. By stacking several slices of cheese together, very few holes remain. The number of remaining holes depends on your acceptable level of risk. That said, I agree that RTOS hardware would be the best option for the EFIS. But in my case (as a day VFR-only pilot), two high quality SBCs (not RPis) each connected to a dedicated screen is a risk that I feel is acceptable. Others will have varying degrees of agreement/disagreement with me and I fully support whatever risk they are willing to accept. This is definitely an experimental solution and for those that are risk averse, I suggest you look elsewhere.
Oof. Shots fired. Haha. Don't worry, I'm not offended. I agree, though. With an attitude like that you probably can't. But, hear me out: Before I made my AOA sensor, I'd never done any Bluetooth development - or any Android development. I also hadn't ever used SOLIDWORKS - which was a steep learning curve for me. I also had to learn how to use the 3D printer I bought for my kids a couple of years prior. Before I purchased my Sonex kit, I'd never built an airplane. I've worked on cars and motorcycles and took 4 years of metal fab in high school, but I'd never worked on an airplane before. I've also never taken any kind of class on video production or editing, yet somehow I'm able to churn out an occasional video for UA-cam and have people tell me all the time that the production quality is high. I don't think my videos are all that great, but I enjoy the creative process anyway. Which is most of the reason I do it and why a homebuilt experimental aircraft is appealing to me. Why build an airplane if you don't want to learn something new along the way? Just go buy a Cessna 150 and call it a day. You'll probably save yourself lots of money and frustration if you do. Software development isn't some mysterious magic. You don't need a college degree to learn how to do it. As a matter of fact, I spent 10 years of my life working a full-time job while taking night classes to get a 4-year college degree in "Applied Information Technology" which prepared me for a job in tech support (NOT software development). I spent about 15 years of my career doing that for a living. I've been playing around with Arduinos and Raspberry Pi's for a few years because I think it's interesting. Eventually, it led to my current job. My boss has told me several times since that during my interview, when I mentioned that I like to play around with Arduinos and Raspberry Pi's in my free time, that's when they knew they'd found the right person. Anyone can learn how to do what this video covers if you have a genuine interest and if you aren't afraid to try and fail until you get it right. Maybe you're right: for MOST people the answer might be no, but most people don't build their own airplane either. I believe in you. Don't sell yourself short. 🙂
I hear you. I actually prefer looking at steam gauges - for airspeed, in particular. Most of my flight hours are in two Cessnas owned by a flying club I belong to. We recently upgraded the panels in both airplanes to include a couple of Garmin G5s, which show your airspeed as a tape. I still find myself looking over at the steam ASI instead. It's a lot easier to interpret a needled pointing at 3 o'clock on approach than to read numbers on a tape. But I love that you can have access to *_all_* of the data on an EFIS, too. Ideally, I'd have a little bit of both on my panel.
This video demonstrates a proof of concept. I've made progress since it was posted several months ago. Take a look at some of my newer videos. Obviously this is not in a state for practical use yet. I still have quite a ways to go with my Sonex build (probably years) before I'll be ready for avionics.
The problem you are going to run into, even though this is stupid cheap compared to off the shelf instruments, is certification which will push all this way up and people will have to get the components from certified resellers to be able to have an airworthy legit craft. Otherwise this is great I am sure there are thousands of enthusiast aviators who are kicking themselves for spending thousands on instruments.
There's no certification required in an experimental aircraft, which is what this is intended for. If you're interested in certified stuff, go buy a Cessna built in the 1970s. Experimental aviation is the pathway to innovation. This is just another option for those (like me) building their own airplane and who enjoy electronics and code development, too.
No hardware design auditing, no hardware design verification, no environmental, EMC or standards compliance qualification. No software testing or verification process, critical safety analysis or failure mode testing... Please don't put this on an aircraft.
Great Video Dan! The more people that we can get involved in this the better it will be for all of us.
Thanks, Phil, for everything - I'm still in awe at how cool MakerPlane is. I appreciate your encouragement and all of the answered questions and the help with CAN libraries, writing the spec ... all of it.
I developed a CAN bus driven auto EFI display using a Teensy micro. Now I have an interest in Aviation and this was one of the first things I looked up. This looks great!
Welcome to the world of aviation. I got into the CAN stuff because the engine I'm planning to mount on my airplane is based on an automotive engine that uses a MegaSquirt ECU. When I talked to the owner of the company, he said they didn't really have an engine monitor, but he did send me some documentation about the MegaSquirt CAN protocol. My plan was to make my own Arduino-based engine monitor, but when I saw that there was already a nice, open source display I decided to just use it instead. I'll basically have to have an Arduino that listens to the MegaSquirt messages and then translate them to the CAN-FiX protocol and push them to the MakerPlane service.
@dan_der_flieger yes I am very familiar with the MS hardware myself. It gets really fun when you get into your own board design if you aren't there yet.
@@1972challenger Hah. It's interesting that you say that. Over the past month or so I've designed a couple of PCBs - one that's a CAN Bus hub (you can connect 10 CAN devices to a single board hub with DB-9 connectors) and another that holds an Arduino Nano, a 12V to 5V power regulator, an air pressure differential sensor (for airspeed - or - angle of attack), and a CAN board. I had to learn an open source PCB design software called KiCad and a process for etching the boards for prototyping using household chemicals (vinegar, hydrogen peroxide, and salt). It all works surprisingly well together. And, like you said, it really is fun! Sort of a game to see how I could make all of the traces go where I needed them on a single sided board.
@dan_der_flieger I was going to recommend Kicad lol. I use OshPark for my board manufacturing. They are a little expensive but they can get small prototype quantities out quick. Another thing to note is sometimes the power supplies can be tricky in the auto/plane world esp during cranking up. That's what I found the most tricky. Good luck and maybe we can cross up on a project.
Cool, I'll have to check out OshPark. I haven't tried sending anything out for production yet, just home etching.
Thanks Dan for pointing me to your video of connecting to stratux. Cleared up a lot. Keep the videos coming as you connect different devices to system.
No problem. I'm glad it was helpful.
Dan, thank you sharing this... All this has lit a fire in me to learn more. Currently I fly an IFR certified, experimental Velocity, and I would have no issue running this as PFD but, with battery backed up G5s running in the of a failure go back to G5. Like any instrument at anytime they can fail so backup systems and plans are paramount. However, I am looking to actually using this in a KR2 as a PFD in VFR only conditions with steam gauge air speed and altimeter and if DIY EFIS fails, I continue looking out the window NBD. Certification is just a process not the end all be all.
Thanks for watching, Gabe. Sounds like you have a solid plan to add redundant systems and not rely on any single one (which is a good idea). I'm still not sold on actually using this in my airplane yet, but I've learned a LOT from dabbling with all of the components and that's a good enough reason to play around with it IMO.
I've looking for something like this for a WHILE.
Thank you!
Glad you found it helpful!
Where did you get this or how did you created thi PFD altitude indicator?
It's part of an open source package called MakerPlane (makerplane.org/). Specifically, most of what you see in this video is the pyEFIS project.
Here's a link to another one of my videos that describes how to use it and, in particular, how to get AHRS data from a Stratux ADS-B receiver:
ua-cam.com/video/AJPfOm8xwjs/v-deo.html
And here's another one demonstrating some printed circuit boards I designed for use with the project:
ua-cam.com/video/cIsv_dQTMyo/v-deo.html
Note that the pyEFIS project was recently updated and has changed a little since I made those videos. I haven't had a chance to play around with it very much yet, so I can't answer any questions about the new version.
Very impressive engineering in a field I love.
Well good for you. Build it and fit it to your plane that would be great to see
The only recommendation id have is to make the panel cut out and connector pinout the same as some popular commercial unit which would make it better for if the plane ever gets sold.
Good on you for doing this. Its great to see
Good suggestion, Dave. Thanks!
What are you going to use for the attitude gyro and heading indicator? Is that display sunlight readable? Some of the inexpensive displays wash out in sunlight conditions. Thanks for the video, nice project!
I'm still working on AHRS sensors. I haven't found one that I'm satisfied with yet. But here's a video I posted later that talks about my foray into printed circuit boards, and it includes data from a Bosch BNO055 IMU mounted on a home made PCB. It works pretty well on a bench top, but some people have said the BNO055 can drift a bit. I haven't tested it in flight to verify one way or the other yet. Here's a link to the video I mentioned:
ua-cam.com/video/cIsv_dQTMyo/v-deo.htmlsi=ujyPPMq0ijNM-Nq5
As for the display, you are correct. It's not sunlight readable. MakerPlane sells a 5" display that IS sunlight readable for about $100US. I bought this one more for prototyping.
Great stuff, thanks for posting this!! Have you researched any on the Yamaha Apex or Nytro engines for your build??
I've only taken a cursory look at the Yamaha engines. Should I research more?
Incredible work! Very cool.
Thanks!
Great video. Just a question. Is there any certification required?
In my case, no. I'm building my own aircraft, called an Experimental Amateur Built (EAB). But that doesn't mean that I'm interested in cutting corners on safety. Before flying with any of this equipment (if I use it) it will be thoroughly tested. I'm still a long way away from building out my panel, which will give me time to determine whether or not I'm happy with how the project is going.
Very nice! Great video.
Thanks John. Looking forward to meeting you at some point.
@@dan_der_flieger Me too. FYI we also have sunlight readable 5" LCD displays for Raspberry Pi's that you might be interested in using that would be brighter than your 7". There are also 3D print files available for the cases for various mounting options.
@@johnnicol5009 - yeah, I saw that but I bought the 7" display before I did. So I decided to test it all out with the 7" one I had on hand. When I'm ready to start building out my actual Sonex panel, I'll likely buy the 5" display. I'd prefer a little bigger than 5", but a larger screen that you can't see in the sunlight is just useless weight in the cockpit. :)
Can the code be downloaded for the various Arduino modules that you have connected to the EFIS via the CAN bus?
The MakerPlane GitHub repository is where I started. There's an Arduino/CAN library (look for CAN-FIX-ArduinoLib) that has example files.
github.com/makerplane/CAN-FIX-ArduinoLib
My code is based on that, but modified for the hardware I'm using. I have it forked on my GitHub, but that repository is not public right now - it's very much a prototype and I don't want to put that code out there as is. I'm taking a short break from the avionics stuff for a little bit and working on my actual airplane. I'll be back at it soon, though. I don't want to burn myself out so I switch back and forth between the two.
Is there a specific code sample you're looking for?
@@dan_der_flieger all understood and very many thanks for the information. I’m just looking to get basic temp and/or pressure data from a sensor module such as a BPM280 via CAN to the EFIS to get me started. I’ll have a good look at the MakerPlane git. Thanks again my friend and I hope all goes well with your projects.
Hey, I just realized I didn't reply to this. Here's a code snippet for reading the BMP sensor and converting it to CAN format (specifically the MakerPlane CAN-FiX standard):
Imports:
#include
#include
#include
#include
#include
#include
#define BMP280_ADDRESS 0x76
Adafruit_BMP280 bmp;
#define CAN0_INT 2
// MCP_CAN CAN0(10); // MCP2515 module (8Mhz)
MCP_CAN CAN0(17); // All-in-one (16Mhz)
CanFix cf(0x82);
Within the loop() section:
float oiltemperature = bmp.readTemperature();
unsigned int oiltemp = oiltemperature * 10;
CFParameter pOilTemp;
pOilTemp.type = 0x222;
pOilTemp.index = 0x00;
pOilTemp.fcb = 0x00;
pOilTemp.data[0] = oiltemp;
pOilTemp.data[1] = oiltemp>>8;
pOilTemp.length = 5;
cf.sendParam(pOilTemp);
Hopefully that's helpful. 🙂
Bro why Screen grey not blue? How fix it?
Very attractive displays for the garage. Don't you have to get FAA approval to build it into your aircraft? Where I live the airworthiness certification depends on all components being also approved. Not where you are? I'm curious. Best, Rob in Switzerland
For certified aircraft, absolutely.
Even then you can legally add extra solutions under certain circumstances. Usually things that are easily removable like additional tablets do not need approval. I suppose you could leverage that even on certified aircraft to add sensors and displays as long as you leave the certified avionics untouched.
As Dan is working on a homebuilt airplane, I suspect he will be operating in the Experimental category of aircraft. And there you can do almost anything. In the U.S. there is the EAA that provides resources on what can work and what won't. In Germany we have something similar in the Oskar Ursinus Vereinigung. For Switzerland I just looked up EAS (Experimental Aviation of Switzerland).
You are correct. My aircraft will be categorized as Experimental Amateur Built (EAB), which allows for non-certified equipment. Obviously, all of this needs continued development and testing before use. I'm only demonstrating the possibility of homebuilt avionics here.
@@dan_der_flieger ... and doing a great job by the looks! 🙂 My background: avionics for Harrier (/AV-8B) and Airbus A-300 and subsequent models' fuel systems while at Smiths Industries (now GE Aviation), ZFT flight simulators from Rediffusion and Thomson-CSF (now L3 and Thales) and most recently Swiss defence radar projects for RUAG AG with Hensoldt & Thales. All the best, Rob in Switzerland
Wow, very cool! Sounds like you've had a great career! If you have any pro tips, I'm always open to suggestions.
Awesome video Dan, thanks!
Dan, this is awesome! However, I do have a question for you -- how are you going to connect those circuits in such a way as they remain good and are vibration proof? If you install this in your home built, it will also be subject to temperature extremes. Will that be a problem?
Hey Jeff. Great questions. In another video I posted later I discussed using printed circuit boards and DB-9 connectors for the CAN bus connections. I also added a few other sensor boards to the mix (air speed, angle of attack, and a simple AHRS sensor):
ua-cam.com/video/cIsv_dQTMyo/v-deo.html
This video was more of a proof of concept showing that it's possible.
Hello Dan, I’m from France and I like very much the way you explain your work. I had installed the pyefis and everything opens fine. I have a BMP280 sensor on an Arduino Uno and I get the data on a Raspberry Pi 4 via a USB connection . In a Thonny script I have the data temperature, pressure, altitude and it’s working fine. My question I want to ask you, in which file of pyefis I have to make changes to display the data from the sensor. I will do the same with the other sensors, but I’m a Little newbie in this and I want to understand this manipulation. Thank you for your response and your projects.
@cosscd7683 - Bon jour. I haven't tried to directly connect any sensors to the Raspberry Pi. I've only attached them to Arduino devices and used CAN bus connections. And I haven't used Thonny (I've heard of it, but no experience with it).
I'm not sure that pyEFIS/FiX Gateway support what you want to do out of the box. But you'll probably want to do this in the FiX Gateway. Look under the plugins area and to find some code that does something similar to what you want to do.
For example, look at ~/FIX-Gateway/fixgw/plugins/demo/ to get an idea how to get data into the FiX Gateway. The FG database key "ALT" is used for altitude. "CHT11" is cylinder head temperature for your 1st cylinder, "CHT12" is your second cylinder, etc. You'll have to look through the spec to figure out which database keys to use for the data you want to use.
Thank you for your response. You just connected sensors to Arduino and the Can connexions and the pyEfis program starts showing your sensors data on the screen without any other manipulation, is it? Can you give me an exemple of how did you do it for the altimeter sensor for exemple? Or can you guide me how can I connect my bmp280 to have data on my efis screen simple without any complications? Best regards@@dan_der_flieger
@@cosscd7683 That's mostly correct. I have a sample program for Arduino that I'll post to my GitHub repository in the next few days. I used an Arduino Leonardo board with a built-in CAN transceiver:
a.co/d/ai5J6or
And on the Raspberry Pi running the FiX Gateway and pyEFIS, I used a USB CAN interface:
a.co/d/e9XDWXj
I had to wire the two can interfaces together (two wires - High and Low) and write code on the Arduino that created the CAN messages in the format that the FiX Gateway was expecting. MakerPlane has a useful library for Arduino/CAN/FiX messaging that simplifies it:
github.com/makerplane/CAN-FIX-ArduinoLib
Thank you, Dan, it’s clear for me, I wait for your example post in GitHub for ideas. Have a nice day
@cosscd7683 - Sorry for how long this took to complete, but I have posted my demo code to my github repository: github.com/danderflieger/mcd_can_simple_demo/
Hopefully it's helpful for you.
Dan thanks for your video , how can i connect AHRS ttl module, its better do through gpio or can-interface or usb? and what additional stuff i need ? and how its be may programming for connect pyEfis
The AHRS module I connected was a Bosch IMU that won't work on a fixed wing aircraft. I connected to it with a CAN bus module. You can add an AHRS chip/IMU to a Stratux (using the Raspberry Pi's GPIO pins) and that is more likely to work. That's as far as I've gone at this point - I'm working on my airplane now rather than the EFIS stuff.
@dan_der_flieger but stratus work only through wi fi ? I dont want use wi fi
@@VVV-AVIATION - I feel the same way, but that's as far as the pyEFIS project has gone at this point. There is another gentleman who is making many improvements to pyEFIS right now. He has integrated an RC aircraft controller which can give attitude indications. See his video here:
ua-cam.com/video/ljyaHKs1s2E/v-deo.htmlsi=EQncFiL_lwJpgRu1
He is working on a lot of really good improvements and making very good progress.
@dan_der_flieger Thank you bro 🙏
Sorry for the question, is this a GUI? Or a full-fledged device with its own ACRS? If with AHRS, then how do you compensate for centrifugal forces in flight?
Hey Ivan. Thanks for watching.
This video covers the MakerPlane pyEFIS (yes, the GUI), but also the underlying data transfer components. It uses a CAN-bus derivative called CAN-FiX (also developed and maintained by MakerPlane).
Regarding AHRS (I'm not familiar with the term ACRS) ... I don't have an AHRS sensor on the device in this video. But if you watch another video I posted more recently, I have been learning how to design and etch my own circuit boards and one of the boards I made holds an Arduino Nano microcontroller, an Adafruit BNO055 Absolute Orientation Sensor (which is supposed to combine readings from three, 3-axis sensors - an accelerometer, a gyro, and a magnetometer - to determine its heading and attitude), and a CAN bus module. The Arduino gets pitch, roll, and magnetic heading data from the BNO055 sensor and converts it into MakerPlane CAN-FiX formatted messages, which are then pushed to this EFIS screen.
As for the compensation for centrifugal forces, the BNO055 is "supposed" to be able to figure that out (e.g. "absolute orientation"). But I haven't yet tested that and I hear it might not work reliably. So I would say that, no, it's not ready for use yet. But if you have a line on a good 9-DOF sensor and solid example Arduino code to combine the readings into accurate, absolute orientation data please let me know. That's probably above my skillset at this point.
What would be cool if people could use SDRs to work on TCAS and ILS, VOR
You probably could use SDRs for receiving those broadcasts. Transmitting would be a different story, though. You'd need FCC approval to broadcast in anything but publicly available frequency ranges. I'd love to be able to build a my own ADS-B transponder and save a bundle of money, but it doesn't take much effort to imagine how easily someone could use it maliciously and cause all kinds of trouble for others in the NAS by broadcasting false data.
Thanks for this. I always wondered if this was possible. I am not very tech savvy, as a matter of fact, I could be considered tech illiterate, but I am going to try and learn. I cannot say it is impossible for me to do if I never try it.
No problem. It's definitely possible and a good opportunity to learn something new.
It will really speed up the learning process if there is an online forum where you can display code and ask questions.
Pressure differential is commonly used for slip-skid input, with matched port and starboard static ports just forward of the tail [depends on where clean flow is on the particular airframe design]
Pressure differential certainly can be used for slip/skid. My original design for the AoA sensor had two pressure differential sensors (AoA and slip/skid). The second had two wind vanes. Then I realized that the Arduino I was using had a built-in accelerometer that I could use similar to the ball in a general aviation slip/skid indicator, without the mechanical nuances of the wind vane.
It's an interesting consideration. Thanks for mentioning it.
@@dan_der_flieger Now I'm curious why the G-5 equiped airplane I flew bothered with static-port based slip-skid. An accelerometer seems far more simple and reliable to implement. Solid state, no plumbing or clogging.
Initial calibration would be simpier for the pressure differential, just set it to zero inside a hanger with no fans turned on. The accelerometer would need to very accurate mounting in both the roll and yaw axis.
The flying club I fly with has two airplanes with dual G5 instruments. The G5, as far as I know, only has ports for pitot/static pressure (airspeed, altitude, and vertical speed), not for slip/skid. Everything else is done with an AHRS sensor. If the one you flew used yaw vales from a pressure differential sensor, it was external to the G5 and probably reported its values over the serial connection.
There are a few avionics manufacturers that claim to be able to figure out angle of attack with AHRS data. I think that's a stretch and is very specific to the airframe and under normal flight conditions. Flying through the mountains on a windy day, for example, could produce updrafts and downdrafts that, while your attitude indicator shows straight and level flight, might not coincide with actual angle of attack against the relative wind.
Seems like the same could be true with accelerometer-based readings during a slip/skid. But I'm not sure I can think of a specific example of when it would be different from a swaying ball.
@@dan_der_flieger AoA is a different problem. [Accurate] AoA without pressure or vanes would basically require integration of a complete inertial reference system. But even Airbus and Boeing choose a vane or two over all that fuss.
Yaw coordination is more of a simple coordinated or not type of information, and transient changes from a gust have little practical importance.
AHRS still needs to get its information from somewhere.
It was a few years ago. That plane also had an autopilot that may have used the yaw pressure differential, but I don't recall it having a rudder servo (C172N only have ground adjustable yaw-trim tabs). It had a real wide mix of separate avionics upgrades being forced to work together anyway.
Can you do videos on the Aeromomentum install?
How the engine doing? How you like it?
I haven't purchased the engine yet. I still have a long way to go before I'm ready for a powerplant.
Thanks Dan.. excellent DIY..
Glad it was helpful. Thanks for watching.
This is awesome!
Thanks Al!
That's a very interesting project!
One that is connected is flight computers, have you played with the idea or seen some opensource project?
I mean like flight computer like Sporty's Electronic E6B Flight Computer, not like autonomous flying.
I use an electronic fight book (EFB) called FltPlan Go that I use for moving digital sectional maps and it includes several E6B functions as well (weight and balance, etc.) It runs on a phone or tablet and it's free on either Android or Apple devices. I'd use for those functions on my tablet and just save this project for in-flight data only.
Brilliant!!!
Great project well explained! Son wants to buy a plane after getting pilots license so will be of interest in future.
Good luck to your son!
Since you're building it from scratch, why use CAN and not a protocol the Raspberry Pi supports natively?
The simple answer is because of Electromagnetic Interference (EMI). CAN is used in automotive, nautical, and in many cases aerospace applications because it's not as susceptible to EMI as most other data transfer standards. So your signal has a better chance of arriving at its destination without interference. It also allows you to have several sensors and gauges on the same network at the same time (all able to listen to everything going on) which means you can easily add redundant components.
One question I have is about the display, specifically about sceen brightness. A year or two back I investigated the available displays and found that the rating in nits wasn’t that impressive compared to the ratings of the commercial EFIS units on the market.
Yeah, this screen is for prototyping only. MakerPlane sells a 5" sunlight readable one for about $100, which is the best price I've seen for anything sunlight readable. I'm hoping that by the time I'm ready to build out my panel, someone has produced a 7" outdoor screen for about the same price. I'm probably a couple of years away from that.
Have a look at the Orange pi 5 plus. It is much faster than the Rasberry pi 4 and variants can be had with as much as 32GB of lpDDR4 RAM, a pair of M.2 interfaces in addition to an eMMC and micro SD. Further, there are a pair of USB interfaces entering thru different buses that would allow for a pair of each device and CAN bus for redundancy all the way up to the computer. Oh, and they are cheap, $140.00 to the door.
I actually purchased An Orange Pi 5 plus just after making this video. It was really good apart from one issue: After about 8 hours of fighting to get it to recognize the 7" HDMI monitor in this video on the Linux distro (actually ALL of their Linux distro) I gave up and sent the OPi back.
It did work flawlessly on the Android image, though, so that inspired me to start developing an Android-based EFIS that is compatible with the MakerPlane message format (FiX). So far I have just a heading indicator and an attitude indicator working. Using an Arduino, I connect to the CAN Bus thru a CAN transceiver, convert each message to a byte array that gets passed to the serial port on the Arduino, which is connected to an OTG adapter on the Android device, where the EFIS app listens for incoming data on the USB/serial port and updates a graphical rendition of the data on the HI/AI screen.
I bought a Raspberry Pi 4 once the prices came down a few weeks after playing with the OPi. The RPi works really well, so I may or may not continue development on the Android EFIS.
Bummer you could not get the video sorted! I have one on the way now. Likely won't have an issue like you since I will use a 1080p or 4k monitor. @@dan_der_flieger
@@mikeiver yeah, it has a weird resolution. I think it was 1024x600 or something like that. I plugged it into a normal computer monitor and it worked fine. Just not the little screen.
Hello Flyer Dan, great video thanks for taking your time, you spoke about different sensors for dynamic pressure or tempeature for oil or coolant.. what would those sensors be? Can you use a sealed housing for dynamic pressure on the bmp580 sensor? What about the chinesium temp sensors for egt and cht?
This video is meant to be an example of what's possible. I posted another video a couple of weeks ago demonstrating my foray into printed circuit boards (ua-cam.com/video/cIsv_dQTMyo/v-deo.html). On that video, I showed how I added a couple of air pressure differential sensors (MPXV7007dp) to sensor boards to gather two types of air data: air speed and AoA.
The Arduino has several GPIO pins that can be programmed for analog or digital use. In the case of the MPXV7007dp pressure differential sensor, it uses 3 wires - Positive Power (5V), Ground, and an analog reading pin. There are two nipples that you can use to connect pitot/static tubing and the sensor basically gives you a reading of what the difference in pressure between the two lines is. the 7007 denotes that it can read +7 kPa to -7 kPa. If the sensor is reading +7 kPa, the third wire outputs about 4.75V. If it's reading -7 kPa, it outputs about 0.25V. And anywhere between is some number. If there's no pressure difference, it puts out about 2.5V on the reading pin. The Arduino takes that value and does some math to convert it to knots and then pushes it to pyEFIS screen over the CAN bus. There are other sensors that are a better fit for barometric pressure and temperature. The pressure/temperature sensor I used here was just being used as a demo to show that you can collect data from just about any kind of sensor (as long as you know what to expect from it) and convert it into some kind of CAN message to send over to pyEFIS.
As far as I know, EGT/CHT sensors would output analog data like the pressure differential sensor I talked about (MPXV7007dp). Probably some range of voltage that increases as the temperature rises, which you would read on some some pin on the Arduino and then convert to a CAN message.
Hopefully that's helpful. 🙂
@@dan_der_flieger I really like your videos man!!! continue doing them, specifically about the Linux based EFIS and EMS, the MPXV7007dp sensor is quite more expensive but I guess reliability is something we shouldn´t be cheeping out - I find it hard to follow up all the makerplane github repository I guess is a steep learning curve; you also mentioned that these systems should be as secondary and not primary, you sounded a bit hesitant on having them as primary, you´ve got to remember that the "mechanical" steam gauges we are using today are far less reliable than any electronics- for electronics so long you have a good source there are no moving parts- the accelerometers are quite genius devices - since they are not that expensive you can have parallels sensors ruining for redundancy-
@@Wolves200- I totally agree that the MakerPlane documentation is a little hard to follow. It took me a couple of weeks to get stuff working. I was hoping to take some of the mystery away from a simple installation.
Regarding the pressure differential sensor, depending on where you purchase the MPXV7007DP, it's not too expensive. I've seen them on AliExpress for about $15 (www.aliexpress.us/item/3256805054885075.html). By the time you purchase two BMP580s to get a differential reading between the two, you've probably spent that amount already.
Regarding primary vs. secondary - the FAA here in the US put out an advisory circular a few years ago that made it easier to install an aftermarket AoA sensor. Instead of needing to be a Supplemental Type Certificate (STC), a certified mechanic can install one and sign off on it - however, the indicator has to be marked with "Not for use as a primary instrument."
I agree - solid state electronics are certainly more reliable than mechanical gauges.
Parallel sensors do give you redundancy, but can also introduce another problem: if one fails, how do you know which one to trust? What if one of the pressure differential sensors, for example, starts to leak a little from one of the nozzles? It's not easy to know which nozzle on which sensor is reading higher/lower than the other one. So unless you have 3 sensors that you can compare, you might actually be using the wrong data and put yourself in danger that way. Personally, I'd prefer to have a single sensor fail (because it's easier to detect) than to not know which sensor to trust.
@@dan_der_flieger Dude! this is super helpful the info you are sharing it seems you were struggling with same thing I am right now, I super excited to start a project like this-
@@Wolves200 glad it's helpful.
The cost with EFIS is not based on the price of components and software, they are pretty cheap and even free when it comes to software. The true cost is incurred in calibration of the sensors, repeatability of the design, and reliability. The calibration process requires expensive traceable sources which are certified and checked at regular intervals. The software also needs to be checked by a third party to ensure there are no errors that might cause the system to display erroneous readings or fail at a critical stage of flight. For example, the software must continue to work even at “impossible” aircraft attitudes and speeds. The fact that an aircraft is not designed to exceed certain flight parameters is no guarantee that this cannot happen. So if you are selling a system to consumers, it must work flawlessly 100% of the time, or fail gracefully with full warnings and an in flight reset capability. Obviously developing such a system at a hobbyist level does not need to meet such high standards, and accuracy and reliability are whatever the builder requires to get the job done. Commercial EFIS are not over priced when you consider the requirements they have to meet.
Sure, there are plenty of steps to certification, if that's your goal. This is for those of us that find enjoyment in the creative process afforded to the homebuilt experimental community. If I was interested in paying gobs of money for someone else to do it for me, I'd buy a certified airplane. Or even a Sonex that someone else already built - they don't hold value very well. But that's not why I'm building my own. It's the satisfaction I get from doing something myself and learning from the process.
I agree that the components are (relatively) inexpensive, particularly for big names (like Garmin) who can purchase them in bulk. And they have invested heavily in up front engineering costs (as they should). But at this point, you're spending money on a name and their advertising/marketing costs. The certification process is complete, as is the difficult up-front engineering. That egg has already been cracked. At this point it's mostly just software updates. Which (as a professional software developer) isn't free.
Admittedly, I'm still not convinced that building my own avionics is the best route. I can buy a nice, well-equipped EFIS from GRT for my Sonex for about $2k that includes moving map, synthetic vision, etc.
But every time I open my Kitplane magazine and see a Garmin ad that says that you buy their stuff "for less than you might think" I cringe. They're probably right - I don't think I can afford to. They've convinced us that it's expensive to equip a plane with avionics. But smaller players in the scene prove that it's mostly advertising hype that Garmin and others sell and we're lapping it up.
Anyway, I encourage anyone that prefers to buy certified to do it. Aviation is a hobby with inherent risks and everyone has a different level of risk aversion. For my part, I only fly day VFR and I'm not convinced that a Garmin will keep me any safer in that environment than anything I can build on my own.
Nice video Dan, but I agree with Michael comments. We have to be very transparent with the flight community and do not transmit the idea this could be used for real use without strongly alert that the risk is high. Including on certified software and hardware bugs happens and the consecuencies could be catastrophic. I am the first who accuse Garmin and others to have a monopole with overpriced product but they are doing a great job for aviation safety.
True, you can't argue with the safety record.
To me, the avionics are not the most dangerous part of an experimental aircraft. You can still fly an airplane if you lose your airspeed indicator (for example). We're trained to use secondary indicators in a situation like that (an AoA for example; or a combination of tach, AI, and VSI). I plan to only fly day VFR, so losing the horizon on my EFIS doesn't matter. I can look out the window and see the actual horizon.
But this system is also redundant. I can add a second, 100% independent display that reads all the same sensors for about $150 to ensure that if a screen fails I still have all of the data in front of me. And there's an option to spend another $150 to have a complete set of redundant sensors for the second display.
I'm not trying to minimize your and Mike's comments. I really do appreciate them. I just think that for my particular mission, a $20K set of avionics is ridiculous. And like I said to Mike, I'm looking very hard at GRT's stuff. For the amount of time I'm spending on homebuilt avionics, their $2k entry fee for a nice turnkey solution is very appealing. Unfortunately, they don't support ECU data from the engine I'm considering (no one seems to) which is why I started down this road in the first place.
Anyway, thanks for your comments and concerns. I appreciate other points of view.
Yes. It's not for certified aircraft. I can fly my ultralight without any instruments in an emergency, but I want certified and maintained instruments. I'm in two minds about an uncertified glass cockpit. It looks cool, but I don't want to rely on something I can't depend on.
Interesting side note. There have been quite a few situations where airliners have crashed and the warning and safety systems have not worked properly. This is because the airplanes have gotten to conditions such as high speed or angles that were implausible so the system would basically just shut down assuming it was in an error state.
Great ... for flight simulator cockpits.
Awesome!
Would be great if those sensores and arduino/esp32/stm32 would be on one single PCB each which could be ordered at PCBway & co.
Making it full redundant with 2 seperate CAN busses and 2 sensors each and 2 independent displays it would be more thrustworth. For Raspberry PI there are extreme expensive SLC SD cards which extreme durabe. Also tuning raspian to avoid logfile writes to SD card could upmthe realibility. Old raspberry PIs are better because you don’t need CpU coolers, which can get loose (glue softens when getting warm) and create a short.
Hi Olaf. I did start playing around with PCBs and demonstrated it in a later video:
ua-cam.com/video/cIsv_dQTMyo/v-deo.html
It's fun to design and etch the PCBs and it's even more fun when they actually function. 🙂
2:56 With an ambient temp of 88°, that's pretty low!
Seriously, now, is there a way to show all four temps on the main display (on one graph)? 'cause you want to catch that 63° one right away
It's open source software, so you have access to the code. You could edit the code on the PFD screen to include different engine information if you wanted to. Personally, I'd just add a second display so I had a backup PFD and/or engine management screen. That way, you have everything in view, but also a backup in case one of your screens dies.
Cool.
Now if we could design an efficient comms unit based on a software defined radio module with the proper filtering for the output feeding a power amplifier to bring power up to the 5-10 watts needed for aircraft radios. This unit should be capable of transmit as well as receive. Anyone out there have something on the bench yet?
Yeah, that would be pretty cool. If anyone starts working on that and sees this, please let me know.
Thanks for your perfect video! 😊
Bro, from wich sensor pyEfis can take Air Speed?
The best one I have found is the MPXV7007DP.
www.nxp.com/part/MPXV7007DP
It has two ports - one would be used for pitot and the other for static pressure. It can sense up to 7kPa from either nozzle.
It's an analog sensor, so you would use an analog port on the Arduino to read the value. The sensor has 8 pads, but you only use 3 of them: +5V, GND, and the output. The output will send a voltage between 0V and +5V, which is read by the Arduino.
* 0V = -7kPa of pressure
* 2.5V = matching pressure on both nozzles
* 5V = +7kPa of pressure
Just make sure your Arduino uses 5V logic. Many are 3.3V logic and putting 5V on that GPIO will fry your board. If you have an Arduino with 3.3V logic, you can step the voltage down using a "voltage divider" circuit. It's built using two resistors.
Here's a calculator that you can use to figure out which resistors to use to step from 5V down to 3.3V:
ohmslawcalculator.com/voltage-divider-calculator
But if your Arduino uses 5V logic, you can use the sensor directly - no need to use the voltage divider.
@@dan_der_flieger Thanks a lot for your answering and time, and two more question
1. This all work throw CAN interface correct? (i mean true Air Speed sensor MPXV7007DP)
2. pyEfis work with Stratux and CAN interface (all sensors) at the same time (simultaneously) or not
1. That's how I set it up - air pressure differential sensor to an Arduino with a CAN interface. Then the CAN data is received on the RPi.
2.Yes, it should all work at the same time. The FIX Gateway is designed to collect data from many sources and present it to pyEFIS to display.
@@dan_der_flieger Matek ASPD-4525 i got this, what you think can it work? And what part of arduino i need buy for connect this aspd-4525 to can interface
@@VVV-AVIATION- I've never used that sensor before, but it looks like it would probably work. It seems like it uses an I2C connection, which pretty much all Arduinos support.
As far as the Arduino goes, none of them (as far as I know) support CAN directly. You need a CAN transceiver to pass the CAN data. However, Adafruit has two microcontroller boards that have a CAN bus transceiver built in. I've played around with them and they work pretty well.
Here's one with an RP2040 microcontroller: www.adafruit.com/product/5724
And here's one with a Cortex M4 (better chip):
www.adafruit.com/product/4759
Adafruit also has Arduino libraries and code samples to get you started:
learn.adafruit.com/adafruit-feather-m4-can-express
Nice vid. Think a Pi4 would run it at full speed?
Probably, but I don't have any experience with the Pi 4s. They're hard to come by right now. I'm looking forward to when we can buy them for under $100 again. 🙂
Dan, do you know if Makerplane will support moving map navigation and drive an autopilot?
@@georgemellen3026 - they do have a moving map project. I haven't looked at it yet, but once I get to the point where I'm ready to really dig into my panel, I'll look harder:
github.com/makerplane/pyAvMap
I'm not sure about auto pilot, but here's an old article that says they used to support a servo controller, so I have to think it's possible:
www.avweb.com/press-releases/makerplane-and-vx-aviation-introduce-auto-trim-controller-for-dynon-skyview/
I would like to see the code running on the RPi 4 and the new RPi 5.. The new RPi 5 can boot/run from an NVME SSD…
I posted another video a few months after this one showing my foray into printed circuit boards. I'm using a Raspberry Pi 4 in that video and it performs much better:
ua-cam.com/video/cIsv_dQTMyo/v-deo.html
I didn't realize that the RPi 5 could run NVMe. That might actually move me to use one.
I haven't finished watching the whole video yet, but one quick comment for your consideration. I am not an avionics engineer, but I did get my hands a little dirty on a recent work project and learned some things the hard way. I would give a hearty recommendation towards placing your electronics in your airplane and doing some basic EMI/RF interference testing with your transponder and some basic radio calls. Do this early in the project and test this along the way as you make changes and updates. The I2C bits can be especially susceptible to EMI, and the 2-way I2C protocol doesn't lend itself to robust recovery when bits get corrupted, it is even possible to hang your whole bus so badly the only possible way to recover is to reboot (or maybe even power cycle) the host. Even converting I2C to a differential protocol and back (for longer wire runs) leaves you susceptible at both ends. SPI has similar issues, but I think can be more recoverable after corruption. Don't just assume you can buy your way out of EMI issues with better shielding. At this point in my career I just expect that any I2C device or code that depends on I2C data will immediately quit working and never come back the moment the pilot presses the push to talk button. Of course everyone's mileage may vary with this stuff ... EMI is pretty mysterious most of the time. CAN is good.
Interesting. Definitely a good caution.
I posted a video more recently that goes over my foray into printed circuit boards. The run for I2C is very short (just a few mm) and I use CAN for the long runs to the peripherals. Obviously, shielded twisted pair will be the wiring of choice to minimize EMI. And even the "long" runs will likely be less than 3ft.
But you make a good point ... Testing and moving of components as necessary will need to be done.
Thanks for watching.
Be cautious with an AOA sensor that has enough imbalanced weight to droop with gravity when the airspeed gets low.
I agree 100%. Always go slightly nose heavy to make sure it shows a stall when there's not enough relative wind to show a correct angle.
If you look at the latest version of my angle of attack sensor, you'll see that the counter weight/wind vane shaft is adjustable so that it can be properly balanced:
ua-cam.com/video/qBw1O5ASWJQ/v-deo.htmlsi=nQtAt9RVMFasZ0d_
A lot of (greek to me) words, yah I've heard the words before, but have little idea what they are or how they interact.....I like tech stuff and have learned car tuning programs, PLCs, and such-this is probably not hard to learn, I guess a basic fundamental knowledge may get me started. Just wish I had the time learn it all..... maybe someday, right now need to stay focused on just getting my PPL! Thank you for sharing, has sparked my interest.
It was all Greek to me when I started, too. Lots of reading and trying things out until I found something that worked and then I moved on to the next thing ... and so on until I got to this point. I still have lots to learn before I even consider relying on it for anything. Good luck with the PPL. It'll be the best decision you've ever made.
This is cool but my concern with it wouldn't necessarily be something like having an improper reading on your artificial horizon. My concern would be a situation where it suddenly incorrectly shows that you have no oil pressure and you make a decision to make an emergency landing based on erroneous data.
I feel like there are enough things in a cockpit to be concerned with that unreliable instrumentation really shouldn't be one of them.
That's a fair point. I appreciate the comment. How would you mitigate that with any other system (e.g. a steam gauge or a high priced engine monitor)? Or why would this one be any different? I'd use the same oil pressure sender as I would with any other system. It's just a screen that displays the data. And you can add several redundant screens to ensure that if one fails you can still see the same data on another (which is not the case with a steam gauge).
@@dan_der_flieger while a commercially available avionics set up is still susceptible to failure It's probably a lot less likely to fail than a bunch of arduinos and homespun code.
As long as the sensor that you use is high quality, even if it's an automotive sensor, it probably is fairly reliable.
Overall I think my main concern would just be that when things start going wrong in a cockpit it can cause task saturation and confusion pretty quickly and the amount of unpredictability for failure in a homespun system like that feels pretty vast.
A lot of aviation accidents are at least somewhat attributable to pilots simply failing to fly the plane because they're trying to deal with some sort of failure going on. I think the more chances of failures occurring there are the more likely that sort of thing is to happen.
Yeah, I hear you. All good points and I hope others are reading this.
While I have been writing this code at home, my day job is to write similar code to collect data from various types of sensors and display that data on multiple types of screens (e.g. injecting data into someone's already existing graphical software - just like I'm doing here). The MakerPlane code base is really well thought out. Arduinos are pretty solid little devices, not much different from what you might find in a high-end avionics device. They just also have other peripherals on the board that make them more accessible to less tech savvy people. And because they're open source hardware, they are fairly inexpensive. But they're pretty bulletproof as long as you don't overpower them or introduce short circuits or whatever. But that's the same with any electronic device.
I appreciate your comments.
@@dan_der_flieger Yeah I get that. I Don't do it professionally but I have been messing with electronics including arduino's raspberry pies and what not for many years now and in general they do seem to be pretty robust.
And I also understand the concept of an experimental plane. It's experimental for a reason. My dad and I built a KR2 when I was a teenager and there was plenty of stuff in that plane that was one off and of interesting design.
Ultimately it's your plane and you're avionics. If you are comfortable with it that's all that matters.
@@DoRC that's cool. I bet that was a great experience to have with your dad.
I had to look up what a KR2 was. Looks like a pretty cool little airplane. Did you have to do the fiberglass layup work or did it come as a kit?
This is a very nice project. I dont know if this has been flight tested. Do not underestimate the electrical noise, from all those USB devices and power supplies.
Thanks for watching.
It has not been flight tested yet. This is a very early proof of concept. I published another video after this one when I started to design printed circuit boards to hold all of the components. For each board I designed, I included a way to power it from the aircraft's electrical system:
ua-cam.com/video/cIsv_dQTMyo/v-deo.html
The main reason I like the MakerPlane echo system is that it's designed around a CAN bus network. CAN much less susceptible to EMI than, say, serial or I2C. And it's easily made redundant as well - because all nodes talk to all nodes, it's very easy to just add another node as a backup (a second EFIS screen, for example, in case one fails).
@@dan_der_flieger yes, i know. can bus is pretty much the standard in avionics. my comment was mostly regarding the EMI that can get into the radio coms themselves.
still, very nice project. will keep it on my follow list.
Oh, I see. Yeah, it would all be powered from the avionics bus (and grounded to a block), not from USB cables. So hopefully the EMI would be very limited? I'd definitely be thankful to hear other/better options if you have any. 🤔
Good video. Please make a video detailing the install of code onto raspberrypi. Details like which version of Pi OS being used. Use of Python PIP and how to avoid the "pip externally managed environment" message when attempting to load the "geomag" package. Some detail about file structure such as where in home directory files are placed. Makerplane documentation gives basics of install but not much else.
Have you watched my video titled "Connecting a Stratux to the MakerPlane EFIS?" I kind of go over some of that, but I did it on a Ubuntu computer rather than a Raspberry Pi. Here's a link in case you haven't watched it yet:
ua-cam.com/video/AJPfOm8xwjs/v-deo.html
Thanks 😂❤
Dan, I've watched your video multiple times and have found it so helpful in demystifying CAN Bus. I have a Pulsar XP with steam Gages and would like to have a secondary EFIS. I have two questions, 1-Will this system ultimately take into account the confusing issues produced between inertia and gravity in cheaper EFIS? 2-Do RC flight controllers such as the SpeedyBee F405 with numerous external sensors feeding it data accomplish our objective of EFIS, OBD autopilot etc.?
Hi Ivan. Thanks for watching.
I really didn't do a very good job of explaining how all of this works together, so here's an attempt to do so:
In the video I connected several Arduino devices to CAN interfaces. The Arduinos were generating CAN messages according to a specification designed by Phil Birkelbach and other people contributing to the MakerPlane community. That specification is called the Flight information eXchange (FiX) specification. The FiX spec takes into account basically every function, sensor reading, etc. you can think of on an airplane. There's a specific message for airspeed. Another for pitch. Another for roll. One for gear position, flap position, etc. I was just looking at the auto pilot commands section of the FiX spec and there are several parameters that FiX allows: Engage, Disconnect, VS Mode, Alt Hold Mode, Alt Select Mode, Heading Increment, Heading Decrement. Additionally other parameters could be sent BY the Autopilot out to servos controlling the aircraft, such as Pitch Trim, Roll Trim, Yaw Trim, Pitch Trim Motor Speed, Roll Trim Motor Speed, and Yaw Trim Motor Speed.
What I'm doing in this video is generating mostly mock data (though I'm also pushing some actual sensor data as well) and converting each of those data into a corresponding FiX message. Then I'm publishing the messages over the CAN bus where there's a piece of software called the FiX Gateway (this is one of the many MakerPlane open source projects). In this case, the FiX Gateway is listening to the CAN messages and then publishes those messages to the pyEfis software running on the same computer as the FiX Gateway.
Of note, the FiX Gateway can ingest data from other sources too (e.g. not just CAN bus). For example, you can connect it to XPlane and see your simulated aircraft's EFIS data on a separate screen. You can also connect it to a Stratux. If you're not familiar with Stratux, it's an open source ADS-B in device to which many people add an AHRS chip. I have a Stratux with an AHRS chip, but I haven't attempted to connect my FiX Gateway to it yet. I should try that and see how well it works ... hmmm.
Anyway, all that said, as long as you can get a data stream from your SpeedyBee, you should be able to fairly easily translate that data to a message that the FiX Gateway can interpret and push to pyEfis. You'll likely use an Arduino to connect to the SpeedyBee's serial connection (assuming it has one for output) and then translate the various bits of data into FiX messages that you would then send down the CAN bus for ingestion into the FiX Gateway. From there, the pyEfis screen will display the data graphically.
Hopefully, that's helpful.
@@dan_der_flieger Dan, thank you for your helpful response as I continue expanding my understanding of the subject. I have a Stratus wit AHRS that I put together so I'm a bit familiar with it and have flown some with it. Stratux was my first experience with the world of open source and I'm hooked :) Im quite sure Flight Tech has applied a RC Flight controller to achieve some of the same functions but I'm not familiar enough with the subject to understand the advantages and limitations. In the long run we have very similar goals for our experimental aircraft so I look forward to seeing your progress. Thanks again for sharing your journey.
@@ivanhoyt7757 sure, no problem. After work I connected my laptop up to my Stratux and told the FiX Gateway to listen to it. My pyEfis attitude indicator followed it as I moved it around. Maybe I'll do a quick tutorial covering how to set up a basic EFIS attached to a Stratux if you think it would be worthwhile.
@@dan_der_flieger Sure, I would appreciate it. Enjoying this learning process and excited to start my own experimenting.
💖💖💖💖
I have always been a bit wary of the idea of using a RPi for an EFIS (or using Linux for it in general) because with most distributions there's so much stuff in there you don't need. I don't like the idea that your EFIS might crash because some process related to printers started filling up a log file and then suddenly you're out of storage. There probably are stripped-down Linux implementations that do target this kind of application, though.
I use a Debian-based distro (Ubuntu) every single day as my primary workstation, and I have for years. Raspbian is another Debian-based distro specific to RPis and it works pretty well. I don't think Linux isn't the issue here, especially on a computer that's disconnected from the internet (and consequently doesn't perform automatic updates that can change things in unexpected ways).
In my experience, Raspberry Pis are solid until the microSD card becomes corrupt. And SD cards are notoriously slow compared to other storage types (onboard eMMC for example). So I totally agree - a single Raspberry Pi probably isn't a good idea for real-world use. Using two of them redundantly is a better option, but still a potential failure point (though everything fails eventually). One good thing about microSD cards is that you can have a spare one (or two) tucked away in the airplane that you could simply replace in the event of a failure.
But there are also plenty of really good SBCs out there these days that would be a better choice. If I end up using any of this homebuilt stuff for real (which I'm still not 100% committed to yet), I'll be looking in that direction. I still have plenty of aircraft to build before I need to make any decisions about avionics.
You can build your own with Yocto Project. I would definitely do it instead of using the regular RPI distros. I wouldnt use an RPI either for the already mentioned reasons. There are several SBC's with built in memory flash, certainly more reliable, such as the OSD32MP1-BRK.
Epic
Thanks!
*_I totally trust this in my airplane. Why would I not..........._* 👌🧐🤨🤔😐
Is this meant to be a rhetorical question? If not, I genuinely would love to hear the answer to your own question. And please be specific about which components you wouldn't trust and why.
If you fly a certified airplane, obviously this isn't an option for you. It's for the experimental homebuilt folks who enjoy designing and building things. I gather you probably aren't interested in that aspect of aviation, though. And I'm 100% OK with that. If you want to pay someone else to do the R&D for you, go for it. There's nothing wrong with that. Please DO buy certified if that's where your comfort level is.
But you do realize that every single modern EFIS in existence went thru an experimental phase, right? Somebody had to have an idea, develop it, and then test it in an experimental aircraft before it became certified. This is literally the same thing. I'm just doing it on my own dime because I enjoy the challenge. It's all open source software designed by people that have experience in the industry who have also donated hours upon hours of their time to a worthwhile cause. I'm building up on their gracious effort and suspect that others will build on mine.
@@dan_der_flieger Resorting to personal attacks to prove how awesome your Frankenstein electronics are... Priceless....
@@thecommentary21 please quote one complete sentence from my comment above that was a personal attack against anyone.
@@dan_der_flieger No quote is necessary. It's obvious you're being extremely condescending. The OP said he didn't trust it. Pretty clear to me. I'm not seeing that the OP said anything wrong at all. He didn't attack you or put you down in any way yet you dig into him pretty good and YoU got your undies in a knot and couldn't take it. I wouldn't trust it either. Perhaps something is also wrong with me? Hmm? I think you need to get over yourself chum. Maybe you're just expecting all of your comments to agree with you and stroke your ego. Sorry we didn't follow the strict protocol on that there.....
All good mate youve made a screen display some data, and these days, thats not too hard for a person to do if that person is knowledgeable.
To get that to the mainstream you can do viacexperimental aircraft. But ti have a product the average joe will buy takes a whole organisation and support system.
You are 100% correct. I have no intention of selling anything in this video. I'm building a Sonex aircraft from a kit. It is an experimental amateur built (EAB) aircraft. This system would ONLY be for experimental use. And I'm not even committed to using it myself yet. I'm just demonstrating the art of what's possible here in case there are others that have an interest in learning.
I work as a software developer collecting sensor data to display on various screens, so this is not new territory for me - the thing that I find really cool is the use of the MakerPlane open source projects/libraries I'm demonstrating here. They've done a good job of designing a standard from the ground up for others to use in their own projects.
Excellent and fun project. BTW it's pronounced like sea-fish or EEFIST. Secondly, there's no way you want screw terminals , USB plugs, or pin headers in your avionics. You might be able to replicate the functionality, but reliability and durability is the hard part. There's a reason avionics are so expensive. Open a Bendix radio up or a garmin nav-comm and have a look at how they're built. Home made is probably just fine for VFR around the pattern but if there's even the slightest chance of inadvertent IMC you'll really want commercial electronics. ( I know I'm g
Hah, yeah, I realized I was mispronouncing it the day after I posted the video. I blame it on having trained with steam gauges
I absolutely agree that using bread breadboards and USB connectors is in no way practical in real life. This was only the first step in a long road.
I've been working on designing printed circuit boards and posted a video about it shortly after this one. You'll be happy to note that I pronounced EFIS correctly in that one 🙂:
ua-cam.com/video/cIsv_dQTMyo/v-deo.html
This free software?
Yes, it's open source, meaning the code is freely available for anyone to download and manipulate for personal use. Go to MakerPlane.org for more info.
@@dan_der_flieger thank you sir for information
@@VivoJefindo-id4cj No problem. Thanks for watching.
I build similar systems for sim avionics and I just skip CAN and use a serial bus. I still wouldn't trust a RasPi or some of those SBCs even though none of that will ever leave someone's garage or basement let alone the ground. Avionics should run on a dedicated RTOS, not python.
Sounds like some fun stuff. The president of my EAA chapter runs a non-profit STEM program for high school kids and was asking for some help putting together a realistic panel for the simulators. There are some really incredible projects out there to add actual buttons and potentiometers to control a GPS, for example (or whatever), including Gerber files, parts lists, code, etc. Really cool stuff.
Anyway, I'm sure you already know this, but in case anyone else is reading this: The beauty of CAN is two-fold:
1. it's less susceptible to EMI noise compared to serial. It uses two separate signal lines - one high, one low - to differentiate between an actual signal and an erroneous one caused by EMI. Serial does not filter that noise very well, which is why CAN is used in vehicular industries. With sims, serial is definitely fine because you're not dealing with anywhere neat the EMI that you will get with an engine spinning an alternator and coils firing spark plugs, etc.
2. it's designed for a many-to-many connection so you can build in as much redundancy into the system as you like (e.g. two SBC EFIS's that ingest the same data in case one EFIS fails) - OR - build several smaller displays that show a single data point (an AoA sensor, for example, or an oil pressure gauge) running on RTOS hardware - OR - (preferably) some combination of both. Redundancy is the answer to the Swiss cheese effect where everything has a potential to fail. The possibilities of failure are holes in the Swiss cheese. By stacking several slices of cheese together, very few holes remain. The number of remaining holes depends on your acceptable level of risk.
That said, I agree that RTOS hardware would be the best option for the EFIS. But in my case (as a day VFR-only pilot), two high quality SBCs (not RPis) each connected to a dedicated screen is a risk that I feel is acceptable. Others will have varying degrees of agreement/disagreement with me and I fully support whatever risk they are willing to accept. This is definitely an experimental solution and for those that are risk averse, I suggest you look elsewhere.
Sure you can. IF you are a software developer. So for most people, the simple answer is no.
Oof. Shots fired. Haha. Don't worry, I'm not offended.
I agree, though. With an attitude like that you probably can't. But, hear me out:
Before I made my AOA sensor, I'd never done any Bluetooth development - or any Android development. I also hadn't ever used SOLIDWORKS - which was a steep learning curve for me. I also had to learn how to use the 3D printer I bought for my kids a couple of years prior.
Before I purchased my Sonex kit, I'd never built an airplane. I've worked on cars and motorcycles and took 4 years of metal fab in high school, but I'd never worked on an airplane before.
I've also never taken any kind of class on video production or editing, yet somehow I'm able to churn out an occasional video for UA-cam and have people tell me all the time that the production quality is high. I don't think my videos are all that great, but I enjoy the creative process anyway. Which is most of the reason I do it and why a homebuilt experimental aircraft is appealing to me.
Why build an airplane if you don't want to learn something new along the way? Just go buy a Cessna 150 and call it a day. You'll probably save yourself lots of money and frustration if you do.
Software development isn't some mysterious magic. You don't need a college degree to learn how to do it. As a matter of fact, I spent 10 years of my life working a full-time job while taking night classes to get a 4-year college degree in "Applied Information Technology" which prepared me for a job in tech support (NOT software development). I spent about 15 years of my career doing that for a living.
I've been playing around with Arduinos and Raspberry Pi's for a few years because I think it's interesting. Eventually, it led to my current job. My boss has told me several times since that during my interview, when I mentioned that I like to play around with Arduinos and Raspberry Pi's in my free time, that's when they knew they'd found the right person.
Anyone can learn how to do what this video covers if you have a genuine interest and if you aren't afraid to try and fail until you get it right.
Maybe you're right: for MOST people the answer might be no, but most people don't build their own airplane either.
I believe in you. Don't sell yourself short. 🙂
By the way, I've watched a few of your videos before. Pretty cool stuff, man. Keep em coming.
@@dan_der_fliegerNot a coder myself, more a hardware guy, but Ultibo makes it easier to do this stuff on Pi's. Have not really tried it for avionics.
It's all too damn pokey. Give me the old gauges any day.
I hear you. I actually prefer looking at steam gauges - for airspeed, in particular. Most of my flight hours are in two Cessnas owned by a flying club I belong to. We recently upgraded the panels in both airplanes to include a couple of Garmin G5s, which show your airspeed as a tape. I still find myself looking over at the steam ASI instead. It's a lot easier to interpret a needled pointing at 3 o'clock on approach than to read numbers on a tape.
But I love that you can have access to *_all_* of the data on an EFIS, too. Ideally, I'd have a little bit of both on my panel.
I didn’t hear the word “calibrated” once. You get what you pay for.
This video demonstrates a proof of concept. I've made progress since it was posted several months ago. Take a look at some of my newer videos. Obviously this is not in a state for practical use yet. I still have quite a ways to go with my Sonex build (probably years) before I'll be ready for avionics.
The problem you are going to run into, even though this is stupid cheap compared to off the shelf instruments, is certification which will push all this way up and people will have to get the components from certified resellers to be able to have an airworthy legit craft.
Otherwise this is great I am sure there are thousands of enthusiast aviators who are kicking themselves for spending thousands on instruments.
There's no certification required in an experimental aircraft, which is what this is intended for. If you're interested in certified stuff, go buy a Cessna built in the 1970s. Experimental aviation is the pathway to innovation. This is just another option for those (like me) building their own airplane and who enjoy electronics and code development, too.
OK good to know, yeah hey no doubt these are great I know they will "Take off" I don't have an aircraft and I want a set.@@dan_der_flieger
No hardware design auditing, no hardware design verification, no environmental, EMC or standards compliance qualification. No software testing or verification process, critical safety analysis or failure mode testing... Please don't put this on an aircraft.