Flight Data Recorders: Foreflight logger, Arduino, Raspberry Pi

Hi all,

Lately I've gotten the bug to create a Flight Data Recorder using an Arduino or a Raspberry Pi. I've read Nigelspeedy's entries with interest, but he has the use of a system that's well beyond typical amateur finances.

I don't have a modern EFIS system that does the logging and I'm not likely to re-do the instrument panel any time soon.

This posting asks the questions:

1) Is Foreflight data logging data sufficiently accurate for Flight Test/40 hour Phase 1 work?

2) Is an Arduino or Raspberry Pi with GPS and data logger add-ons, fast and accurate enough for Flight Test/40 hour Phase 1 work.

My "yardstick" would be that I want a system that is accurate enough and fast enough to collect data for the Phase I, 40 hour fly off and the POH production.



One can get add-ons for either the Arduino or the Raspberry Pi that supply GPS data - longitude, latitude, and altitude, as well as data loggers which can store the data. So on the face of it it seems possible to build a system that will acquire the necessary data. And I've read article/s blogs, web pages where people have done that.

You could also add an OAT temperature gauge and perhaps even a sensor that's plumbed into the pitot system. That would be very handy.

But I wonder about the speed and accuracy of such systems.


But then I remembered my Foreflight/iPad will log flight data and I looked at some of the KML files. I'm wondering if this is accurate enough. This is what I saw:

<altitudeMode>absolute</altitudeMode>

Evidently this means height above sea level. But what does it use for "sea Level"? MSL?


I have to figure out what this line means:

<gx:interpolate>1</gx:interpolate>


What is it interpolating? Successive GPS readings? How does this affect accuracy?


Then there's the data:

<when>2017-05-20T19:11:54.62Z</when>
<gx:coord>-70.911008 42.585208 31.0</gx:coord>

<when>2017-05-20T19:11:56.35Z</when>
<gx:coord>-70.911004 42.585210 32.0</gx:coord>

<when>2017-05-20T19:11:57.88Z</when>
<gx:coord>-70.911004 42.585211 32.0</gx:coord>

<when>2017-05-20T19:12:01.88Z</when>
<gx:coord>-70.911001 42.585216 33.0</gx:coord>

So the readings are not once a second. And here is a big jump of 5 seconds:


<when>2017-05-20T18:56:01.38Z</when>
<gx:coord>-71.471201 42.562610 1719.0</gx:coord>

<when>2017-05-20T18:56:05.02Z</when>
<gx:coord>-71.468250 42.562614 1714.0</gx:coord>


Are these data accurate enough to use to back out course, speed, climb/descent rate, takeoff roll?

I've done a search for Flight+data+recorder in the forum and there are some entries - mostly old.


Any thoughts would be appreciated.

Check this out for a small, cheap, and easy logger: http://www.vansairforce.com/community/showthread.php?t=84045&highlight=logger

The thread is a bit old but should still work.

It can log most any serial stream.

Brantel said:

Check this out for a small, cheap, and easy logger: http://www.vansairforce.com/community/showthread.php?t=84045&highlight=logger

The thread is a bit old but should still work.

It can log most any serial stream.

Click to expand...

As I wrote at the start of my post, I don't have an EFIS that supplies the requisite "serial stream".

I'm confident the data logging capabilities of the Pi or an Arduino will work.

it's the data ACCURACY of those systems - as well as the Foreflight data logger - that I'm asking about.

There are several ways a person gcould attack this, depending on whether you want it to be something quicker and easier, or a "hobby project" for severe geek appeal.

If you were to start with the standard Stratux hardware, you'd be most of the way there. You wouldn't be using the Stratux software, but writing your own. As a bonus, all you need to do is swap out or re-write the SD card and add a couple of receivers, and you have a Stratux.

The Raspberry Pi will provide far more compute power and storage than you're likely to ever need. The AHRS/fan control board gives you a 3-axis accelerometer. The commonly used GPYes sends a position every second by default, but can be configured to send it more often. You could, if you wanted to, add an OAT sensor and differential pressure sensor for airspeed. All the parts are available off the shelf, I think. The code could be pretty simple, especially if you're not doing any fancy graphical display. Al you need to do is collect data from sensors and log in in some sort of text format, like a CSV file - or JSON, or whatever else you want. Analysis with Excel or Splunk after the flight will let you plot out whatever you want to see.

There's also a guy who rolled his own from scratch, if you want to go that route: http://www.dangerpants.com/labs/adi/ I don't think it logs, though, so you'd probably need to modify the firmware and add some sort of external PC-readable storage to do that.

As for accuracy, I guess it depends. I haven't looked at large amounts of flight data to know if there are gaps or inconsistencies. GPS antenna location might be the biggest influencer; if you spend a lot of time upside down or at high bank angles you might lose GPS briefly. Don't know. I'll see if I can get my Stratux to log the GPS data stream to a file the next time I fly. I know Avare will show a smooth and accurate flight path even when I'm having fun, but I really never get past about 80 degrees or so of bank.

It never made it close to production, but I put together the beginnings of something like this. It consisted of a project box containing an Arduino with 3 sensor boards - a GPS receiver, a 10 DOF sensor (accelerometer, gyroscope, magnetic compass, pressure and temperature) and an extra pressure sensor. I planned to plumb my pitot & static lines to the box (second pressure sensor in an enclosed compartment). The Arduino would have been a complete GPS enabled ADAHRS. I was feeding a serial output of this data to a Raspberry Pi for both data logging and a simple EFIS written in Python. It was ambitious and I ultimately abandoned most of the project and bought a AVMAP UltraEFIS as my backup EFIS. I don't have any doubt that I could have completed this project and it would have functioned reasonably well, the Arduino and the sensors were certainly capable of the processing and were easily providing reliable resolution, I think I had it doing 1 data collection per second.

My second version of this did make it into my plane, although I'm not using it at all. This was just the Raspberry Pi with a 7" touchscreen. I'm getting serial feeds from my Skyview and its GPS receiver. I had plans to make it a data logger, but it proved to be unnecessary as I can get everything I need from the SkyView user data log. I did build a moving map for this and that will be in production in the near future, but I'll be stripping everything else out. The map, based on OpenStreetMap will give me a little bit of extra reference but even that is of limited use with Skyview and Foreflight. Ultimately, this project really wasn't worth consuming the 50 or so square inches of panel space that it did. Definitely worth it on the "geek having fun" scale though.

To your original question, I used my data logs extensively for my test phase. GPS data alone (Foreflight) is of limited value. You need air data - IAS, altitude and OAT. The EMS data is quite helpful as well. Without these, manual data logging will be needed.

Good luck with this endeavor, if you want specifics on what I did on my first attempt, PM me.

Saville said:

As I wrote at the start of my post, I don't have an EFIS that supplies the requisite "serial stream".

I'm confident the data logging capabilities of the Pi or an Arduino will work.

it's the data ACCURACY of those systems - as well as the Foreflight data logger - that I'm asking about.

Click to expand...

Serial streams don’t have to come from an EFIS. Also the logger code could be slightly tweaked to log data from thousands of possible sensors at a very high rate.

For home brew sensors...accuracy depends on the resolution of the A to D converter in whatever device you are using has.

You can get some very high accuracy and high update rate GPS units.

Can’t speak to Foreflight because I don’t use it.

Traveling at 170kts your covering 283 feet a second. Even the worst data logger will give useable data. As stated, its all about the accuracy of the sensors, but even the cheapest sensors nowadays are better than the best of them during the apollo days.

Bob burns
Rv4 n82rb

If it’s in your price range, you could buy a complete Stratux unit with GPS +AHRS and use its internal logging feature to capture everything. (A complete Stratux is under $250 https://amzn.to/2VbbW3F)

After your flights, you just off-load the log file from the unit. Use of one of its supported apps is optional.

The nice bit about a Stratux is they have already don’t all the heavy lifting of sensor fusion so the AHRS and GPS day is usable without any additional coding.

You also have ADSB-IN for all those cross country flights you’ll take after phase-1

Costs and time could get interesting for a DIY system.

You could update your panel to a 7" Dynon system and get full engine monitoring too - heck ignore the Dynon flight portion and configure it as an engine monitor only.

Around 6K



But I do have to admit DIY is more fun...

az_gila said:

Costs and time could get interesting for a DIY system.

You could update your panel to a 7" Dynon system and get full engine monitoring too - heck ignore the Dynon flight portion and configure it as an engine monitor only.

Around 6K

But I do have to admit DIY is more fun...

Click to expand...

DIY would cost $100 give or take and some time.

Were I to update the panel the task would take me months just to do the panel. Then there's the question of whether or not I'd have to swap out autopilot servos etc.

I don't have lots of free time to do major projects on the plane.

But I have the time to work in the shop at home on a DIY project for a unit that I don't always need to have in the plane and operational.

The Stratux idea is within the realm of cost vs time considerations.

Saville said:

DIY would cost $100 give or take and some time.

Were I to update the panel the task would take me months just to do the panel. Then there's the question of whether or not I'd have to swap out autopilot servos etc.

I don't have lots of free time to do major projects on the plane.

But I have the time to work in the shop at home on a DIY project for a unit that I don't always need to have in the plane and operational.

The Stratux idea is within the realm of cost vs time considerations.

Click to expand...

Yes... it all comes down to a balance of time - money - location....

I did think the sensors would be more expensive.

Which parameters are you thinking of logging?

As I said, DIY is more fun.

If you want to log performance data, you?ll want airspeed altitude. You can derive vertical speed. GPS will be much less important, and not good enough for performance data.

Saville said:

But then I remembered my Foreflight/iPad will log flight data and I looked at some of the KML files. I'm wondering if this is accurate enough. This is what I saw:

<altitudeMode>absolute</altitudeMode>

Evidently this means height above sea level. But what does it use for "sea Level"? MSL?


I have to figure out what this line means:

<gx:interpolate>1</gx:interpolate>


What is it interpolating? Successive GPS readings? How does this affect accuracy?

Click to expand...

KML uses WGS84 projection and altitude is based on EGM96: "The KML encoding of every kml:Location and coordinate tuple uses geodetic longitude, geodetic latitude, and altitude (in that order) as defined in Annex B. Note that altitude is measured from the vertical datum, which is the WGS84 EGM96 Geoid. The altitude measurement (orthometric H) is illustrated in Figure 1."

http://docs.opengeospatial.org/is/12-007r2/12-007r2.html#14

gx:interpolate is a google extension (hence the gx prefix). Its documentation is: "Boolean value. If the multi-track contains multiple <gx:Track> elements, specifies whether to interpolate missing values between the end of the first track and the beginning of the next one. When the default value (0) is used, the icon or model stops at the end of one track and then jumps to the start of the next one."

https://developers.google.com/kml/documentation/kmlreference#gxinterpolate


I don't know what coordinate system a COTS GPS will use but it's likely to be WGS84.

One feature that might come in handy would be a user-settable flag, that you can use to denote the beginning or end of a test run, or a specific GPS location, or something of that nature.

Dave

David Paule said:

One feature that might come in handy would be a user-settable flag, that you can use to denote the beginning or end of a test run, or a specific GPS location, or something of that nature.

Dave

Click to expand...

That idea occurred tome as I was flying wind direction determination circles last week and using my Foreflight Track Logger to capture the data:

If I had a Flight Data Recorder (FDR), the wind direction and speed circles would be useless to me because I needed the results during the flight in order to then fly the upwind and downwind legs.

But if I had a simple display for, say, a Raspberry Pi FDR and a button, I could start the circle, press the button to tell the Pi to begin recording. Press the button when the circle was complete, and that would signal the FDR to:

1) Stop recording
2) Determine the min and max GPS ground track speeds
3) Determine the GPS heading for those min/max speeds
4) Display that data on the simple display.

So last week I decided to fly some simple tests to determine how useful the Foreflight Track Logger is in capturing data for Flight Tests.

So I flew a simple plan which consisted of taking off, flying wind speed and direction circles at 5000 feet and then again at 8000 feet, then doing some simple aerobatics to see if the Track Logger could also be used to tell me how I'm doing with the acro.

The results were interesting. I downloaded the CSV file from Foreflight and wrote some Python to capture the data and plot it out in 3D.

The short answer is - the Foreflight Track Logger might be useful for Phase 1 flight test of climb, airspeed calibration,best glide, Vx Vy determination etc.

Doesn't seem to be useful in showing a round loop.

This is the 3D plot of the full flight. The roll, loop and roll is the track at the far right of the plot:



This is a plot of speed vs data point from Foreflight. It clearly shows the 4 circles I did at 5000 feet and the 3 I did at 8000 feet. It would be simple to extract the min and max speed from the data as well as the course at those speeds:



But one thing I noticed was that when I executed the loop, the data capture rate seemed to slow down - it didn't show a smoother loop, and also I noticed that the capture rate increased with my speed:



I over-plotted some data points with stars and in red showing the time period just after the entrance to the loop and well after the loop. Notice how the data points are sparse during the loop and increase in data rate during the exit from the loop and the pull up:

I wonder what causes the data capture rate change? Aerobatics causes a loss of signal to the Stratus 1?
General Foreflight Track Logger operation? I have to look at other parts of the data file where the speeds were slower (like take off and landing) to see what happens.

Saville said:

But if I had a simple display for, say, a Raspberry Pi FDR and a button

Click to expand...

Like this? https://www.adafruit.com/product/1115

DaleB said:

Like this? https://www.adafruit.com/product/1115

Click to expand...

Yes precisely what I had in mind.

Saville said:

I wonder what causes the data capture rate change? Aerobatics causes a loss of signal to the Stratus 1?
General Foreflight Track Logger operation? I have to look at other parts of the data file where the speeds were slower (like take off and landing) to see what happens.

Click to expand...

Is the data capture rate consistent in normal flight (i.e., when the Stratus maintains LoS to the satellites) or does it change with speed as well?

It's possible the GPS loses its connection to the satellites in a loop due to interference. It's possible the unit could be falling back to sensor data to interpolate at a lower rate.

I could see something like, with a 1Hz sample rate and the unit giving the gps 3 tries, you'd effectively have a 4Hz interp rate or a 1Hz GPS rate.

However, if the data changes sample rate with speed, then it could be distance sampling, which I would think be an unusual approach, or it could actually be changing the sample rate on speed.

You could plot sample rate vs speed vs altitude and look for a correlation.

Try plotting the points during the loop over horizontal distance. Are they really farther apart, or just appear spread out due to the vertical component?

rv7charlie said:

Try plotting the points during the loop over horizontal distance. Are they really farther apart, or just appear spread out due to the vertical component?

Click to expand...

Well I was looking at the data points after the loop - the dip and then the rise. My speed was increasing yet the data points are getting closer together in the dive and then further apart in the climb. One would think that if my speed was increasing and the acquisition rate was constant that the spacing would increase and not decrease. So I'm surmising that the acquisition rate was not constant.

But I confess to not having figured this out yet and further plotting of the data might lead to some insight.

Saville said:

Doesn't seem to be useful in showing a round loop.

Click to expand...

I wouldn't rule that out quite as quickly.

I used a Dynon to log my loops and in the first configuration they looked horrible.
Well maybe my loops do look horrible but the recordings looked horrible to a point that it defied physics. I important them into R so you could easily model the dynamics.... .

So I investigated and it turned out that the accuracy of my GPS signal drifted way off when inverted and took a while to come back when in normal flight. Note it's not that I lost tracking completely (maybe that is what happens to you as you mention recording slowing down) but my accuracy just got worse.

Looking at my setup (GPS antenna on dashboard of RV-8) it seems my fuselage was blocking the GPS signal in certain parts of the loop. So I put myself a little GPS data logger together I could move around the airplane easily to find a better spot by combining a serial data logger:

https://www.sparkfun.com/products/13712 15$

with a GPS module

https://www.sparkfun.com/search/results?term=GPS

they don't have the GPS I used any more but above has lots of choices which would all work. All you have to do is to connect RX to TX and vice versa connect both boards to power, write the config file on the memory card and put it in the logger and power it up.

Turns out when I moved it on my wingtip the loops were round. So my theory above seemed to be correct.

When I upgraded my GPS to be 2020 compliant I moved the Dynon puck inside of my wingtip and haven't had an issue since... .

So you might have to just move your GPS around a bit to get round loops... .

Oliver

spatsch said:

When I upgraded my GPS to be 2020 compliant I moved the Dynon puck inside of my wingtip and haven't had an issue since... .


Oliver

Click to expand...

Very helpful post.

So when you moved the Dynon puck to the wingtip, I take it that the extra wire run inside the wing does not affect antenna performance/signal?

Thanks!

If a GPS receiver antenna puck is moved out to the wingtip, does it's orientation matter? If it's mounted "upright" as if on a glare shield, I take it that being upside down doesn't affect reception?

Or should it be bolted onto the outboard rib so that it is 90 degrees rotated from where it would be on the glare shield?

Thanks!

Saville said:

If a GPS receiver antenna puck is moved out to the wingtip, does it's orientation matter?

Click to expand...

No. The GPS antennae on our planes don't care. Some of the military jam-resistant ones might aim lobes at individual satellites for jam resistance, but not ours. Similarly, VOR antennae don't care about orientation.

ADHRS, that's another story.

Ed

What about using a Pixhawk UAV autopilot for a flight data recorder? It has redundant IMU sensors, GPS, internal state estimator (AHRS) and configurable logging/telemetry.

Pixhawk hardware is about $100 for the older models.

I taught a Flight Test Engineering course last semester and mounted a Pixhawk on the tie down loop of a Cessna 210. The location wasnt great for GPS reception, but we got great airspeed data up to 170 kts.

The data is logged to an SD card and can be downloaded by removing the card or downloading through a USB cable or wireless radio. The default rate is 200Hz, which result in giant files for long flights. We have configured it for lower rates for certain tests, and to only log messages that are useful for analysis.