Part Prices

I was looking at laying out a prototype board, something better than the proto board I am using now. I really like the MAX6675 for the thermocouples. The protoboard is looking good with 4 of the Arduino modules on there. I've built some braces for the modules, and it should be good for ground testing. 

I can buy the Arduino modules with the cap from the data sheet, 0.1" pins and a screw terminal for about $4.00 all day long. If I want to buy the bare chip, it is $9.00-$11.00! Why? I thought the Arduino modules might be using a clone chip, but when I magnify the chip, it clearly says MAX6675ISA. Is it counterfeit? I would thing MAXIM, or whoever would be catching these at customs if that were true. I just don't get it. 

I need to do some more research. Find out if there is some magic I am missing. I am sure I could request samples, and probably get what I need for very little, but if someone were to want to reproduce my work, well, it could get very expensive. 

I know I said I ordered 3 meter thermocouples, I was wrong. I ordered 2 meter cables, and boy are they long! I could have gotten away with meter and a half cables for the two front (rear) cylinders, and 1 meter for the back cylinders. Anyway, they aren't built well, so I may need to modify them anyway. The crimp joints don't have any strain relief, and that is where things are likely to break. I 3D printed a brace to support the modules.

The code has been modified for talking to all 4 modules. I think I'll only have 4 on this board, due to space. Eventually I'd like to use 4 more of the same module for the EGT temperature measuring. I am also using the Hall Effect Linear Current Sensor Module ACS712 for Arduino for measuring current to the panel. I haven't the software for that yet. 

I am printing a proto mount for the firewall now. I use tinkercad for these parts. The links are here, if you want to use them. Let me know if you do. 

ProtoMount                       ModuleBrace

      

Engine Monitor Progress

I am gaining a bit of experience in Android development. Some things I did in that last app are helping, while I need to learn more to make this work. One thing I have clearly learned, the drawing canvas can be made into tiles. This is important, since if the app is to display both in portrait and landscape, it will be much easier to move individual gauges around than trying to use different offsets depending on orientation.

rough example

The other thing I learned, these gauges can have a million options! I may need about half that many before I am done as well. Should the round gauge turn clock wise or counter clock wise? Should the green arc be thick or thin, should the ticks be shown or not. Of course I can add all those options, and I still need to add more.

I've built the individual instruments using normal Object Oriented (OO) concepts. I could just as easily substituted the tachometer as a bar graph as a round gauge. I also have the ability to build an new type that can be a line graph or something, and only have to change the code a little. I can change the individual gauges, and probably not have to change the implementers code as well.

The OO concept allows a great deal of flexibility. Everything is abstracted away, such that the value of the fuel pressure will not really care what color the pointer is, or that the gauge is round or some other shape. Where it is placed on the screen is equally irrelevant, and allows the user to change the layout of the screen to suit their needs, and present the most important information in the most prominent position.

I am making progress, I just keep getting bogged down in implementation details, that can probably wait. Some of you are looking at this and saying, "it isn't very good". Fine, tell me what other things I should change to make it better looking. I've already considered OpenGL 3D looking instruments, and non-linear scales, red lines at limits, and many other things. The app will include audio and visual alerts depending on settings.

For now, I have all the instruments I need for my airplane on the screen. I have provisions in the code for 6 and 8 cylinder EGT/CHT values, as well as manifold pressure, and temperature. I want the screen layout to be customizable by the user, so they can pick the instruments they want, and where they are on the display.  


 Thanks for your feedback so far.

Getting Back at It

I've finished my other Android app. It is non- aviation related, and it doesn't use an Arduino, but it proves my skill as an Android developer (or not). It may be in the Playstore real soon now. The weather is warming, and I can get at the plane in the hangar, so I am going at least make an effort to move forward with the engine monitor project.

I've been playing with the Android PFD that I really like. The  A-EFIS is really nice, and I can see this as the primary display I use going forward. Long term, before I would fly any tablet in IFR conditions, I would like a AHRS system bolted to the aircraft, and connected to the tablet. This app is good enough for daily use otherwise using only the tablet gyros. I tested this while flying on a commercial flight (I wouldn't want to test and document while flying solo in GA). 

It is time to replace the engine instruments with an Android app. I have the skills, and proved that I can get the data, I just need to put it all together. So I will document my design with this post, and move on to actually finishing it, showing my test results. I look forward to your feedback, and want to know your thoughts.

I am trying to use best practices, so I will try to use modern technology, and communications. It will still use the Arduino, since that platform is reliable and well documented.

Using the 3 layer design Model, View Controller (MVC) pattern, I will use the Arduino output as the Model, the Android display as the View and the logic to monitor and log the data as the controller. There may be redundant logging on both the Arduino and the Android. The Arduino will be attached to the aircraft, and have the aircraft data. The Android will be removable, and allow interpretation and modeling at remote locations.

The Arduino will read all the raw values from the sensors, and convert those values to actual real numbers. The actual message will contain units, so the numbers have a context.

The output from the Arduino will be in JSON format, allowing different platforms to use the information.  Someday someone may want to replace the Android display with another platform, and that will be possible using this design. The message will be sent from the Arduino about once a second, but can come more often.  A sample message will be similar to:

{"engineParams":
     ["CHTS":[
        "Cyl1": "340F", "Cyl2": "341F", "Cyl3":"348F", "Cyl4":"333F" ],
      "EGTS":[
        "Cyl1":"1530F", "Cyl2":"1520F", "Cyl3":"1550F", "Cyl4":"1545F" ],
      "RPM": 2330,
      "OilPress": "50lb",
      "OilTemp": "220F",
      "FuelPress":"25lb",
      "Volts" : 14.2,
      "Amps" : +12.3,
      "ManifoldPress", "32.29InHg",
      "Timestamp", "2142325533.5sec"]}


The Android will use this information to display graphically the current engine situation. The Android will be able to interpret these values and display the data in other units, set monitoring points with alarms, and other alerting mechanisms. Logging will try to be as similar to the Insight engine monitoring data formats (CSV), allowing existing analysis tools to utilize this data, and make common sense results.

Some of the alerts will include:

• Low oil pressure
• High CHT
• High oil temprature
• Low voltage
• Low charge (amps)

As well as others can be programmed in.  Blinking displays and audible alerts are possible, and a combination will be used. The audio output from the Android device can be routed to most audio panels. The Android device may allow playing music, podcasts  and other entertainment functions along with the alerting functions.

Using the JSON input format can allow debugging and testing on a desktop computer. Creating or using recorded data can allow playback to the Android device. The Android emulator included with the ADK is very good, and allows devices of all types to be used, to insure the display will work. I can start working on the Android code without having a functioning Arduino device working.

I welcome your input