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.

No problem. I'm glad it was helpful.

Glad you found it helpful!

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

Thanks!

Glad it was helpful. Thanks for watching.

Thanks Al!

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

Good suggestion, Dave. Thanks!

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.

I've only taken a cursory look at the Yamaha engines. Should I research more?

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.

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: kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.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.

Thanks!

I haven't purchased the engine yet. I still have a long way to go before I'm ready for a powerplant.

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: kzfaq.info/get/bejne/d7CAmbKend7bmqc.html

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.

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.

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.

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.

Hi Olaf. I did start playing around with PCBs and demonstrated it in a later video: kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.html It's fun to design and etch the PCBs and it's even more fun when they actually function. 🙂

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.

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): kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.html This video was more of a proof of concept showing that it's possible.

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 (kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.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.

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: kzfaq.info/get/bejne/p6inZLJmprm7eoU.htmlsi=nQtAt9RVMFasZ0d_

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.

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: kzfaq.info/get/bejne/d7CAmbKend7bmqc.html And here's another one demonstrating some printed circuit boards I designed for use with the project: kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.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.

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.

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.

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.

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.

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/

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-dn9mx - 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: kzfaq.info/get/bejne/otCplKt82JfXYnk.htmlsi=EQncFiL_lwJpgRu1 He is working on a lot of really good improvements and making very good progress.

@dan_der_flieger Thank you bro 🙏

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

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

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.

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: kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.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. 🤔

Yeah, that would be pretty cool. If anyone starts working on that and sees this, please let me know.

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: kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.html I didn't realize that the RPi 5 could run NVMe. That might actually move me to use one.

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.

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.

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.

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.

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?

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 🙂: kzfaq.info/get/bejne/ma-jqcKVtrqxqaM.html

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.

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

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

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

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.

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