Working for THIS man!

So, as mentioned previously, I have shaken off the shackles that go in concert with working for The Man.

What to do now?

Work for this Man!  Or, in other words, me.

It's not like I forgot how to build programs, after all.

To understand this undertaking, there are a few things to know:

  - the RV-12 airframe and the Rotax 912 engine both have scheduled maintenance items, which fall under the broad categories of coming due based on calendar time ('do this once after 36 months in operation' versus 'do this every 200 flying hours')
  - it requires constant attention to make sure you don't miss any
  - there are also Service Bulletins from the factories that need to be addressed. Some of these require periodic scheduled inspections too.
  - the Dynon Skyview, which is the central flight computer in the airplane, can be configured to capture data logs every time the plane is flown.
  - these data logs include both the most current Hobbs and Tach times.  If you don't want to read that short article, just read this snippet from it:

"Tach time is the preferred method for logging engine time for maintenance purposes."

This is misleading - for the Rotax 912, Rotax stipulates that Hobbs time is a better (and mandated) measure of the aggregate working time of the Rotax engine.  Tach time was (and still is, I suppose) the choice for the older, more traditional aircraft engines like the Lycomings in my previous plane, but with the Rotax, time spent idling is still considered to be working time, primarily because of the RPM reduction gearbox. Hobbs time runs faster than Tach time on average, so the extra effort of idling through the gearbox on the Rotax forces us to manage maintenance on the engine using Hobbs time to account for the extra effort required by the gearbox.

So,  I intend to make use of the Hobbs time recorded and reported by the Skyview to track maintenance requirements on the engine. That's a bit of a simplification (I'll do a lot more, including using the calendar date to find the "n number of months" inspection/replacement schedules too), but I'm sure you get the point.

Where this all ends up (personal use only vs. a for-profit service) is up in the air, so to speak, but it sounds like an intriguing project, and that's all I need these days.

Now, I don't expect you to sit through all of this video - I present it only because it is the flight for which I gave the data logs to work with:



A short recap of the flight for people with better things to do with an hour and twenty minutes:

• I flew an IFR approach into Madison Co. (KUYF) using the Skyview. I remained VFR at all times.
• I then flew a 2nd IFR approach into Urbana (I74) - I had initially intended to use a navigation waypoint on the far side of the runway, but shifted to a closer one before I got there.
• The approach I flew was to runway 20, but the wind slightly favored runway 2, so I had to circle around.
• I didn't get the plane low enough on the first try, so had to go around for another try.
• I stopped for lunch at Urbana, then flew back to Bolton (KTZR)

I started on the program (which will take a few weeks to build) this morning. I selected "read the data log file" as the first step.

Here are the results:

As long as I was reading the data to present it in that list (there are approximately 127 columns of data, two of which are latitude and longitude, so I exported those two plus altitude into a new file, correctly formatted for display in Google Earth (3D) or Google Maps (2D).

This is the 3D representation of the flight - you will note that the altitude I can get from the data is MSL (above sea level), not AGL (above ground level) and I don' know how to translate twixt the two, so the plane never seems to touch the ground.

This is the entire flight:

This is the 2D representation of the taxi out and back in at KTZR:

This shows the go-around at I74:

It's a good start, and not bad for three hours of work!

Stay tuned!