What you can do with the GRT EFIS....
 

It's late, I had a good day flying (two flights with two different CG test points), and I thought some of the more technically-minded might enjoy this little example of what we can do with the modern EFIS capabilty. The GRT folks designed their system with the capability to record flight data, so that you could play it back through the EFIS itself, and "relive" your flights - or give cool demos at trade shows!

Seeing as how I am supposed to be a flight test engineer, I thought "wouldn't it be cool if we could use this capability to record the data in realtime, and then import it into a computer post-flight, allowing easy data reduction?" Surely, it would be more accurate than the traditional method of trying to fly and record data by hand at the same time - or recording the panel on a video camera, and then hand-recording the data back home.

I posed this question to a few folks on the web, and to some of the engineering Coop students at work, and can take no credit at all for the resulting programming - I haven't written code since my early days with Basic and Fortran. But their results are amazing!

Let me share today's products. I went up to fly pitch stability Phugoids - trim for a speed, pull up to slow about ten knots, then go stick free, and watch the results. From this, you can plot the period of oscillations, and determine whether or not the oscillations are damped (ie, the aricraft wants to return to the trimmed condition, and is therefore stable). Do this at several CG's, and as you move aft, you should discover where you go unstable.

I flew two such missions today, one at the forward end of the CG box, and one about 2/3rds of the way aft. Recorded the data, decoded it, and fed it into Excel. Took me about three minutes to produce the following plot. The X-axis is time, in 1 second intervals. The upper "squiggle" (green) is airspeed, the lower squiggles are pitch (pink) and roll (blue) angles. The "spikes" in roll are simple event markers I fly into the data - a quick doublet signals the start of a Phugoid, another, the end. That allows me to quickly find the times of interest in the large data files. The real data is in the pitch oscillation and the IAS.

This plot is for the aft CG positon, with a data take trimmed on about 120 knots, followed by one about 90 knots. For an engineer...this is COOL! :cool:




Now you know what engineers do on a Saturday night.... :rolleyes:

Paul

GRT Data output questions
 

Paul, I like it. I have a couple of questions, if you have a moment.

Does the GRT also log yaw? If so, it seems like with a bit of software, you'd have this: http://www.appareo.com/

I don't quite understand what the coop students did - I thought the GRT output ASCII data in an RS232 stream, perfect for importing to Excel. I guess if I have this wrong, then they must have read the binary data and converted it to ASCII.

It wasn't that simple....
 

Mickey,

I originally thought it was as simple as decoding an ASCII string, but that is not the case. The EFIS records bursts of data from the EIS, AHRS, and GPS datastreams. The resulting file needs to be decoded and calibrated. GRT was kind enough to share their data definitions with us (which they were under no obligation to do - great company!), and that gave us an undertsanding of how the files were structured.

The real hero of this project is RV-7 Builder Carl Morgan, down in New Zealand (I love the international collaboration aspects of the Internet!). He is the one that wrote the code that takes the raw datafile and converts it into an XML file which can then be viewed in a browser in columnar format. From there, I just cut and paste into a spreadsheet, and then I can manipulate the data any way I want!

Yes, the datastream includes Yaw - in my example, I just picked three columns of interest for this test. Anything that is displayed on the EFIS is either recorded, or can be generated from what is recorded (TAS is not recorde for instance, but IAS, OAT, and Pressure Altitude are...so you can compute it easily).

My Coop students are another story! Seeing as how there are a bunch of Aero Engineering students running around our campus all the time, I recruited a few of them that were interested in being invovled in a real flight test program. We get together in the evenings, I pass on the techniques and theory behind flight test, we talk about what tests they are interested in working on, generate test cards, and then they reduce the resulting data after I go fly them. Sure, I could do it all myself, but this gives them the opportunity to do something that they probably will not get in school! I would have killed to be involved in a real flight test program back in my college years - it was not until I got out that I was able to do this stuff for real.

Paul

Grt
 

Thanks a lot for the info. Much clearer now.

I hope you post your test cards some day so those of us that come behind you can stand on your shoulders!

Neat stuff Paul.

I'm working on a similar capability, in my spare time when I'm on the road. I've wired up my Dynon EFIS, Grand Rapids EIS 4000 Engine Monitor and the GNS 430 so I can grab the serial data. The serial output of each box is wired to a separate jack. I connect a cable from each jack to a Keyspan 4 port USB to serial adapter, then plug that into the USB port of my laptop. The laptop will be strapped down in the rear seat area.

I initially wrote my own perl scripts to decode the data from each box, append hi resolution computer time, and write it to file. Later on, Mike, from I know-not-where, got interested, and he sent me a much nicer perl script, with a GUI, that puts all the data in one file. There are a few bugs to work out of his script, but it should eventually be released to the world.

I was on the road last week, and spent my spare time cobbling together some perl scripts that grab specified time slices of data, then create data plots using predefined formats. I'll create plot formats for different types of testing, which will save me a lot of time when it comes time to plot data. And several flight test engineers from work are itching to help me analyze it.

For test cards, I've put all my planned test points in a MySQL data base, created LaTeX formats for a test card, and most types of test. Tables in the database hold weight and balance data, loading info for each flight, and the test point numbers (and execution order) for each flight, etc. Once I pick the test points for a flight, I run a perl script that pulls the data from the database, poplulates the LaTeX templates with test point data, and about 10 seconds later I'm looking at a test card in pdf format. The script also alerts me if the loading for the flight isn't compatible with the weight and CG range I've specified for each test point. I've got a few things to sort out, such as adding tracking of completed test points, test points that need repeating, plus create templates for some of the test types, etc. I'll release it to the world once I have it working the way I want. Here is an example of the automatically created test card. All the tests on that card obviously wouldn't be on the same flight, as they need different CGs - it just shows some of the different aspects of the test cards.

You're going to be like me Kevin - when I first looked at a 40 hour test period, I said "man, that is going to take forever! What am I going to do with all those hours?!"

Now I go "Boy, I hope I can get the basic stuff done in 40 hours so I can at least sign it out of Phase 1 with a good conscience!"

So many test points, so little time... :p

Of course, one of the coolest things is that once you have collected the data, and if you keep good notes, you can always go back and look for interesting stuff in previous flights. Good for those long cold rainy days when you can't fly....

I actually got a lot of inspiration from your web site Kevin - I just don't personally have the up-to-date programming skills (or time) to do all the things that you are doing - I took the easy way out with the GRT data stream and a thumb drive. I still can't believe how much info I can store on one of those! The technology is advancing so fast....give it another six months, and you'll be able to buy a realtime telemetry system at WalMart... :rolleyes:

Paul
(no flying for a couple of days - gotta go on a work trip...) :(

Imminent Test Flight
 

Paul and Kevin,
I must admire your engineering expertise. Only hope you have in sorted soon as I expect to be doing my first flight in the next month.
Will advise.
Pete James.
Australia.

Share Code?
 

Way cool!
 

Paul,

This is fantastic! I would certainly have given a lot to be involved in a flight test program like yours when I was at college. Is there any chance you could share your software? Although I am only running a GRT EFIS at the moment I'm planning to install an EFIS in a few months. I would really like to capture data like you have.

I'm at little suprised at the low damping of the phugoid, although the period is quite long (~15s, time base is quite compressed) so I guess its not an issue, or its the price we pay for light stick forces. Can you share your data at a more forward cg? Did you find the point at which it was not damped? What was your cg position, in terms of mac, at that point? Do you have any dynamic data, such as SPOs? I'm guessing that it is much more difficult to measure stick force or elevator per g, do you have any such data?

Sorry for all the questions, but any answers would be gratefully received (by direct email would be great if not of general interest).

Pete

Quick Answers...
 

Glad that folks are interested in this stuff!

As for sharing the code...it's not mine to share....(I actually don't even have a full copy - it resides on his web site) but I know that Carl is planning on letting it out. I think he is doing some polishing to make it ready for the general public. I'll certainly let everyone know when he decides it's ready for prime time. In the meantime, if you are flying a GRT EFIS and doing testing - record and save all your files, and they can be decoded anytime after that!

Pete, I'll have to digest some of your questions when I have a little more time. The period of the Phugoid is actually about 30 seconds for this case, and so far I have found little variationin that with CG. It does appear to be more damped at foward CG, as expected. This was just a quick example of what we can do!

Paul