Page 4 of 4 FirstFirst 1234
Results 31 to 37 of 37

Thread: DIY Engine Monitor

  1. #31
    Premium Member (Donated) WWhunter's Avatar
    Join Date
    Jul 2011
    Location
    In the woods
    Posts
    617

    Default

    Ryan,
    Since you already know that I am NOT computer savvy, the only suggestion I have for you is....keep at it!! You're doing great. That's my $0.02 :)

  2. #32
    Premium Member (Donated)
    Join Date
    Sep 2014
    Location
    IA
    Posts
    119

    Default

    Thanks for the encouragement! I was glad to get the display hardware working. I was about to trash the whole thing when I was trying to get it to talk with the MGL equipment. I know enough about how it works to confuse myself.

    One question I'm pondering currently is does it really need a dedicated alarm display? Are the flashing colors on the out of limit readings enough or do we need to be able to see what gauge is the alarm on in a separate window like it is now? My thoughts are leaning to removing it since the display is small and so you should be able to quickly understand what reading is out f the limits. I feel like if this were a much bigger system with multiple screens, then a dedicated alarm list that would be able to be seen on a primary display would definitely be to some advantage.
    Ryan
    S-20 (Painting)
    Build Site

  3. #33
    Premium Member (Donated) Tailwindflyer's Avatar
    Join Date
    Sep 2015
    Location
    Wichita area KS
    Posts
    75

    Default

    Ryan,

    This project is looking great.

    I think I agree with your idea to remove the dedicated alarm display box and just keep the highlighted out of limits values.

    My 2 cents is to have a single alarm light/LED close to primary field of view plus the highlighted out of limits values on the engine display unit.

    I am following your progress with interest along with the enguino and the experimentalavionics.com projects hoping to be able to adapt something for my build when the time comes.

    Please keep up the good work!

    Cheers

    Rich
    S20 build in progress, N71NG reserved
    http://n71ng.blogspot.com

  4. #34
    Premium Member (Donated) WWhunter's Avatar
    Join Date
    Jul 2011
    Location
    In the woods
    Posts
    617

    Default

    Ditto! I think the single notification would be fine. If you are they type that is always got an eye on the display, I would think you would notice it easily enough. I a the type that does the precursory glance every so often at the gauges and think a flashing or highlighted reading would be seen fairly easily.

  5. #35
    Premium Member (Donated)
    Join Date
    Sep 2014
    Location
    Eastern Iowa
    Posts
    131

    Default

    Ryan,
    There must be a bunch of human factors and user interface stuff on when and how to present information about an out of spec condition.
    Something that can't wait to be seen by a typical pilot's instrument scan perhaps has to be presented as an alarm. Immediate safety of flight issues. Not sure what that is on an S-20.
    Something that needs to be addressed but isn't of instantaneous importance maybe would get a different priority. Fuel level. CHT out of spec. (but out of spec over a certain time limit or rate or degree may rate a different presentation.)
    Instrument scan is likely to be disrupted when we are focusing on something, such as pattern work, passenger issues, turbulence, can't get the %^&^&* GPS to reset, etc. I don't trust instrument scan.
    I'm suggesting you game situations for your airplane, assume worst case for your human frailty, and consider where alarms might prevent deterioration of a condition, especially one you could affect if caught early.
    Just thinking out loud.

  6. #36
    Premium Member (Donated)
    Join Date
    Sep 2014
    Location
    IA
    Posts
    119

    Default

    Thanks for the input! I removed the alarm box and gained back some screen space.

    Thanks for the response Jim. I have read stuff about control/switch design for things like gear and flaps. Also stuff about what colors to use for what and when. I haven't found a reason to delve more into that for an engine monitor project mainly because I can't think of anything that would need it at the moment. An enhancement that I have on the books to do is make the alarms configurable so some can never be silenced or made to stop flashing. RPM red lines for instance would be something that I would think should be blaring and flashing away until the condition is rectified.

    In addition, the app currently has a logging capability that will log all the parameters for each gauge. An enhancement I want to make to that is a log of associated out of limit occurrences. That data would be able to be seen in the normal logging, but would require software or an excel sheet to identify those instances where the limits were exceeded. I figure if I can have one simple record of all the occurrences, processing the data by a normal human would be much easier. Also lends itself to being recalled from within the application or something else.

    After your post I also added a note to start tracking how quickly parameters are changing so that we could alert the pilot if they will exceed the limits and not only after they have done so.

    I also am not sure what would be immediate safety of flight issues in an S-20 that are able to be monitored by the application. I am planning on bringing in data from a GPS and a Garmin G5 backup EFIS instrument so I can get access to attitude, airspeed, altitude, and GPS data. I have some neat ideas for that when I get to a good spot with the engine monitoring capability.

    One of the ideas is a wind vector. One of the things that an EFIS does that I want in my plane is that wind vector. Not sure why I like it so much. It isn't any ground breaking algorithm or display, but I've always flown in airplanes without it and when I'm slowly crossing all these corn fields I kind of want to know why and how. So by bringing in the data from the G5, I can do some math on it and display a wind vector (or wind components).

    The neat thing (that I assume is already being done by places like savvyanalysis.com or other engine data analyzing websites - The knowledge they gain from having access to all of that engine data and then correlating engine issues with the data is invaluable. And the data acquisition is free! ) would be to start learning about your engine from all this data and being able to alert the pilot if something isn't right given your engine's history. For example, if you go to take off are you really getting the correct engine power? Is the fuel flow correct? How much runway are you going to need for the takeoff given the current temp, altitude, etc. (Xavion - from the X-Plane guys does this I'm pretty sure)? Is something failing? Neat possibilities for avionics.

    After all the rambling, a small project update. I finally got the application communicating with the MGL RDAC successfully. I don't know much about the serial data communication, but have been learning lots and think I have a decent handle on it for the time being. I had previously coded in many of the Rotax sensor conversions, so I think they should be working fine. If anyone uses an MGL RDAC and like tinkering please let me know. I'd like to be able to test this thing out alongside some calibrated instruments.

    Here are some pictures of the screen and the 3D printed case. Came out looking great. I don't have the rear built yet. I need to finalize some things for data and power connections before I get that made.

    Attached Images Attached Images
    Ryan
    S-20 (Painting)
    Build Site

  7. #37
    Premium Member (Donated)
    Join Date
    Sep 2014
    Location
    Eastern Iowa
    Posts
    131

    Default

    Ryan,
    Very interesting project.
    Fred and I have been doing a lot of practicing of engine out and emergency landing scenarios both from altitude and low level. As a glider pilot, I'm comfortable with steep banking near the ground but that almost always in a descending, rather than constant altitude, orientation. Same with an engine out. I wonder if it is feasible to develop an alarm that would alert one to uncoordinated flight, like the ball is out by one or more ball width and any other situation where an accelerated stall is more likely (these are not necessarily the same situation, of course). I understand we can get too complicated for our own good. I'm only thinking out loud.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •