Making use of G1000 data logging

[TMetzinger]

Now that the G1000 is offering data logging for pretty much all airframes, it occurs to me that there can be some benefits to operators who operate them, particularly if they have a fleet, like a school or FBO.

Depending on what info gets logged (Kent, if you have time, could you send me a file from your plane to play with?), it should be possible to import the data into a database, and then sweep it for events that might be not in accordance with best practices or policies. Some things that come to mind are:

Hard landings - by matching vertical speed against altitude - if you get a high VS followed quickly by a constant altitude, you might have a hard landing.

Operating flaps outside the envelope - this is a common thing on the DA 40 - I see students starting to put flaps down when they're too fast, or forgetting to retract them after departure before accelerating. Happens on Cessnas too and probably Mooneys

Landing with insufficient fuel - we can "catch" folks who landed with less fuel than we liked and counsel them - either they didnt' set the totalizer correctly (lecture 1) or they did and they landed with insufficient fuel (lecture 2).

Engine temperature issues - if we spot a high cylinder head temp, we can look at the data surrounding it to see what was going on and counsel the pilot on his operations. Same thing if we find abnormally high/low fuel flows for the MP/RPM settings.

I know that Airlines have departments that do this kind of review normally as it helps them catch trends in operational errors or deviations before they become problems, and ensure that the airplanes are operated efficiently. All of this reduces cost and should improve safety.

It occurs to me that this might be a service that could be offered to operators too, from a business with a web portal. So... forget I ever mentioned it until I get my business plan worked out.

 

[jesse]

Personally I don't want to be nannied when I rent an airplane.

 

[TMetzinger]

Personally I don't want to be nannied when I rent an airplane.

Well, operate it inside the envelope and you won't be! I think that if I were an owner of an airplane made available for rent, this would be a good thing for me.

I DO see your point, it's valid, and the market would have to show whether the idea is viable.

Data's a double-edged sword, I understand. I can see where a manufacturer might refuse to honor the engine warranty if they can show through my own data logs that I ran their engine contrary to their recommendations.

 

[OzPilot]

So... forget I ever mentioned it until I get my business plan worked out.

This is actually a great idea

 

[jesse]

Well, operate it inside the envelope and you won't be! I think that if I were an owner of an airplane made available for rent, this would be a good thing for me.

I DO see your point, it's valid, and the market would have to show whether the idea is viable.

Data's a double-edged sword, I understand. I can see where a manufacturer might refuse to honor the engine warranty if they can show through my own data logs that I ran their engine contrary to their recommendations.

It just depends on whose hands it is in. You'd have to tread carefully. Often "violations" would have no statistical significance from a maintenance perspective and "correcting" pilots is not going to be well received.

 

[TMetzinger]

It just depends on whose hands it is in. You'd have to tread carefully. Often "violations" would have no statistical significance from a maintenance perspective and "correcting" pilots is not going to be well received.

I agree. For our school, I think the things that would lead to discussions (with the renter or the CFI) would be things like the low fuel, or the flaps. Not so much a "you're not a perfect pilot" attitude as "we need to inspect the flap pushrod because you were going 15 knots over Vfe when you put them down".

 

[OzPilot]

Tim,
If an FBO or school was using this tool, with their continual uploading of data, other uses could include a historical look at engine performance or comparing against any other data set that has deviated from the median

 

[TMetzinger]

Tim,
If an FBO or school was using this tool, with their continual uploading of data, other uses could include a historical look at engine performance or comparing against any other data set that has deviated from the median

Right! I can forsee a LOT of use of this stuff, depending on what's logged:

Print a map showing where the airplanes have been.
Know about a TFR violation or near miss before you get the letter of investigation.
Monitor engine utilization and parameters like fuel consumption. Spot a potential failure before it happens.
Keep track of error events - bet there's a log message when your CO guardian is failing - for reliability measurements.

 

[Jaybird180]

Oooooooh, I'm Skrrrrrd

 

[HPNPilot1200]

We are dong this at Purdue with Alakai FDM. Grad students are working on using the data to research various operational practices and procedures. Actions taken from the analysis are non-punitive in nature and usually just results in a safety memo to all pilots or students. If a reg or limitation is clearly being violated, further monitoring with that knowledge can be taken.

The amount of flap deployments over speed was clearly evident within the first few weeks. The numbers were actually quite high.

 

[TMetzinger]

Interesting, Jason... Wonder how much work is involved to integrate the FDM with the Cirrus, and the types of data captured in comparison to the G1000 data files?

 

[HPNPilot1200]

Interesting, Jason... Wonder how much work is involved to integrate the FDM with the Cirrus, and the types of data captured in comparison to the G1000 data files?

I'm not exactly sure. We have a compact FDM box under the pilot's seat which records everything and transmits to the data over wifi to a data center. I believe there are over 150 parameters monitored at any given time.

 

[ajstoner21]

That kind of thing is already being done on some aircraft.

Just a quick google search found:

http://web.mit.edu/hchin/Public/HAI...to Structural Health and Usage Monitoring.pdf

A proactive maintenance kind of thing. Base maintenance schedules off actual usage, and not set hours flown.

"Regime Recognition"

 

[Everskyward]

Here's an AC about this. Look at Appendix II for examples of the various parameters which can be measured.

http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/0/40c02fc39c1577b686256e8a005afb0a/$FILE/AC120-82.pdf

 

[denverpilot]

I mentioned this "opportunity" to a CAP Crew Chief when I saw Kent's first posts about his trials of it.

Crew Chief said the SW version wasn't high enough and unless a version came out that was mandatory that had the feature, National was too cheap to have interim upgrades done.

I suppose that should have been obvious when they let all the TIS, XM Weather, Terrain, SafeTaxi, and all the other optional stuff that actually makes the G1000 useful, expire too. Only DB upgrades for the mapping are covered AFAIK.

Makes the G1000 transition easier when nothing works though!

 

[flyingcheesehead]

Now that the G1000 is offering data logging for pretty much all airframes, it occurs to me that there can be some benefits to operators who operate them, particularly if they have a fleet, like a school or FBO.

Were I running a school, I'd definitely be looking at the data, but mainly as a long-term maintenance tool. I probably would also make sure that renters weren't running full rich (16-18 gph in the DA40 as opposed to 9-10 gph) and weren't running the CHT's too hot. However, it'd have to be dealt with delicately - Nobody likes "big brother." Also, I've looked through a ton of the data already, and it's not quite as clear-cut as you'd like to think.

Depending on what info gets logged (Kent, if you have time, could you send me a file from your plane to play with?)

Sure - PM me your email. (EDIT: Never mind - See the next post.)

Hard landings - by matching vertical speed against altitude - if you get a high VS followed quickly by a constant altitude, you might have a hard landing.

I don't think you can determine this from the logged data. It's only logged once per second, so someone could have an almost-oops and save it at the last minute and it'd look bad. However, in reality, it's difficult to even determine the exact moment of touchdown. Many runways are sloped, and even the ones that appear level are no match for the 0.1-foot resolution of the G1000 log - So you won't see a constant altitude anywhere. (That 0.1 feet probably isn't actually accurate, at that resolution there will be a lot of non-ideal things going on with the static pressure, the transducer itself, etc.)

So, WRT touchdown there's really a period of several seconds where the actual touchdown could have occurred. You can see the plane decelerating through the published stall speed easily enough, but how much did it weigh, and what was the actual indicated stall speed? The altitude may be maintained within five feet from 75 knots all the way down to zero IAS, so where was the touchdown? Vertical speed has a lag, and must be sustained for 10-15 seconds to be accurate, and even dropping the last 5 feet in one second, which will be a pretty hard landing, will hardly (or not at all) register in the vertical speed field. Finally, the "bump" on landing may or may not register in the normal acceleration field as it'll be very brief, so if it happens midway between two data log snapshots it may not show up at all.

So, a lot of stuff isn't quite as easy to critique based on the data log as you'd think at first.

Operating flaps outside the envelope - this is a common thing on the DA 40 - I see students starting to put flaps down when they're too fast, or forgetting to retract them after departure before accelerating. Happens on Cessnas too and probably Mooneys

The G1000 does not handle the flaps, so it does not know their position and thus cannot log it.

Landing with insufficient fuel - we can "catch" folks who landed with less fuel than we liked and counsel them - either they didnt' set the totalizer correctly (lecture 1) or they did and they landed with insufficient fuel (lecture 2).

That one is doable.

Engine temperature issues - if we spot a high cylinder head temp, we can look at the data surrounding it to see what was going on and counsel the pilot on his operations. Same thing if we find abnormally high/low fuel flows for the MP/RPM settings.

Careful, though. I had a high CHT for probably two minutes yesterday before I noticed it and increased fuel flow to handle it. Two minutes = 120 lines = screenfuls of 400+ temps. If someone sits at 405 for a few minutes, I wouldn't even say anything... OTOH, if someone was at 450 for an extended period of time, clearly there was some abuse/neglect going on.

It occurs to me that this might be a service that could be offered to operators too, from a business with a web portal. So... forget I ever mentioned it until I get my business plan worked out.

I've actually been working on this, though software licensing issues might just kill it dead in its tracks.

Here's another example of something that could be done given lots of data from different airframes: Correlate CHT's with the various factors that affect them (OAT, airspeed, fuel flow, etc) and see if there are any outlier airframes... And then you can tell the client "Hey, we noticed that your #3 cylinder tends to run significantly hotter than the average DA40 #3 cylinder - You might want to have your AME check your baffling." Could save a ton of mx money and downtime, but there'd have to be an awful lot of processing going on to catch all of these sorts of things.

 

[flyingcheesehead]

BTW, here's a list of what gets logged in the G1000 on the DA40 once per second, the units and the resolution (software version 0321.22):

General:
Local Date (yyyy-mm-dd)
Local Time (hh:mm:ss)
UTC offset (hh:mm)

Flight instruments/parameters:
"Barometric (indicated?) Altitude" (feet, 0.1 foot)
Altimeter setting (inHg, 0.01 inch of course)
MSL altitude (no indication as to what this really is - Feet, 0.1 foot)
GPS altitude (feet WGS, 0.1 foot)
Indicated Airspeed (knots, 0.01 knot)
True airspeed (knots, 1 knot)
Groundspeed (knots, 0.01 knot)
Vertical speed (fpm, 0.01 fpm)
Pitch (degrees, 0.01 degree)
Roll (degrees, 0.01 degree)
Lateral acceleration (G, 0.01 G)
Normal acceleration (G, 0.01 G)
Heading (Degrees, 0.1 degree)
Track (Degrees, 0.1 degree)

Engine, avionics and systems info:
Frequencies on all NAV and COM radios (MHz)
GPS fix mode (enumeration, such as "3D")
Bus voltage (volts, 0.1 volt)
Fuel Quantity for each tank (gallons, 0.01 gallon)
Fuel Flow (gph, 0.01 gph)
Fuel Pressure (psi, 0.01 psi)
Oil Temp (deg F, 0.01 deg F)
Oil Pressure (psi, 0.01 psi)
Manifold Pressure (inHg, 0.01 inches)
RPM (rpm, 0.1 rpm)
CHT's on all cylinders (deg F, 0.01 degree)
EGT's on all cylinders (deg F, 0.01 degree)

Navigation:
Active Waypoint (ident)
Latitude (degrees, 0.0000001 degree)
Longitude (degrees, 0.0000001 degree)
HSI source
Course (degrees, 0.1 degree)
Horizontal and Vertical CDI positions ("fsd" - offset degrees, maybe? 0.001 degrees/dots/whatever the d stands for)
Waypoint distance (nm, 0.1nm)
Waypoint bearing (degrees, 0.1 degree)
Magnetic Variation (degrees, 0.1 degree)

Weather:
OAT (degrees C, 0.1 degree)
Winds aloft speed (knots, 0.01 knot)
Winds aloft direction (degrees, 0.1 degree)

Autopilot (if GFC700-equipped) settings:
Autopilot on (boolean)
Roll mode
Pitch mode
Roll command (degrees)
Pitch command (degrees)
Vertical Speed command (fpm)

And, some parameters that appear to relate to WAAS - I think the "mt" might just mean that we're not WAAS-equipped (as in "empty") instead of being a unit.
HAL (mt)
VAL (mt)
HPLwas (mt)
HPLfd (mt)
VPLwas (mt)

I've attached a zipped text file (comma-delimited, .csv) from a flight that I took with Pete and Larry back in November. Here's where you can play with graphs of that same data online: http://cirrusreports.com/flights/N569DS/224513

 

[TMetzinger]

Thanks a ton, Kent! I forgot that the flaps aren't indicated in the G1000 in the Diamond or Cessna. Too bad. Lots of good stuff to do with other data though. Shame that the fuel quantity seems to be driven by the floats, and not by the totalizer. On the one hand it prevents negative numbers when the pilot forgets to set the totalizer, but on the other I'm not sure how accurate it would be. Probably enough for the "snitch" function I have in mind, though.

 

[Jaybird180]

Would extending maintenance schedules based on the data be legal? I suspect not, and therefore this would have no value for Mx cost savings.

 

[JeffDG]

Would extending maintenance schedules based on the data be legal? I suspect not, and therefore this would have no value for Mx cost savings.

Well, you could go to the trouble of creating a customized inspection and maintenance program based on the data and having it approved by the FSDO..."Progressive inspections" are available to piston-engine aircraft, just most people don't go to the hassle of getting a program approved so are left with the "default" annual schedule.

 

[flyingcheesehead]

Would extending maintenance schedules based on the data be legal?

Yes, provided you get a program approved as Jeff states. But even if you don't...

I suspect not, and therefore this would have no value for Mx cost savings.

Au contraire. See the example I gave above. Fixing your baffling is a lot cheaper than replacing a cylinder that's hosed because it always ran too hot. There are many other possibilities, too.