×
SparkFun will be closed on Tuesday, November 5th to support our team in being able to go out and vote! Orders placed after 2 pm MT Monday, November 4th will ship on Wednesday, November 6th. Thanks for your patience and understanding.
On this month's ATP, Pete opens with some light to moderate existentialism and discusses his adventures in glider piloting! He decided to build a data logger and some modified instruments to track more and better data from his flights than typical instruments do. Many acronyms are thrown around, and the word "log" loses all meaning.
ReplaceMeOpen
ReplaceMeClose
If you have any data logging advice, recommendations, questions, comments, jokes, concerns or delicious recipes, please leave them below, and we'll see you in September for the next According to Pete!
About the logger, what is wrong with an SD card receiving serial data? I have done this for a while with no big issues. I like that I can easily swap cards and can store a lot of data using the SD library. Someone help me if there is a serious flaw with this!
That's what I'd do. Using the SDFatLib to create CSV files is really easy. Wire it up to pins D10-13 on the Pro Mini and you're good to go as far as wiring. The only thing I see that's wrong is that it might not be hard enough to seem fancy?
As long as the Pro Mini is the 3.3V version then I think everything would be fine.
There's nothing wrong with it at all and I didn't mean to imply that there was. Quite the contrary, I think that's the way to go. But the question was what sort of functionality you might put into a logger if you built it from the ground up.
I have had issues in logging in that I simply add data to the end of a text file. Is there an elegant way to increment file name with each reset or name it from a time stamp? This could be useful functionality, but I don't know how to implement.
Adafruit has a sketch for their data logger board that increments the log file name for every reset. Check it out: http://learn.adafruit.com/adafruit-data-logger-shield/using-the-real-time-clock-3 (its under the setup section of code)
Thank you!!!
I was thinking, if you use two gps' and average out the two, would that increase accuracy? Also, what if you used a raspberry for the controller. Then you could dump all data onto a flash drive in whatever format you want. And you could use a lcd screen to view the data. Then again, it may be overcomplicating things.
If one is a fixed base station and both are the same type of receiver, it increases it tremendously. This is a proven method called differential GPS.
http://en.wikipedia.org/wiki/Differential_GPS
Multiple GPS units don't really add any additional information (unless they are far apart) -- so averaging the output does not increase accuracy. It is sort of like having two people recording the same measurement that was reported by a third person, if one of the two people recording really screws up, then maybe it would help, but assuming that both people are doing a decent job then one person is redundant.
But, the gps' won't be reporting the same reading. Gps is all about timing, precise timing. Since the clock in each gps receiver would wonder, each one will report a slightly different reading. Therefore, if you average out the readings, you would most likely be able to remove some of the noise generated by the varying clock speeds.
I really should have given more explanation, sorry (got interrupted).
The theoretical best improvement for two gps units that are completely uncorrelated is sqrt(2), or about 71% (10 foot error goes down to 7.1 foot error). However, if you look up the sources for error on GPS, most of it is stuff like atmospheric, satellite position error that are completely correlated, so what you really get is more like a 10 foot error improving to 9.5 foot error; hardly worth the effort.
Nice! I was not aware of that, but I guess I'm not surprised.
I did some googling, and you're right. according to this graph, http://www.montana.edu/gps/understd.html#Selective_Availability_(SA) , most of the error comes from the Ionosphere, wich is kindof duh on my part. :)
Yeah, it would be nice if that were true, but unfortunately its not.
I was doing a UAV project way back in college that involved GPS tracking as the primary guidance system. The problem back then was that accuracy wasn't as good as it is now, so I had the idea of using three GPS units to use to qualify against each other and increase the accuracy down to a finer pin point. I even enlisted the help of a mathematician to see if there would be any advantage to this and what the math would look like. At first blush it's possible you could increase accuracy by adding more GPS data inputs and simply averaging the resulting data. However, this is a full blown project in it's own right and may yield totally different results than something a simple average-of-the-data can yield. There's already an underlying and complicated set of filtering and bias algorithms that are going on in order for the device to spit out that GPS data. I never went down that rabbit trail though, so that's where my story ends. I just thought it was worth mentioning that it would be worth trying but starts to stray into yak shaving territory. I'll also note that I was trying to improve horizontal accuracy and that vertical accuracy was (is?) less accurate than the horizontal data.
It almost sounds like you would have to take multiple readings from multiple devices of each satellite, average that out, then send that through the triangulation agriotherium while keeping in mind that the antennas are in different locations. Which is probably not possible with off the shelf hardware. With that being said, would averaging the altitude readings still help. Just guessing here, but the problem with reading altitude is that the satellites are farther away horizontally then vertically. Therefore timing would have to be even more precise. So two gps could help with this, especially if you could make the gps' on an even plane.
Heck, why all the trouble...just download an app for this. There are some cool ones that look like a full panel display. Use a IOIO for any extra sensors. I know... that's not fun or expensive enough.
Well the thing about data logging is realizing that there is no such thing as analog or digital. It is all just numbers. Your log is just going to be a long list of numbers. Your logger won't care where they came from. The arduino will convert analog to digital, and receive digital values over i2c/spi. Then it just regurgitates the numbers, without caring what they mean, for the data loger to store. You can then have a program interperate the numbers when you retrieve them. Personally I would use excel, but vernier labvue could easily be used to re-display the data as a series of instruments.
Now that I think about it, I would probably use a propellor. Use one cog to gather and process the data, one to log it, and one to display the data as it is being logged.
Ah.... but that can't work. Gliders don't have propellors. (Sorry- but I couldn't resist the setup. :)
I'd use GPS and Barometric to cross reference and get a more accurate altitude. I'd use a IMU for vario as it's a small measurement and very finnicky, and GPS would have a fair bit of uncertainty, noise and lag unless you're diving or climbing at around 5 feet/second or more (as a guess). Also, if you've got an IMU then you can easily include an artificial horizon, which isn't a common instrument in a glider but would give you accurate bank angle readings. Having GPS is important for accurate time calculations, i.e. IAS and variometer's feet per second.
The crystal oscillator in the microcontroller arduino or otherwise has more than enough stability to serve as the time reference for determining rate of climb/decent, IAS (Indicated Air Speed) is not a timed parameter.
If you think about it most of our digital watches (for those of us that still wear them) are not equipped with GPS, and keep quite accurate time.
Personally, I'd look at using this design as a start: http://www.rctimer.com/product_927.html
It has a input for direct connection of a GPS sensor, has logging capability and software to display the data once it is collected. Modification of the software to give output indication for rate of climb/decent should not be too difficult. This board has a full IMU, 3 axis mag, 3 axis rate gyro, 3 axis linear accel, plus a baro sensor. Use a block of dense foam taped over the baro sensor to prevent local air flow turbulence from generating more noise than necessary. The circuit runs off 5V, is small and very light weight.
Alternatively, if a really sensitive varo is desired, then an air chamber with a "calibrated" leak can be used with a differential pressure sensor to get a higher signal to noise ratio from the pressure sensor, as the pressure in the air chamber will lag that which is sensed in the port exposed to the aircraft's current atmospheric pressure. The calibration of the system would entail setting up a known stable decent rate holding it until the output of the differential pressure sensor stabilized, and noting the value of pressure difference that was sensed. A correction coefficient would then translate that pressure value to a feet per minute decent rate.
http://hackaday.com/2013/08/05/centimeter-level-precision-gps-for-500/
I think that the biggest potential issue may be temperature fluctuations in the glider, which may cause fluctuations in battery output. Beyond that, in terms of a logger, the best option would probably be to roll your own. The OpenLog schematic is simple enough, so that it shouldn't be too hard to integrate the SD card directly into your design. That way, you're only dealing with one Arduino, instead of two. In terms of logging analog data, I'm confused as to why you couldn't simply log the 0-1024 integer as text in the log file. In terms of the graphic display, it may make more sense to opt for seven-segment displays with hand-written labels. Not only will they be easier to control from the Arduino, but they will also be easier to see, since there is a large difference in contrast between the numerical values, and the labels which describe them. With the graphic LCD, you'd need to actually read all the text on the screen, before understanding what it was saying.
A garmin e-trex legend c will provide the vario info...
I found on repeated (non scientific) tests with different ublox GPS the greater velocity the better the accuracy, and w/o saying the better the lock the more accurate the altitude. I feel with 6 to 8 satellites maintaining consistent lock, logging could start method would give fair results. Less... don't log altitude just ground speed. At a minimum give a warning for less than 7.
NEMA data strings ( http://aprs.gids.nl/nmea/ ) are easy to parse. Just pull the info out that is relevant to your logging and save them to an sd card as a .cvs for later graphs and charts of the flight in your favorite spreadsheet.
As a fellow pilot, here is my two cents worth.
The GPS constellation was not designed for high precision altitude determination. WAAS improved this a bit, but the results you will be able to attain will not get you to where you want to be in my opinion if you limit yourself to GPS data only.
The GPS satellites are in low earth orbits which means they move overhead and the number of satellites in view varies over time. This leads to times where the geometry of the solution for determining your altitude is particularly poor. Some of the constellation may be blocked by a mountain range you are close to as well. The result of this is that you cannot depend on GPS for altitude unless you factor this in, as IFR GPS certified GPS units do. They require several more GPS signals to be recieved to allow for multiple fixes to be calculated in a way that all agree to a certain accuracy before allowing the approach to be flown. Research RAIM for more info on this.
As a pilot, part of you wants to know your ground speed, as this tells you how long you will have to fly your given heading to get to your destination, but a bigger part of you wants to know your airspeed since this is what is making your plane stay airborne. I.E. if you were to want to fly a given airspeed you would need to know the winds aloft, your heading and apply that to the GPS derived ground speed. As the winds aloft vary with altitude and are poorly forecast this can be difficult.
Density altitude is dependent on the temperature, relative humidity, and local non-standard atmospheric pressure. Temperature and pressure being the most dominate factors. You don't need the density altitude to seek thermals, however. What you are interested in here is am I going up or going down, which a standard baro sensor will tell you.
Density altitude is most important when determining the length of runway that will be used to take off or land. It is also useful in determining the distance to climb to altitude, and the actual airspeed that you will be flying at as opposed to what is indicated on the aircraft instruments.
So if I read you correctly, you want to add instrumentation to a certificated glider you do not own. You can do this as long as what you put into it is totally portable, I.E. you do not connect to the aircraft electrical system, or to its pitot/static system. Use suction cups to affix it to the window, or velco straps to affix it to a surface so it does not move, or to your leg like a kneeboard. Just be sure it does not affect the control stick movement, or can come loose to hit you or get stuck in the way of a control if you encounter negative g's.
To get what you really want in my opinion you have two options.
Keep in mind that any baro sensor you place in the cockpit will have "installation" errors associated with it which will cause it to be sensitive to such things as opening or closing the cockpit vents. For vario purposes, as long as you leave the vents in the same position, it should not pose a problem. But if you open or close the vents, expect several hundred feet of difference in indicated altitude to be indicated.
What I would suggest is use a baro sensor to give you the change of altitude info you are really interested in as a glider pilot. This could even be given as a tone which varies in pitch as you find rising or descending air currents allowing you to keep your eyes outside the cockpit in the search of thermals.
Hope this helps.
Hey Pete, I'm an Aero student, I've used GPS (the EMA-406) on my aircrafts and gotta say it sucks when you want to use the altitude data, however you are using the BMP085 sensor, so beside pressure you can get exact altitude from it. To get climb rate, I used the time from GPS and Altitude from BMP and voila!
Pete, Why not use one of the inexpensive little flight controllers for Quad/Hex/Octo-copters. They are fairly accurate and provide all the sensors you are looking at. (GPS, Baro, magnetometer etc.) All in a very small package, driven by an Arduino compatible processor! (Think MultiWii Pro or Crius AIOP) Seems you could put all this together in a really small package.
Look at this baby!
http://www.ebay.com/itm/Flytec-6030-Vario-Paragliding-/300692743451?_trksid=p3284.m263&_trkparms=algo%3DSI%26its%3DI%26itu%3DUCI%252BRTU%252BUA%252BFICS%26otn%3D21%26pmod%3D310658618111%26ps%3D54
BMac
Yup, that was one of the examples I was looking at.
Not sure why you differentiate between analog/digital date they are both just numbers that can be either saved in a text or binary file.
BMac EE.
...and that's really what it all comes down to. But the question becomes, as far as products go, is there still a place for something like the Logomatic that will read an ADC and record the value? Or do you perform all of those tasks with a separate uC (maybe something with a 16-24 bit ADC instead of the standard 10 we all use) and then dump it to something like an OpenLog?
If I understand correctly I think the logomatic could still have uses like hanging it off of an analog circuit such as a simple thermistor without the need for adding stuff like a uC or firmware. I could see some uses for analog logging without needing to provide digital data. In your use though, no.. it's almost easier to go all digital.
Use the BMP for a variometer that's the way a standard VSI works. (Vertical Speed Indicator) Infact all of you info about Altitude can be derived from pressure, (Std Altimiter, pressure Alt/ Density Alt., set kohlsman for 29.9, then adjust from standard temperature 15C at sea level, (remember your pilot training)).
BMac, private pilot.
Pete, Fellow glider pilot here (mostly theoretical at this point though... work y'know), also named Pete, based out of California... I've had a pet project for longer than I can remember to design and build such an instrument, my challenge has been the ever improving state of sensors and compute power ... it changes before I get a chance to implement something that I'm happy with... so I'm permanently planning... anyhow.. from my long research the following stream of consciousness is issued...
Vario... there is a fair amount of info out there about using the BMP085 as an vario sensor (its just been end-of-lifed and replaced with the BMP180 (i think) by the way), but folks these days seem to be looking at the less 'noisy' and faster sample rate MS5611 (from Measurement Specialties), these as smaller (yes thats possible) , slightly higher resolution and can supply up to 100 readings second for that rolling average to bring the noise floor down even further. They are a little hard to source in the US (Sparkfun please look into supplying these .. pretty please) but its possible to buy them in Europe and have then delivered, they are more expensive but they appear to be worth the bump in price, I fried my first one trying to solder it so be careful. Regarding using accelerometers... most folks don't need them for 'simple' variometers, its only when you are getting into complex very well compensated varios that accelerometers are needed. They can be used to compensate for (amongst other things) sideways gusts that may influence the pressure readings, as well as differentiate real air mass induced climbs from climbs due to 'stick' lift`. This also brings up the need to have an airspeed sensor (i.e sense 'pitot' pressure in addition to 'static' pressure), summing these properly will give you a 'total energy' vario (i.e Potential energy from height + kinetic energy from speed), properly used can be used to cancel any stick lift (i.e. pull up with stick, reduces Kinetic energy, but increases Potential energy), differences in Total Energy should tell you if you are actually climbing or sinking. You can go beyond this and model the neutral airmass sink rate of the glider against its polar and you can get a 'netto' variometer that tells you slightly different info... is the airmass I'm in rising or sinking, you can further correct this info in circling turns with an accelerometer and even a compass (or GPS) for bank angle and turning G loads...its quite a complicated subject when you start to get into it...
Most of the hobby open source varios (or the simple Hang glider units that you can hang around your neck) go for just pressure differentials based on static pressure changes using most often a BMP085(or similar) but more recently a variant of the MS5611 is getting favoured (yes I'm English) , check the the Meas Spec sweb site out, there are low res and hi res ones, be careful to get the right one -BA03 if memory serves.
You can do a lot and get lots or useful info from the combination of Pitot (airspeed) measurements, Vario climb rates and GPS info... such as estimated wind direction (simple vector math of airspeed, compass heading and gps ground track), instantaneous glide angle or range to a defined altitude including info on glider polar curve, airspeed, wind speed, ground track ... hell you could even download the free DEM worldwide elevation data and build a terrain model that allows you to know when you will hit the mountain on your present track based on the above and a GPS posiiton and some extrapolation... the possibilities are endless. Its a fascinating project that you will never be finished... if you are anything like me.
Logging... phew... there is a standard logging format that is used by most commercial electronic glider instruments the .IGC format (its an open standard), available and well defined from the various web sites such as http://www.fai.org/gnss-recording-devices/igc-approved-flight-recorders or http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/ . This is designed to allow for height and position (plus a motor sensor, noise or vibration) logging suitable for various levels for badge claims... simple badges, competition and world or national records. The standard builds in some sort of encryption and 'anti-tamper' stuff, thats probably a bunch of hassle, but if you can get an .IGC interpreter working you can do some wonderful 'after the fact' rendering of your flights on many web based tools that are out there that use resources like Google maps or Google Earth.. check this out... http://www.doarama.com/activities/1408 not me just a local pilot.
Good luck.. I'm very interested in your progress with this...
Peter
Wow! Thanks for all of that. We'll check on the availability of the MS5611, too. And maybe the next video will be a status update of this project. There seems to be a fair amount of interest.
I have been thinking along these lines for a while. I think the problem with GPS is accuracy at least compared with the "steam" values in a 2-33. 100 ft/minute climb is only 1.13 mph. GPS is generally not accurate enough to give this kind of accuracy in flight. You can go back and do the averages, but it won't help you thermal reliably. The problem is compounded because the total energy you get from the climb is the kinetic + potential. You can gain some potential by giving up kinetic, so you have to make sure you are actually gaining energy in the thermal not just altitude. (Of course, gliders have a TE probe to do just this.)
Having said this, there are some flight systems that use GPS to look at this, albeit crudely. I often flight with a simple Garmin hiking unit which has a built in barometer. It is nice for very simple flight recording, but certainly not for records or badges.
The simple solution would be to use a $33 iphone/nexus app with a $99 GPS bluetooth unit. Yes- there is an app for that. I don't think you are going to do better or cheaper than the commercial solutions.
I think it could be fun to add a camera, 3 axis IMU, and GPS for a full flight log. It might help you do better on landings if you can review the flight. The commercial stuff doesn't do that, and it would make awesome home movies later if you can sync the log with the video. Have fun!
Why not use a combination of old technology and new for the VSI. You have a barometric pressure sensor, so add another barometric pressure sensor inside a tuna can with a very small hole in it. Vertical speed will be a function of the difference in the pressure readings. Empty the tuna can, install the sensor, epoxy the wire hole, solder or epoxy the lid back on, and drill as small a hole as you can for starters. As you know, mechanical VSI gauges are just an aneroid barometer with a small hole in the bellows and they work quite well.
Yep. That's a good idea. Maybe I'll play with that next.
With GPS accuracy and speed are goals at odds with each other. I would say you could use the GPS for basic vario functions, however augment it with the pressure altitude you are also collecting. You should be able to read it far quicker and more accurately. I am thinking something like using the GPS altitude to "calibrate" or relate the pressure altitude to GPS altitude. As a addon if you went to a more powerful processor you could find and download a DEM (digital elevation model) and get your ground altitude over the actual ground you are currently over as well as referenced to your airport. Sounds like a fun project.
I agree, use both GPS and pressure altitude and fuse the results with a simple complementary filter. You should be able to get density altitude with the addition of a temp sensor and a humidity sensor.
Pete!
I did this exact same project last year. I've been flying gliders for about 17 years, and actually spent the afternoon today chasing thermals.
My project was using an ArduIMU that I had lying around along with a GPS, and an Openlog to log to MicroSD. Actually the whole reason I made the logger was I had the ArduIMU in my parts box and wasn't using it for UAV experimenting anymore. The best part was that the ArduIMU not only already had all of the GPS protocols written, it also outputted yaw pitch and roll data. I wasn't recording any barometric information. Getting reasonable vario data from the GPS is totally do-able. If I was going to add some analog data, personally I would get the Arduino to read the analog and dump it all via serial to the OpenLog.
If I recall correctly my logger display also gave me some other stuff on the screen in flight. Altitude, Groundspeed, rate of climb. Distance from take-off point, and gliding range before I hit the ground (based on take-off elevation). Instantaneous L-over-D. Current Track and Rate of Turn Flight Duration
I mounted mine in a project box, and then used a Go-Pro camera Suction Cup Mount to suction cup it to the side of the canopy. At least at my club, they have no issues with you suction cupping equipment into the cockpit. Everyone up here flies with a PDA of some sort to log their flight.
This project kinda fizzled out for me after having some pretty good success with it. What finally killed it for me was when I got a Nexus 7. There is a free android App called "XCSoar" which pretty much does all of this and more and includes a moving map of where you are, and also logs your flight into the gliding standard logging format (lookup "IGC file" online). I was flying with my Nexus 7 today. My experience is that the GPS altitude in XCSoar is within 50-100ft of what my altimeter is saying.
I'll fire you an email with my Arduino code tomorrow if you're interested. It is pretty much a heavily hacked version of the DIYDrones ArduIMU code with all the gliding stuff piggybacked on it.
Here's me, before I got the suction cup mount for the Nexus 7: http://www.youtube.com/watch?v=od3Tn6iLnNQ&feature=share&list=UUTGf8b9CGSvmqN64jP-Y01A
Have fun!
Tom
ASW-24! I hope I get to fly one of those one day. Code? Nah. Not that I don't think you've done well, but, you know. I gotta do it myself. It's not so much the end result as it is the journey.
You'll get there! I also learned on 2-33s. In Canada the Air Cadets use them for training... which is how I first got my license. By the time I finished with cadets, I think I had over 300 flights in them :)
The only real difference between flying a 2-33 and something like the ASW-24 is that you can still hear yourself think when you accelerate to 98knots in the ASW-24. :)
You can pretty easily write a complimentary filter that will pit the strengths and weaknesses of the baro and the GPS against one another. The GPS can be considered drift free over a very long time scale and noisy in the short term. The baro has qualities complimentary to that. You would take the time rate change of this filtered, or combined, altitude as the source for your vario. Here's a a pro tip: get this thing in the air as soon as you can logging real, raw data. Then, back in the comfort of your shop, which looks eerily like mine, you post process that raw data and come up with all you "magic numbers" for the filter. The gains, the high/low pass time constants, etc.
I'll also add that GPS is velocity should also be logged. You can get the 3D velocity vector out of that chip in either ECEF or NED. GPS velocity should go into your filter also. It would be foolish not to use sensor fusion in this situation. Also those helicals are kind of meh in terms of performance. You will do better with a patch in this instance, but for what you are using GPS for, I might take that back, you should be OK either way. GPS velocity is generally more accurate than position because of the way it is measured. Vertical velocity suffers from the same constellation geometry issues that vertical position does, but it is not as noisy because of the different measurement process.
I am neither prepared nor talented enough to comment on the component or programming aspects of your build (cool project by the way), but have you considered a simple elastic band with hook-and-loop closure for mounting the final build package as a wearable (wristband, armband, or leg-band)? Could make for a pretty cool flight-"watch" or H.U.D. on your forearm and the display should always be easy to read instead of grabbing an holding a lanyard where you could read it.
As it was said before, GPS vertical accuracy is by system design about 1.5 times worse than horizontal. Surely WAAS in the US and EGNOS in EU can mitigate many of the common errors of GPS (such as satellite clock, broadcast orbit errors and more importantly atmospheric errors). The receiver you are using is a good one, but I have very little opinion for small quad helix antennas (won't mention the manufacturer here). I would suggest using a good external patch antenna which will give you about 3 to 5dB more gain in normal conditions (when you are airborne). GPS can also be used in differential mode to achieve centimetre accuracy and surely I would consider that if you have a wireless data link at hand onboard your glider. Finally, please check the uBlox protocol manual on how to set the correct Kalman filtering for your application (I think it's message UBX-CFG-NAV5). In summary, yes I think you can succeed with GPS and a decent antenna.
Coming to logging.. with GPS you have a PPS (pulse per second) which is an analog pulse synchronised to GPS time to a few tens of nanoseconds. Normally you get the PPS and shortly after that (microseconds) a bunch of NMEA sentences relevant to the GPS second that just happened. uBlox has clear application notes to describe the relationship between this analog PPS signal and UART data. If you would be integrating GPS with accelerometers and gyros then you would have to refer everything to a common time frame in order to be able to integrate sensor outputs post mission. Usually GPS time is a good choice and PPS can be used to trigger reads on the SPI/I2C bus of digital sensors. Moreover uBlox "T" series have an external digital input that will time-tag (with the local receiver time, roughly aligned with GPS time) an external event. So would you want to very precisely reference in time analog events I would strongly suggest to use that. One example could be photogrammetry, where pictures need to be precisely time and position tagged. If the only sensor you want to log is the BMP085 then I think that very coarse synchronisation will suffice (e.g. the GPS UART FIFO buffer is empty -> dump a baro reading on the file). I normally use STM32 and Fatfs which gives me a lot of flexibility, but I would say that the openlog is perfectly capable of handling two sensors too. Hope this helps?
I haven't seen the hat in far too many episodes...
Do I have to start wearing a hat more? Oh, if I must...
yes you do
Just a few random neuron firings:
Your storage medium is digital so think digital from the get go. Use an ADC up front as needed...
Vario, huh? You sure picked the hard one! Mu guess is that a running average would give the most readable result, however, there are issues in general w/ GPS. Note that vertical error in a GPS readout is about 1.5 times greater than horizontal error. Your MSL may be off since GPS measures vertical distance from the geodetic sphere ( a computational model of the earth ). Standing on the beach, looking at the ocean while your GPS swears you are -15 meters is always fun.
I would guess that you might get a decent ( though coarse ) vario w/ GPS. Especially since you are looking at the moment to moment alt variance. Whatever method you use ( radar alt, acceleration, air pressure, GPS ) you will likely have a moderate to heavy calculation to get a great result.
It will be fun to hear the progress/result!
You can use the Openlog logger. It is not just a serial text logger. I've created a Flight Data Recorder for my Quadcopter and can capture a surprising amount of data, even 10ms sample loops if you are careful.
Thanks to some work Nathan did a year or so back, Openlog can be used in "binary" raw mode, in other words, it will record raw 8-bit bites into the log file at 115Kbps. I wrote a encoder library on the quadcopter's Arduino Mega that provides a frame format for the data sent serially to the OpenLog stored in the file. There is a unique start sequence (2bites) followed by a record type byte, a compressed timestamp, the 8-bit raw data, and finally a one byte checksum. The PC side decoder figures out where packets start and finish in the raw file and decodes each value in each record. There can be a glitch from time to time so the checksum byte is important. Each record can be a unique list of values, for example, lat, long, alt, pressure, etc. Where possible I transmit binary equivalents to save time, for example, the NEMA text values for lat or long are converted to a binary form only taking 4 bytes each, and then reconverted to the original text string on the PC. Analog integer samples can be transmitted directly as can floating point. The PC decoder handles big/little endian conversion, floating point architecture mapping, etc and produces a text CSV file of the data that can be process in excel or whatever. In this way, I record mixtures of analog and digital sensor readings, all time stamped, using the Openlog. Works great.
As an aside, I was under the impression that a lot of the cost of commercial loggers is for the price of certification for use in competition flying.
Are you planning to have the vario also have an audio output, or will this be purely a logger?
An interesting addition would be to log air temperature around a thermal. Comparing climb rate to temperature as well as barometric pressure might be an interesting thing to do. The aircraft inspector at my club built a vario using temperature sensors in each wingtip to try to tell him which way to turn. This was about 30 years ago, all analog. On a particularly hot day with high climb rates the audio output would go ultrasonic.
I'm sure certification's got everything to do with it. Audio output? Nah, not for now.
The rolling averaging filter for the GPS height is immediately what I thought of. The question I would have would be accuracy of GPS itself, http://www.gps.gov/systems/gps/performance/accuracy/ . The varience may be too great if you're trying to see if you are on the edge of a thermal, but maybe seat of the pants might be a better indicator anyway for that. Do the commercial ones use WAAS ? http://www.gps.gov/systems/augmentations/ . My other concern is based on getting and keeping a lock. Certainly driving seems to have it's dead spots, the signal is pretty weak and can't penetrate buildings, or seems like heavy trees etc. Check out the commercial ones and if they require an external antenna.
For logging, ditch an arduino, and use a RPi, or some other small linux based system and just write to a file. That way you have plenty of horsepower for any filtering, and ability to dump both raw and processed data if you want to.
Oh, you Pi guys! "I gotta blink an LED! Well, a Pi is your best bet, son!" I keed, I keed...
Seriously, though, a Pi might ultimately be the best choice. But, it's likely to be way more processing power than I need, and it'll surely take more current to drive it than a pro mini. When I do a project, I tend to start with the simplest approach and scale up as necessary, not the other way around.
I've had a RPi since the beginning of the year, still haven't fired it up ! It is cheap horsepower though. We use them at work as video generators for 1080P. The company owner complained that the boxes cost almost as much as the RPi's !
As a software guy I look it more as, it can interface to what you need on the hardware side, and you have enough horsepower to do lots of calculations on the raw data for presentation. Power consumption, well with the energy density of LiPo's, does it really matter ? It's a couple of ounces of battery, no big deal.
I just get kinda bored though of watching all the SF video's where it's "arduino this, arduino that". Be nice to see you guys use something else for once !
OK, fair point and I don't blame you at all for saying that. And the truth is that we'd like to be doing more examples with more platforms, and you'll likely be seeing more of that in the near future. But for this particular project, I'm not convinced (yet) that a pi the right choice. It would be a multi-hour learning curve to get up to speed for me. I'd really love to invest that time... but time is the rarest commodity. And if I can get the job done in way less time with an 8-bit uC that comes with a free IDE... well, you get what I'm saying. It might seem like a lame excuse (seems lame to me as I type it), but I've got so many unfinished projects that I've got to be careful about what I stick my foot in for fear of making yet another unfinished project.
And yet, even now there's a little voice in me going "yes! go get a pi and jump in! screw the time! it'll be fun!" Crap. Guess I know what I'm doing tonight. I hate you, andy4us.
...now I see in a comment farther down where I said "It's not so much the end result as it is the journey." Hypocrisy stings, man. Little burny, little itchy...