One of the primary objectives of beta test is to automate the calibration process; but for now we are still doing it the old-fashioned way. Our focus at the moment is getting the Sling LSA aircraft at the Sling Pilot Academy equipped with Gen 2 V3 systems. Except for final programming and bench test, the hardware is ready to go. Concurrently, Bob Zaleski and his team of high school flight test engineers have been generating the data that we need to develop aircraft curves for the Sling. I thought it might be interesting to step through the first part of the data reduction process to share how the sausage gets made at this point.
Bob and his team have been using the autopilot to assist when flying GPS speed runs. This helps achieve stable parameters required for a successful trim shot. The high school flight test engineers have been doing an excellent job recording data, including z-time for each run. A run consists of 3 or 4 legs at least 90 degrees apart. Bob has been using a technique of flying an equilateral triangle, always using the same three headings, which helps me locate data for analysis more quickly when I'm looking at a large table.
Data are recorded by the Gen 2 V3 and the Garmin G3X EFIS system. The Garmin data includes information that we don't record in the V3, and it records at a much slower rate (1Hz); so before I look at the high-rate 50Hz V3 data, we find the trim shots we want to use for analysis using the 1Hz Garmin EFIS data. After each flight, Bob downloads data from the V3 box and the EFIS. Data and a copy of the run card are e-mailed to yours truly for analysis. Since these airplanes are used in a primary training environment, we want the calibration to be as accurate as possible, which means lots of flight test and data reduction to be sure we've got it right before we turn it over to a student pilot.
The first step is to take the 1Hz EFIS data open it in Excel and re-arrange the columns. I delete columns not required. After I’ve got the columns arranged in a usable format, I then highlight in yellow the start and end of each run and annotate “start” or “stop” with the run # and flap configuration. I'll add other notes as required, so this 1Hz data file becomes a notebook reference for each sortie. When you look at these portions of the tabular data, it’s easy to spot each leg of the run by scanning the “heading select” value, since Bob is using the autopilot and Garmin records these data. Once the GPS ground track stabilizes after a turn (until the next turn), I start to look for a trim shot (or two) on the leg. We define a trim shot as 1-3" of stable flight, on parameters; so I like to isolate 6" chunks to drill down into in the next step of the analysis process.
A perfect trim shot would have stable pitch, airspeed and power settings throughout the duration. However, a perfect trim shot does not exist in the real-world, so we are looking for the best combination of relatively stable parameters. The first step is to plot IAS and pitch over the duration of the leg. The reason I start with IAS is because ultimately, we are looking for pressures in the high-rate data. Since IAS is pressure based, a consistent IAS across three legs (regardless of accuracy of IAS) indicates that pressures will be similar for each set of high-rate data. In a perfect world, a leg will have an airspeed variation of +/- 1 KT or less at a constant power setting. By graphing IAS, I can determine how well it was controlled for the duration of the leg, and also find stable parameters at the desired test (pressure) condition.
The other parameter that I graph is pitch. In stable, level flight, properly boresited pitch effectively equals geometric AOA (after we correct for incidence). Like IAS, pitch should be roughly coincident across each of the runs. These pitch values will also come into play when we “sanity check” the absolute AOA computed during the final phase of data reduction. Pitch, like AOA, is a noisy parameter, but if things are relatively stable, a good value can be determined by averaging the data over the duration of the trim shot.
By using the airspeed graph, I find a time hack that I want to look at more closely. If the run card called for 70 KIAS, I’d look at that graph to find a set of stable values at 70, +/- ½ knot. Some runs are better flown than others, and on some it’s quite easy to find a good chunk of data, while on others not so much! Fortunately, we don’t need much, since the V3 is recording at 50Hz. Another key parameter is power setting. It should be stable throughout the trim shot as well as prior to the shot. If power is changing, I can’t really call the condition “stable.” After I have a time hack to look at, I highlight the line in orange, and then build out from there +/- at least a couple of seconds. When I do this, I eyeball GPS track and ground speed, VSI and altitude to see how well those parameters are dialed in. The more stable the trim shot, the more lines I may include to refine the average even more. After I’ve highlighted the lines I think will make a good trim shot, I perform some rudimentary analysis to establish the quality of the data. In some cases, a couple of portions of a leg may be good, so I'll highlight both and then use the statistical tests to determine which one will be the final trim shot for that leg.
The “avg” value is simple the average of the numbers selected for the trim shot. The next step is to define one standard deviation (“std dev”) value. Then I apply a standard error test (“std error”) to quantify the stability of the value. Obviously, we are looking for low standard deviation and error numbers, which mean the data are stable and quiet. There is actually quite a bit of TLAR (that looks about right) in this process, because I’m old school. I’m confident a young engineer well versed in MatLab could probably largely automate this process (and work a lot faster than I can!); but we don’t plan to do too many more manual calibrations.
What’s next in the manual calibration process: after the GPS speed runs are finished and we've developed these tables for each leg, well run those GPS track and speed numbers through a separate spreadsheet that calculates TAS and static source pressure error. With those data in hand, then I will drill down in to the high-rate data recorded by the V3 box to find Pfwd and P45 pressures for each trim shot. After I’ve built a pressure table, I’ll calculate aircraft weight and horsepower used for AOA calculations. All of those data will go into a third spreadsheet that will calculate absolute AOA, which we’ll plot and then curve fit to develop the aircraft curves. Once we’ve plotted the aircraft curves (4 total, one for each flap setting in the Sling), we’ll determine how many are required for accurate AOA information—it may be possible to combine some of them. Or not. We won't know until we look at the curve plots. After all of that is complete, we’ll program those curves into the V3 software. Lenny is currently modifying the software to accommodate logarithmic curves, which give better post-stall/high AOA performance the 2nd order polynomial fit we were previously using. After the curves are programmed, then we flight test to determine set points. The wifi interface is currently in flight test, so after we confirm that is working correctly, it will only be a matter of flying a particular configuration and speed and pressing an “input” button to insert the set points. We hope that the Sling aircraft are common enough that only minor set point adjustments may be required after we finish up all of the tedious work!
Comments