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.

After You Rewire it...

Yesterday I stopped by an estate sale. They had a Robosapian V2 for $10. This is a robot I've wanted for years, but they cost more than I could justify. I thought $10, why not. The remote seemed to work, and it had batteries in it, I thought for $10, I would take a chance on it.

It needs 6D cells and 4AAA batteries, so I stopped off and picked up some batteries for another $15. So now I am $25 into it, and it doesn't seem to work. My normal mode after buying something like this, and finding it doesn't work, is I Google for similiar failure modes. This failure mode is, it does nothing. I opened up the feet again to be sure I put the batteries in the right way, which I have, but the one pair of AAA batteries are super hot, like I can't hold them.

Reading some of the fixes suggested, was a youtube video about how easy it is to rewire this thing. I watched about half of it, and thought, this is like Tim Taylor rewiring everything just because. Another site suggested rewiring the legs. The one site suggested it is easy to open the robot up, so I thought, I can open up the torso to measure voltages on the main board.

Insulation has flaked off and is covering bits of the robot insides.

 

What greeted me when I opened it up was shocking! Insulation just flaking off of the wires. Most of the wires that went to the legs had about 50% of the insulation missing. I continued opening up the robot, and when I got to the legs, there were parts where all I saw was a mass of copper, you could no longer tell one wire from another.

I thought I would try the rewiring repair. I went to Radio Shack to see what they had for wire. There was a significant gap between the 22GA wire and the 30GA wirewrap wire that they didn't have. I bought the 22GA wire to use for the motor power, and decided to cannibalize a Cat 5 cable for the logic wiring. It took about 4 hours to do all the wiring. There are several sites with details on what the wires are for.

I want to blame some MBA or manager for making a really bad choice here. I don't know for sure, but someone at the company decided to cut some corners with the quality of the wire. Some of the wire in the robot is fine, but the critical wires (the ones going from the body where the computer is, to the feet where the batteries are, and they move a lot) are just crap.

I was short of resources as well. The connectors that are in the robot are pretty cheap as well, but are a common connector. They have tin crimp on pins. Rather than risk the whole pin, or the body of the connector, I decided to strip back about an 1/8" of wire and solder my new wire on with some heat shrink to insulate the connection.

Once I got the wiring done, it still didn't work. I tried using a meter to trace the trouble. I was not getting any voltage from the AAA batteries in the one foot. When I opened that up, I found the connector in the cover was covered with corrosion, and not making good contact. After cleaning up the connection here, the robot started jiggling around and talking!

Success! I now had a working Robosapian V2. I started putting the panels back on, and covering the robot up, so it looked like it did when I brought it home. I messed up on some of the screw placement, but it went together, and looked good.

I played with the sensors for a little while last night. The blob detector is pretty good, and worked really well. The motion detector was pretty good at well, I could get it to flail backwards and scream when I swatted my hand towards the head. It walked and reached with the remote. So I went to bed.

When I got up this morning, I started messing with it more. I wasn't using the manual, just randomly pushing buttons. I clicked on the "D" button that starts the dance routine. It was playing music and moving quite a lot, then it quit. It seemed to quit on a proper down beat, but was in an odd position to end a dance.

3 of 6 wires are broken from white connector

Nothing worked again. Grrr! how much do I need to open up to find the trouble this time?  I opened the torso, and the trouble was obvious. My soldering on to the connector ends made the wire brittle. People have told me before, "don't solder your crimp connectors, it makes the wire brittle", but in this case, I didn't have much choice. Most of the wire was already missing the insulation, and I didn't think making long pigtails with lots of heat shrink was a good idea. (I didn't think of long heat shrink coated wires at all).

I've ordered some new connectors. I will replace all 4 of the connectors I soldered to like that, and make sure there is enough jiggle room between the connector and the solder joint.

After you rewire it, you do some pretty cool things with this robot!

These robots are a challenge.

App In the Playstore

Like I said in the last post, my app is in the Google PlayStore, and can be downloaded by anyone. There were some things I found out the hard way, but overall, it was a pleasant experience. Yes, I am working on the engine monitor, I just needed to get this wrapped up. I am guessing there will be updates when people start giving me feedback, and there are a couple items I want to update for the next revision.

To get an app in the store, you need to sign up as a developer.  This is a simple task, agreeing to Google's terms, and paying $25. The $25 is a one time fee, and allows you to put in as many apps as you want.

The Playstore is trying to be fair to everyone, without putting them at risk. They don't want apps that are all spam, or extortion type apps, where you can't use the app without paying something extra. They kind of control that by mostly forcing you to use their services to pay for the in app purchases, if there are any, or to clearly label your app as pay to use.

If you want to distribute your app outside the US, you need to certify that the app doesn't break any ITAR rules. They ask you to check a box, and aren't really into looking for specific certifications. That check box probably keeps Google an arms reach out of any ITAR enforcement action.

The one thing that took the most time, Google was a little more picky about my package name. This, being my first app, I went with the defaults in Android Developer Studio. When I created the app, it asked for the package name, and filled the box in with "com.example". I didn't make any plans at the time, so I left that alone.  When I uploaded the app to the playstore the first time it rejected it, saying that "com.example is reserved for special items".

You can look, according to IANA.org, example.com is available to be used for illistrative purposes:

As described in RFC 2606, a number of domains such as example.com and example.org for documentation purposes. These domains may be used as illustrative examples in documents without prior coordination with us. They are not available for registration or transfer.

Wow, who knew. For the engine monitor code, I changed that already to com.engmon, at least for now.

All the icons I had already done. If you look at the icons on a phone, they are a little better looking than in the play store. Maybe if I was making money from this app, I would hire a graphic designer to come up with something clever, but these kind of illustrate the walking outside the app requires.

I did need a large icon to get it in the play store. I didn't start with the big one(512x512 pixels) while building the app. I started with the second big one (144x144pixels), and built proper layers using gimp to build the icon. I scaled the 144 pixel image down to make the smaller icons, and that worked well, as I expected. I tried a couple trees in front of the Android, but it didn't look well. For the big image, gimp did an OK job scaling up the 144 pixel image.

The other thing the app needed, was to be built without any debugging turned on. I get it, many of the debugging facilities are entered using various networking ports. Once someone has access to an app, in a nefarious way, they can do bad stuff, due to the fact that there is really only one user for all the apps on the smart phones out there. All apps have the same permissions for everything.

Google has some funny algorithm that determines where the app shows up when you search. When I type in Acreage calculator, it find an app called Acreage Calculator (the play store allows apps to have the same name, I am guessing trademark registration would trump any conflicts, but I am not gonna worry about it). The other app converts square meters entered in a text field to acres, as a converter would do. My app didn't show up this morning. It may when it gets enough downloads, but how do you get downloads if it isn't visible?


You should down load my app and give it a shot. Please give me feedback in the Playstore, or here. Your ideas may be incorporated in the next release of the app.

Thanks for listening.

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

Android ADS/B in for $20 available NOW!

It is finally available! I predicted it about a year ago, when I first ordered my tablet, and thought about writing it myself, and asked for help. I am glad there are more ambitious people out there, because they get it done. My Android development skills aren't there yet either. I am working on an app that will use maps, but haven't got to that part yet.

The app is $1.50 in the PlayStore, called ADS-B on USB SDR RTL (beta)  it shows up in apps called "USB ADSB..." on the tablet. The USB dongles are really only about $15-20 US, plus shipping. You will probably need an OTG cable or adapter for a phone or tablet. (The OTG cable allows attaching USB client devices like mice and keyboards to a phone or tablet). Really the cost may approach $50 plus a tablet.

The app shows promise, and really looks nice. It starts the map centered on Lakeland Florida, so it needs to be adjusted to where you are. The maps can be sectional, WAC, IFR, and street maps, and can be selected from a menu. The pinch to zoom works, but the menu allows zooming, along with buttons in the upper corners.

When the app comes up, it displays all the available devices, selecting the available device starts the app. The top part shows the map, the bottom part shows a list of the aircraft that the software has heard recently (can be adjusted in startup menu, defaults to 60 seconds).

It appears to be listening for 1090MHz Mode S with Extended Squitter (ES) transponders. 1090ES is the world wide standard. GA in the US will probably focus mostly on the 978MHz UAT devices, since there is more bandwidth available to those devices. See UAT or 1090ES in my other blog).

The developer says it will have weather eventually. Weather alone would make this app worth while, but the aircraft positions is a huge benefit. "Mounting" a tablet in an aircraft isn't hard, and there are a few adapters to make it easy. 

This doesn't completely compete with the Garmin GDL-39, and their Pilot app, but it will give you the chance to see what is possible, and the benefits to having ADS/B service.

I had trouble using it. The SDR dongle is very sensitive to the antenna chosen. I found a link to a site were there are extensive design and testing of antennas especially for ADS-B reception:

http://forum.planefinder.net/threads/ads-b-diy-antenna.23

I chose the simple 1/4 wave dipole and was able to get some reception. I didn't want a large antenna, nor an amplified one. I want to be able to use this portable in rental aircraft and such. It did seem if I got the SDR farther away from the tablet, it worked better. I used a USB extender to do that.

The battery life doesn't seem to be negatively affected running the SDR dongle, the screen still eats most of the battery. Someone suggested a split OTG cable, so it could be connected to power while running the SDR dongle. That is a great idea.

I can't say this will save a life, or replace TCAS for alerting, but it could help someone get the big picture when ATC calls out traffic.

If everyone only does ADS-B in, it looses some of the benefit. The future will require us to use ADS-B out as well, then everyone should be on the same level.

A Quick Look at A Couple Android Gyro Apps

Tonight I was flying from KDAL to KMSP on Southwest. Now with the technology on all the time policy, I've been getting more bold. I actually try to use aviation apps on the plane while riding in the back. I've tried GPS based apps, and the metal tubes that are commercial aviation make using the built in phone and tablet GPS unreliable at best, and mostly unusable. I have maybe gotten 4 satellites at once on my tablet.

Gyro apps should be usable on aircraft, no matter where you are sitting. I tried a couple at random while coming home. I didn't start using them until we penetrated the clouds just north of KRST. We were supposed to be flying the KASPR4 arrival, but when we got in close, the controllers gave us all routing.

From my window, is seemed like we got much closer to KMSP than flight aware shows, but this will show that we did do some maneuverin, especially out past Lake Minnetonka.

The two apps I used were Sensors and Gyro.  Both apps portray an aircraft Attitude Indicator (AI), where gyro also displays a Directional Gyro (DG).They both rely on the sensors in the tablet or phone. I tested both on my Samsung Galaxy Note 10.1 (classic?).

I've written before about how the gyros work on an Android device. The gyros in the device are rate sensors, and to display current attitude information, they need to be integrated over time. Both apps seem to have done this well, with limits.

Sensors, (I can't find it in the play store any more, I did crash it this evening, so I was able to send the author a note about me wanting to get in touch with him/her)  is a really basic AI. It is probably designed for a phone, but it seems really reliable.  The gaps around the angle display seem to be quite revealing on the tablet, but probably look good on a phone. The calibrate button is needed, and should be set while the aircraft is on the ground.

Where the Sensors app has trouble, is the coarseness of the changes. I had to integrate its reading to determine our attitude. I don't want to be too harsh on this app, it does well. It is a little jerky, and tended to not lock in to a particular pitch or bank angle. The bottom numbers are always integer values, so I wonder if there is some rounding going on, and that makes it less smooth. Overall, I really like the work that went into this app.

The other app, Gyro, or Inflight Instruments looks really good. It has a ton of settings. I've said before the Galaxy Note 10.1 sometimes doesn't work with some apps, because of the gyros, but this app lets you adjust around it with different Gyro configurations (in the settings menu). Once I found that my tablet seems to have the gyroscope orientation "C" with the tablet in portrait mode, and set the calibration, I could see it work.

The AI wasn't as sensitive as I might like. During the big right turn in the picture at the top, it seemed like we were doing a 15 degree bank, and the AI only showed about half a line of turn. The DG seemed right on, or very close. I got myself turned around, and thought the DG was pointing the wrong way, but let it go, it turns out it was pretty much right on.


Summary

Right now, I wouldn't use either of these for instrument replacements in actual IFR conditions. They show promise. I probably won't write my own gyro instrument app.

I did want to try A-EFIS, but thought it needed GPS (it does for altitude). That appears to be a reliable panel replacement.  Next time, I will try it.

Watch Operating Systems

This is kinda becoming my Android discussion page, so I'll talk a little about a change that Samsung has made, and why it doesn't matter at all.

Samsung has a couple watches on the market, the Samsung Galaxy Gear and the Gear 2, and the Gear 2 Neo. The Gear 2 watches were announced yesterday, and have some people in a tizzy.

The original Gear watch that Samsung announced over the summer was not well received by most consumers. Partially it was some of the limitations it had initially (I only worked with the Note 3 when it first came out), and partially it was the price (retail was almost $400). The battery only lasted about a day (25hours), and the camera was fairly big in the band.

The one thing that Samsung tried was putting the full Android OS on the watch. I commend them for trying to put a full mobile OS  on a watch. There are several facilities in the Android OS that probably weren't needed for a watch. As an example, the watch didn't have any phone hardware, so that facility could be turned off, but probably there are things that cause the OS to at least check for the hardware.

The new gear 2 watches no longer run Android. The new watches run Samsung's other OS, Tizen. Some folks thought Samsung was using Tizen as a threat to Google. The worry was that Samsung was going to switch all their phones and tablets from Android to Tizen, freezing Google out of that section of the market. Maybe Samsung folks were making that threat to Google, but recently Samsung and Google have put together a more cooperative agreement.

Tizen on the watch will make some people wring their hands. They will say, it is the end of Android, and that Samsung has started the switch. Maybe Samsung will try some Tizen phones, but I don't see them running all their mobile devices on Tizen. The Android/Google eco-system has too many facilities that Samsung would have to duplicate and get 100% right. Some people think Android is inferior to iOS, can you imagine the reaction if the Tizen eco-system isn't as good as iOS on day 1.

At the heart, or at least the lowest level, both Tizen and Android run Linux OS. There are many variants of Linux, and over the last couple (ten?) years the Linux OS has been optimized for lower power. Anything put on top of Linux will use more resources, and more power (IE Battery). Faster processors are generally more power hungry as well.

A watch should last a while before needing a new battery or recharge. How inconvenient to be somewhere without a charger, but needing a watch to work.

A watch doesn't need as much operating system as a smart phone. I played with the TI Chronos watch. That watch didn't have bluetooth or WiFi, but it still had wireless capability, so it could be programmed and get alerts from a computer, using the enclosed USB FOB. It has fitness functions, and tells time, and each segment in the face is programmable. The cool thing is, the battery lasts about a year!

Last week I saw on Hack A Day a watch someone built with an Arduino (ok now this post matches the charter of the blog :-). This watch has bluetooth, and can talk to an Android device. There are no claims on the battery life, but it has a rechargable lithium battery, and would guess, it might last several days at least. Put something like this in a 3D printed case, and some other cleanups, and it could be something I would be proud to wear.

No on seems to care what OS any of the other smart watches run. I've heard Pebble runs the FreeRTOS, but I don't know or care. Sony smart watch, according to Wikipedia runs the Micrium uC/OS-II. Meta watch also seems to run the FreeRTOS according to Wikipedia.

None of the other smart watches run Android. Samsung tried it, and it didn't work. They are smart to try something else.