Data Comm Tools We Need

I spent the last week on a business trip, and managed to go most of the week without WiFi. The airplane I flew on didn't have WiFi, and while in the car I didn't have it either. I was staying at a 5 star hotel for 4 nights, and had only marginal coverage, at $13 a night. I ended up using my mobile hot spot on my phone and burned through over half my monthly allotment LTE internet in 4 days. I learned how much I rely on data connections.

Several years ago, probably 1998 or so, my wife and I were at Oshkosh, and walked by the Iridium booth. The Iridium sales person offered us a free phone call to see how great their products are, and maybe we could use them in our airplane. This was before my wife or I had a cell phone, and we wanted to check in on the kids. After three or 4 failures, we never got to talk to the kids, and we walked away unimpressed.

About a week ago, the Airplane Geeks had the president of Iridium on the show and allowed him to hawk his products.He presented a new product that sounds like something pilots can use in the plane, and maybe other times as well. The Iridium Go looks to be the perfect implementation of the Iridium network for us.

The Iridium Go is a WiFi hotspot that will work anywhere in the world, at almost any altitude. This is the opportunity to make a tablet and phone work anywhere all the time. When in the air, the tablet can get all the data updates desired, along with making VOIP phone calls on the phone. The Go also has tracking and other useful features built in.

I know FIS-B and TIS-B should have much of the datalink covered, there are some things it won't have covered. Items like downloading whole graphical charts while in the air, or additional weather information will not be available over FIS-B.  TIS-B and FIS-B aren't available outside the CONUS either, operations there will benefit from additional datalinks.

Airlines have the ability to use Iridium datalink today, and the ICAO flight plan has a capability letter reserved for CPDLC using Iridium (J7 CPDLC FANS 1/A SATCOM (Iridium)) in Item 10. To put Iridium radios in commercial aircraft is a very expensive aftermarket event. Using the Iridium Go for non-safety of flight purposes is a much smaller cost (More than an order of magnitude!).

The price is around $600 for the GO, and while that sounds high, consider the cost of a typical smart phone is in a similar ballpark (off contract). One might guess if these devices become quite popular, the price may come down.

For tooling around in your Taylorcraft, this might be overkill, but I could see it becoming almost an expected item on a Citation, or King Air. People rely on data communications a bit more in the 21st century.

(Iridium hasn't talked to me at all, I saw this and thought this is  great product!)

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. 

Doing The Annual Inspection

The weather is getting nice, and I am wanting to work on the plane again. It should be put in condition to fly, and that requires an annual condition inspection. My airplane, being an experimental, and built by me mostly, I have the ability to do my own conditional inspection and sign it off. It hasn't flown for almost 3 years, so I haven't done a complete conditional inspection for some of those years. This one is going to be thorough, I am in no hurry to actually fly.

I've got everything opened up. There are items that need repair (IE drip rail in the front that I broke while storing a box inside the plane), and other things that need a good looking at. I am changing the oil, and sent a sample off to a lab for analysis, to be sure the last couple years of dis-use hasn't done significant damage to the engine. The lab will test the oil for elevated levels of metals that may be early signs of engine damage.

I am looking at the firewall extensively for the engine monitor, and where to attach the monitoring computer.  Most of the smaller wires between the engine and the firewall are for sensors. The wires around the oil filter are oil temperature and pressure sensors. The silvery wires are EGT/CHT thermocouple wires. Under the engine are the fuel pressure wires.  There are the ammeter wires on either side of the shunt (that is a bit of old fashioned technology).

In the annual inspection, I found the ammeter light is burned out. This light is only needed for night flying, since I can see the instruments during the day. Each engine instrument has it's own light bulb, so I am 1/6th of the way through needing to replace them all. It'll be good to replace all the engine instruments with a smart box to monitor all this, as well as display current state.

I've started on the bluetooth code. That is a bigger challenge than I thought, mostly because the Android emulator doesn't support bluetooth. I need to keep my phone plugged in and use that for the tester. It isn't bad, but the phone has lots going on, so the log files scroll fast (and this is my only phone right now.

Soon the annual will be done, and hopefully about that time, I'll be ready to put my arduino in the plane, and start testing some of this. In the mean time, I've ordered another arduino, a mega 256. It seemed I ordered that the same day the arduino zero came out. Why am I messing with 8 bit micros when 32 bitters are about the same price? I don't know, comfort maybe, or maybe it is all I need, the 32bits may not get me anything. (The zero only has the same number of IO pins as an uno, so there isn't a big win yet, some day there may be a mega zero, until then, I'll keep using the mega).

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.

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.