|
Data logging is a feature found in just about every modern glass panel instrument. It offers an ability that is hard to match with a clipboard in the cockpit - massive quantities of data on just about every parameter!
The Dynon Skyview I installed is a fantastic instrument. The Skyview is a network of pieces that all integrate together seamlessly. The display, engine monitor, air data box, gps, and so on. The display is the heart of the system, and automatically records every input into the system into a downloadable file. The amount of data is staggering - literally. The default rate of data logging is 8 times per second. For an hour long flight this will produce over 30,000 lines of data! That much data will literally bring Excel to its knees. I reduce the frequency of data to once per second and this is more than sufficient. The on-board memory will hold 30 hours of data at this rate!
The data log offers the user a great way to review previous flights. I have been downloading the log after each flight and trimming the file to just the entries for the most recent flight. I then save this as a new file for each flight. Importing the file into Excel allows me to review the engine performance, airspeed trends, determine rate of climb, or look at my ground track in Google Maps or Google Earth.
I've included a few samples of the graphing and analysis that can be done in Excel. Several were generated from the first flight data log. You can see how the engine was running, how closely the CHT's are matched (#3 is my hot cylinder), whether reducing the throttle causes a spike or drop in oil pressure or if RPM follows fuel flow.
I reviewed the data file for the saw-tooth climb series I performed during Flight #6. I used a manual data-gathering method to collect data leading to Vx, Vy, and Slowest Descent speeds. Out of curiosity I graphed the data for Flight 6 and carefully reviewed the segments associated with the climb-descent portion. The graphs below correlate airspeed with altitude to identify each climb-descent segment.
Each climb-descent segment produces a distinctive peak on the graph. The shape of the peak tells how good the test was. If the altitude line rises at a consistent rate (i.e. constant slope), then the climb was well stabilized. If the peak is abnormally shaped or rounded, then the data is likely of poor quality. The airspeed stability (or variation) is also visible on the graph. Ideally, the airspeed is spot-on during the climb & descent, but in practice that can be hard to do. The graph tells the story.
Once I had reviewed the graph and made notes of where the "quality segments" were located (i.e. small airspeed fluctuations, steady slope on the altitude trace), I went back to the raw data and extracted the beginning and ending altitudes and elapsed time and re-entered those numbers into the Climb-Descent spreadsheet. This produced slightly different graphs than my initial data sheet numbers did.
What conclusion can we draw from this? If the data is quality data, then the two graphs should agree with each other pretty closely. However, as we introduce more scatter in the data, fail to hold airspeed exactly, make the occasional timing error, or simply encounter bumpy air or changing winds, the two results will differ. My conclusion from analyzing Flight 6's data set confirms what I believed during the course of the flight: The data gathered was useable, but not very high quality due to the conditions in flight. The variation in the resulting graphs tell the tail. I'll plan to run another saw-tooth climb set in the future. In the mean time, I'll continue to use the numbers gathered here (they're probably pretty close anyway).
Resources for data log analysis and manipulation:
| 
