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

Amarino - Again

So I switched back to Amarino. Nothing wrong with the Andruino, in fact long term I'll probably base things off of that, I just need a GUI on the Android now, and Andruino doesn't let me do that. Code that I write for Amarino will be portable for the most part, so I should be able to write a gage module and use it for both environments.

So I rewound... I didn't go to the trouble of connecting the old PC hard disk to the new computer. I thought I would learn more if I did it the hard way. So far I think I have. Amarino isn't very flexible. The code must be hard coded for your bluetooth cards address. Finding the numeric address was a challenge. Initially when the pairing starts it displays the address, but then it changes to the name of the device. I looked in settings, thinking it might list the address there. It turns out the Amarino app has the address in the connect dialog. It took a little while, but I have it.

When I installed the ADK, it defaulted all my targets to 4.2.2. That works great on the emulator, but none of my devices are that advanced. I only have 4.1.2 on them, and some older phones have 2.3.3 or something. (If you aren't familiar with Android, the 2.x OS was pre-tablet version, but you can find some off brand tablets running 2.x, then the 3.x OS was for the early tablets, and Google quickly came up with an OS to satisfy their needs, and it only ran on tablets. The 4.x and above OS is the unified phone/tablet OS that is very current, and is more distributed, so most situations only need a new app, not a whole new OS to get almost all the latest features). The different OS targets APIs are also numbered (IE 4.1.2 is API 16, 2.3.3 is API API 10, sort of like Java versions). 

I installed the 4.0, 4.1 and 2.3 APIs so I can test things out on all my devices. This is done in the Android SDK manager app. Just a few clicks, to select what do download, and press install packages and the ADK is app updated! I didn't download the MIPs or Intel versions, thinking it would save time, and I don't really need them. The older tablets I gave the kids are MIPs based tablets, I may get a version another day for them, if I decide the app is suitable for older tablets (probably, I am not doing anything too complicated, but I don't think those devices have bluetooth).

Loading a bunch of new devices still didn't let me change targets. I had to restart Eclipse. Now I have a large collection of usable APIs. It still can't find my phone, only the emulators. It turns out I needed some new Samsung USB driver for it. I am not sure if Samsung is pushing the boundaries, or if they are being evil requiring a new driver. I'll look into that another day. I installed the app, but now touchwiz keeps crashing. I am rebooting the device, hoping whatever mess I created will get fixed.

Uh oh, now what? Well rebooting didn't fix anything, touchwiz keeps crashing. The phone is useless right now. At least the GUI. It isn't anything malicious, like a virius, just my dopey version of SensorGraph. I can use the notification bar to get to email, and that works (if there is a notification to select). Now when I exit email to go back to the home screen, when touchwiz crashes, I end up back at the email program.

Ooof, sitting here thinking about things, I think I know what I did. The SensorGraph came with an Icon defined in the original package. When I started putting the package together, it couldn't find that icon, so I created a 0byte file for it. I am guessing touchwiz is trying to draw a zero byte icon, and is getting a null pointer exception. I'll change the app to use some other icon, and then download that. It is just touchwiz, so that makes as much sense as anything.

Yes, that fixed that trouble, but now SensorGraph quit at startup. I thought it was because Amarino wasn't running. I started Amarino and connected to the board, then SensorGraph, but it still crashes. The LogCat was enabled, and I see a runtime exception, no class found at.abraxas.amarino.Amarino. It almost sounds like I don't have the amarino libs installed on the phone? Hmmm...

"With great power..." I had the amarino libs included in the build, but not in the deploy. Under the project->properties->buildpath->order and export, I had to check the box to export the amarino libraries. Now it works! Well it is connected, and well, 1 active connection. It says "hello world, sensor graph". I still need to upload the sensor graph software to the arduino. I had already loaded the code to the arduino library. Here is a screen shot of the stock MeetAndroid sketch output on the phone (random noise on analog pin 5)

Then I went and changed the sketch to read the input from the LM34 that was on the board at pin 15

It started at ambient temperatures, then I put my sweaty fingers on it, and you can see where it jumped up.

Now on to redoing my GUI work.