Full fadec

[rv6ejguy]

Originally Posted by HAL Pilot

I think folks are advocating for a more glass cockpit feel sds controller. LED/OLED vs older LCD. Maybe even interface directly with new glass cockpit screens and not even need a separate controller.

We looked at integrating function into the popular Dynon/ Garmin EFIS units but they were so not willing to at the time (2017) to cooperate to make that happen. It would also tie our product to other companies and future software/ hardware updates from them and you never know what that entails. We don't have the R&D capacity to deal with that unknown nor maybe the capacity to even work on the interface code in the first place. This would have to be a cooperative effort with the big 2. If they don't play, it doesn't happen.

Other EFIS brand users would be left out as no way we can work with all of them.

Given that the programmers are not used much once programming is complete, you probably don't need this capability anyway.

The EM-6 will have CAN capability in the future which may allow us to share more ECU data with an EFIS but even that requires technical cooperation from the big guys. One of them didn't see the numbers or benefits for them when we were talking and I get that. They'd have to expend engineering time with us and that has to be worth it for them in the end.

We're just finishing 7 years straight of R&D (CPI, CPI-2, EM-6) now while dealing with unprecedented market growth at the same time. Hoping to get back to 5 day weeks sometime soon and getting away from my 6 and 7 day work weeks from the last several years. Can't sustain that level forever. Looking forward to getting the EM-6 released and concentrating more energies on production again.

[BillL]

Originally Posted by rv6ejguy

We looked at integrating function into the popular Dynon/ Garmin EFIS units but they were so not willing to at the time (2017) to cooperate to make that happen. It would also tie our product to other companies and future software/ hardware updates from them and you never know what that entails. We don't have the R&D capacity to deal with that unknown nor maybe the capacity to even work on the interface code in the first place. This would have to be a cooperative effort with the big 2. If they don't play, it doesn't happen.

Other EFIS brand users would be left out as no way we can work with all of them.

Given that the programmers are not used much once programming is complete, you probably don't need this capability anyway.

The EM-6 will have CAN capability in the future which may allow us to share more ECU data with an EFIS but even that requires technical cooperation from the big guys. One of them didn't see the numbers or benefits for them when we were talking and I get that. They'd have to expend engineering time with us and that has to be worth it for them in the end.

We're just finishing 7 years straight of R&D (CPI, CPI-2, EM-6) now while dealing with unprecedented market growth at the same time. Hoping to get back to 5 day weeks sometime soon and getting away from my 6 and 7 day work weeks from the last several years. Can't sustain that level forever. Looking forward to getting the EM-6 released and concentrating more energies on production again.

Good summary Ross. Is there any plan to expand and include some useful OBD features? Is this what you are talking about where the "panels" are streaming the engine data like temperatures and pressures? I suppose there could be an AD interface box that taps the sensor outputs, but certainly not the most economical way to get the data. To progress in the application of known technology (generalized as "OBD") some integration(handshaking as a minimum) will become necessary.

There are many things that could be done by OBD II today, but aren't - example cylinder to cylinder torsional acceleration, to analyze a weak cylinder, starting amperage from the starter to yield compression pressure of each cylinder. Perturbation of A/F to continually optimize each cylinder. Oil pressure vs rpm on startup to recognize oil system issues, or plugged suction or filters. These, and many more, have been proven but not applied commercially.

[rv6ejguy]

To my knowledge, the Big 2 are not set up to read conventional 5 character OBD codes as they were not designed around automotive use.

We also don't use this protocol as our system is so simple in comparison to OEM automotive systems, it doesn't make sense.

We illuminate the Fault LED on the programmer and display error codes in one of 5 gauge modes directly as below. The photo shows a problem with both IAT and CHT sensors in this case.

Our system lacks the complexity and capability to do more than basic diagnostics of our system. We don't get into engine specific diagnosis like cylinder # misfires. Again, we are not a Garmin, Siemens, Bosch or Delphi and we must work on Lycoming, Continental, Franklin, Rotax, Jabiru, Rotorway and a host of automotive conversion engines as well.

EM-6 will have additional built in diagnostic tools for injector and coil function, some of that previously developed for CPI.

Automotive and aviation commonly use CAN for data transfer between "boxes" and we think this is well proven and most robust. The new CPU has CAN capability but we have not had to time to develop the code for that yet. Possibly in a future software release and this could open more possibilities at that time.

Currently we only output RPM and fuel flow data to the glass displays.

[Tomcat RV4]

Mentioning out dated, is probably a keyboard warrior!