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!




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

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...

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...

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?

So, Paul, will you be sharing the code for parsing the data stream from the GRT EFIS? If not sharing, then how about for a contribution?

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

penguin said:

Paul,

I'm guessing that it is much more difficult to measure stick force or elevator per g, do you have any such data?
Pete

Click to expand...

There are CAFE Foundation reports on the RV-6 and RV-8A which include stick force per g. I don't remember if they included elevator deflection per g. They're free on the CAFE web site, www.cafefoundation.org

Cheers,
Martin

Not sure how this relates to Kevin's work, but somebody has posted data logging software on Dynon's support forum:
http://dynonavionics.com/cgi-bin/yabb2/YaBB.pl?num=1131123528

It's very cool to have these tools available for post-flight analysis.

Dave

Ironflight said:

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

Click to expand...

In theory, the period of the phugoid should be proportional to the TAS, if I recall correctly from my TPS classes (too many years ago). Two different aircraft types should have the same phugoid period, if the tests are done at the same TAS. In the type certificated world, it is considered acceptable for the phugoid to be very lightly damped, even slightly divergent, as the period is so long that the workload to control it is normally very low.

Data logging scripts available

Davepar said:

Not sure how this relates to Kevin's work, but somebody has posted data logging software on Dynon's support forum:
http://dynonavionics.com/cgi-bin/yabb2/YaBB.pl?num=1131123528

Dave

Click to expand...

That software, the Waiters Flight Data Recorder looks quite interesting, but it has no relation to the stuff Mike and I are working on. It is a Windows-only solution. Our scripts use perl, which is freely available on Windows, Linux and OS X (which is what I'm using).

I'll post in this forum whenever Mike's scripts are ready for release. I suspect we are a few months away from that though. I've stopped development of my original script, because Mike's looked so good. But there is at least one major bug to exorcise, and many small features to add, before it is releasable. And Mike has other things going on, so it is often many weeks between updates.

Edit - I must be getting old, as I forgot to mention that my data logging scripts (Dynon D10A and GRT EIS 4000) are available on my web site. They are very crude
Perl scripts, but they work. I've tested them on OS X 10.4.2, but they will almost certainly work with Linux, and I did have an earlier version working with Active State Perl on Windows and OS X 10.3. The current version hasn't been tested on Windows. Get the scripts here.

GRTDecode Announcement - Cross Post from GRT Yahoo List

My main form of contact for this will be via the GRT Yahoo List, please see / use that for upto date info / contact.


Hi all,

As has been mentioned I've been quietly working on a utility to extract information for the .LOG files that can be recorded on a PFD.

Well after some help with specs from GRT (thanks Jeff / Greg) and some testing by Paul Dye (ironflight) it is as ready as it is going to be for a public release.

Please bear in mind this is un-supported by GRT and will only get limited support from me, any data errors I'm very keen to get flagged but otherwise as I don't have a flying plane (and I'm still in the waiting list for a GRT dual PFD system), I must focus on other things as a priority ;-)

Some notes / things to be aware of:

• This is a commandline utility - no windows use interface so you will need to use a 'DOS' window and type a command line.
• ALL values are currently un-validated - I've implemented the specs as best I know and the numbers 'look' right, but without careful testing with known cases I can't be SURE. If you can validate / test / confirm / prove one way or the other I (we all) would like to know.
• The analog values require calibration constants - these are specific to a PFD (ie. therefore playing a .LOG on a different PFD to the one it was recorded on will provide a SLIGHTLY different representation). Currently the constants are hardcoded - but visible in the XML output. I may be able to refine these to 'theoretical values' given some time and hopefully long term we will be able to read the constants dynamically as needed.
• GPS decode is only working for 'aviation format'
• I'm unsure of some of the units - eg. degrees C / degrees F, knots / mph, litres / gallons and it will vary depending on your setup - just be careful and validate some known points before you start 'trusting' the data.
• The XSLT sheet is available via my website - this provides an easy way of presenting the data in a neat manor and also providing a prompt for new versions when they are released.
• No error checking is done on the inbound file stream - it may be that strange results will get generated if something starts going awol.
• Beware of the XML file sizes - they can get VERY big, very quickly. The non-summary functionality is there, but you probably don't want it. Likewise the verbose option adds detail to the XML but little value for normal use. The XML files do compress well however.

Once things settle down a little, I would like to methodically work through each of the parameters and get positive confirmation of readings with different people. This will need a combined effort as it depends on what configuration / connections different installations have and time / effort to coordinate the results.

The web page:
http://www.rvproject.gen.nz/grt/

Example output:
http://www.rvproject.gen.nz/grt/TESTDATA.xml

I suspect this is going to generate some interest / workload - please bare with me if things are taking a bit of time.

Regards,

Carl
--
ZK-VII - RV 7A QB - fuse / engine
Cromwell, New Zealand
http://www.rvproject.gen.nz/

Carl is the Man!!!

.....and now that Carl has released the beast into the wild, I want to say again just how much of an incredible service he is providing to those folks with the GRT EFIS!

He has been working on this utility for just a couple of weeks, and had the first version running in only a couple days after I posed a question on the GRT Yahoo group. They must have really long days there in New Zealand, becasue he seemed to be working on it at just about every moment of our day and night.

It does take a little command-line-savvy to run, but once you figure that out, you can convert files pretty fast. (My modern-computer-savvy Coop Student Task Force had more trouble with DOS than I did - I guess that means I am gettign really old....).

All of the AHRS/EIS data appears to be in common units - Knots, feet, degrees F, etc. A few things like Manifold Pressure are uncalibrated, but since you know the scale factor and bias values for your specific MAP sensor, it is easy to compute. Volts are in volts. I have found little need for the EFIS analog paramters yet.

This is the "Killer App" for the GRT EFIS.....


Paul

Carl,

Thank you, thank you, thank you for your efforts. Way cool. I contacted GRT a month ago asking for the data definitions but it's been a month and I just bugged them again. I'm a aircraft performance engineer for a major airline and I write a lot of code at work so you can be sure that I was interested in doing what you're doing.

I know there's a lot of talented RV people out there - maybe we all could help out or figure out what we really want to do.

We use APM/ETM (aircraft performance monitoring & engine trend monitoring) here at work to diagnose problems before they arise (hopefully). I can try to incorporate some of that methodology.

I sort of want to get the data log real time so I can either store it to a laptop/PDA and do other things with it.

Just wanted to let ya know that there are others out there...

Thanks again,
Scott