MQTT and NodeRed on an airplane?

I've had several posts about using NodeRed for home automation, communicating with various nodes over MQTT. Could I do the same in the airplane? I think I could, and there would be some benefits to it. Certainly less wiring, and maybe more reliable and customizable.

The whole point of this blog originally was to use an Arduino and be able to monitor the engine status. Originally, I was going to use a Mega, and a bunch of shields. The old eco-system caused me to lean that way. Mega on the bottom, a custom shield next, and a Bluetooth shield on top. The world has moved on, and now I can use ESP-32 and 8266's with built in Wifi and Bluetooth. The boards only cost about $10, instead of the $20+ for the Mega and Bluetooth shield.

The sensors can mostly be wired to the ESP-8266 board with SPI (3 wire) communications, through adapter boards. If I need an analog or digital input, it is available on the board as well. There are very inexpensive thermocouple modules available, that would take care of the CHT and EGT measurements. The oil pressure and temperature would be analog inputs if I stick with the stock probes, but there is the Dallas18b20 probe that could be used to measure temperature, but there only one temperature measuring point on the engine. The Dallas 18B20 can be used for OAT measuring.

The oil pressure transducer is off on a flex pipe, with a manifold for to hold the hobbs switch. (theoretically, the oil pressure measurement could be combined in the computer somewhere to enable the hobbs timing measurements). There are nice solid state pressure sensors that may be appropriate for fuel and oil pressure, I need to do additional research.

Volt and Amp measurements can be done using the analog inputs, using the existing shunt for current measurements, or adding another shunt. There are also hall effect sensors that could be used to measure current. Using various current sensors would allow measuring all the important values at once, charge rate, drain rate, etc.

The tach measurement can come off the mag or EI unit. A transistor or optoisolator should work when connected to a pin that accepts interrupts.

Other sensors could be added or deleted anytime using additional nodes. If I want to measure the airflow through the baffles, I could add a node with multiple pitot tubes to see where the air might be leaking.

Then the question becomes, how many nodes should I use? It would be tempting to build one for each sensor, I want to limit the nodes to one function (I've said that before). How gray to I want that idea, one function could be all the thermocouples. Another node for all the oil information (pressure, temperature). Another for the fuel pressure, levels. Convenience may dictate some other arrangement, like thermocouples left side, thermocouples right side, that way the wires don't have to be so long.

Each node will still need 5V or 3V connected. It would be tempting to use the micro-USB connectors on the boards to feed the power. I think, the constant vibration would make the connectors fatigue very quickly, and the power would be falling out. It would probably be best to solder the power to the boards.

A $10 raspberry PI zero could be the NodeRed/MQTT hub. The raspberryPI should be mounted inside the cockpit. I am sure the WiFi signal can get around the firewall on a plastic airplane. Even a metal aircraft should have WiFi from the engine compartment to the cockpit. I'd have to try it out though.

In the cockpit, PLA printed enclosures should work fine. In the engine compartment, there may be problems with PLA or printed enclosures (constant vibration, heat, and rain). 3D printing my own enclosures may be compromised quickly. It may take some experimenting, certainly to make appropriate mounting choices, considering the sensor wiring stresses and heat.

NodeRed should allow nice cockpit displays of the instruments, and allow logging in various formats including CSV. Using the same CSV layout as the COTS instruments (like J.P Instruments) would allow people to analyze engine performance using off the shelf tools (excel, etc). The file could be scp'd from the Arduino, right to a tablet or phone, taken home and analyzed.

I don't know. I see a few worrying things, but nothing that is really scary about doing it. Can you talk me out of it?

Stuff To Learn

I knew the different Arduino boards are all a little different, but I didn't realize the Arduino Mega 256 was really different. My other Arduino Mega is only a 128. The Mega 128 and most of the other Arduino boards use the FTDI USB interface. The Mega 256 uses a ATMega8U2 chip, like the UNO. The boards sure look the same

Now I am using Linux to do development, so the serial port ends up being called /dev/ttyACM0 instead of some /dev/ttyUSB0. No big deal really, it is just I was surprised there were more differences than I expected. The Arduino on Linux page has many helps to get things working.

I took the basic sketch, blink and modified the loop to be sure I knew it was my code running on it.

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(100);               // wait for a tenth of a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(100);               // wait for a tenth of a second
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(100);               // wait for a tenth of a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(100);               // wait for a tenth of a second
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

Now I want to get things working with the display. I bought a LCD touch screen for this. The screen looks familiar, almost identical to the Sharp Zaurus screen. (we can talk all we want about iPhone/Android but the reality was there were smart devices running a *nix flavor waiting for a phone a long time before either were invented! Zaurus was the first one I had, the Nokia 770 was the second, wifi enabled internet connected personal mobile devices).

There is a thread on the Arduino forums about this device, including locations of the libraries. I am going to build a minimal graphics library so I can build a display of the basics before I start using the bluetooth connection to the Android. 

More Engine Monitor Updates

This will be kind of a quick post, but the gist of it is, I've been busy. In between getting a new version of my other app out, and explaining the technology behind these gauges on my other blog, I haven't been watching a lot of TV or hanging out in bars.

The new gauges have options that work, and the interface and abstract implementation make these very flexible. Looking at all the gauges, they mostly have the same call, the size differences are sort of hard coded.

In the picture above, you will see round and bar gauges, mostly the same as before. The new changes are the round gauges can go in either direction, be 270 degree, or 180 degree (any sweep angle should work) There is one CircleGauge class that actually draws them all! The CircleGauge class is extended by things like the Ammeter class, or the Volts Meter class.

The gauges have options for clockwise/counter-clockwise, ticks, and various color options (I haven't been setting the color options, these are the  default values. The gauges can have a rotated start angle, and display the title and value in the center of the gauge.

The gauges all get their values from an EngineValues class, that can be set at any time. The next steps will be to put in the bluetooth reading code that will allow me to connect the Arduino to the engine and start measuring values.

What-cha think? Am I heading in the right direction?

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

Back to the Original Purpose

Enough with the SDRs and Chumby's and other distractions. Well, mostly...

I've been a subscriber to EE Times for probably 20 years. It used to be a weekly paper like format, but is now a skinny magazine, but with amazing web bits to supplement it. A couple weeks ago, there was the an invitation to a webinar on RTD and Thermocouples put on by Maxim. The webinar happened on Wednesday, and I listened to it. Pretty good talk, the speaker couple have been more exciting, but was well prepared, and talked about some good products. He didn't convince me to switch to RTD's but I am now thinking of using an integrated SPI chip to do everything.

The webinar hammered into me the reason for the second temperature sensor at the cold junction. The reason is, that ends up being a second thermocouple, since the copper wires that we are connecting to are of different material than the wires in the thermocouple. If we don't know that temperature, then the actual temperature we want to measure will be off a bit. Having the second temperature sensor will add to the complexity, and cost of the circuit.

The one complex circuit presented used the MAX6126 for voltage reference, and DS600 for the cold junction temperature sensor and the MX7705 for A/D converter. There was some discussion about keeping a constant current source, and other details using these three chips to get a good measuring circuit.

Then he showed the MAX31855, wow, pretty simple. Connect the thermocouple on two pins, some power on a couple more pins, a crystal and capacitors on other pins, and then the SPI to the processor and you are done! About the simplest convertor I have seen for under $5! It does SPI, so I should be able to piggyback 8 or 12 or 16 depending on engine chosen. I won't have to use up the A/D convertors to get past a 6 cylinder engine. There is an SPI library for the Arduino and everything.

Now I am still dreaming, I need to actually build something. I need to order about 8 of them, 4 J type, and 4 K type. DigiKey has them for about $3.55 each, but only if you order 2500 at a time! Single quantities are over $7.50 each, and hard to come by. Maxim is generous, and offers them as free samples. I was able to get 2 of each that way. Well, I ordered them tonight. They are just up the street, well some part of the company is (right down Beltline on Midway in Addison, probably 5 miles west, yup google maps says 4.7 miles).

Another toy

This is sort of related, since it is Android. I got an Mk808 android device. I say device, because I am not sure how to categorize it. It plugs into a HDMI port on a TV or monitor and uses that for a display. Otherwise it mostly acts like a tablet processor. There are no g sensors or touch screens, but you can plug in mice (or bluetooth mice) and control the desktop that way. It can run crackle or netflix, and youtube so it is good for an entertainment device. It has a browser (two), and can read and write office like documents (or use google docs).

So what you say, I can get a tablet and do all that. How about replacing your PC with one of these? What would it hurt? You say you can't download photos to it, no you probably can't. You can't play games on it? Well, my kids are driving my wife nuts playing angry birds. You can download all kinds of games. It has the whole google play store on it. Games, apps and media are all available.

What if you wrote desktop type apps for it. Why not, you know, a 32 in 1080p monitor would be way cooler than two 20 inchers, there would be no line, and the mouse would smoothly slide between windows.

What does a desktop PC cost, $400, maybe $1000? Well this is under $100. Yes, that is right, 1.6GHz processor with 1GB memory isn't much, but it might be worth a try? EBay has 'em for about $50 if you want to experiment and don't want to blow too much. Get one of the fancy wireless keyboard mouse combos and you have a full multimedia center. Cut the cable and do some fun stuff.