Basejumper.com - archive

L/D Vario is an Android+Wear, iPhone, and Windows app for wingsuiters and trackers to help maximize your flying performance. It is a much simplified version of L/D Magic for iOS.



The app is based on "Accelerometer-Vane Principle" and uses the accelerometer in your device to accurately measure Lift-to-Drag ratio (L/D) and provides instant visual and audio feedback. To use it, your device needs to be mounted on a vane that is positioned in undisturbed air stream (away from the body at least 2-3 feet) and is precisely aligned with the relative wind at all times, so that its Y-axis (from screen bottom to top) is parallel to the relative wind, and X-axis (left-right) is parallel to the ground. Similar to what you can see in these videos: vimeo.com/108428363 and vimeo.com/108326309. Now with Android Wear watches, the device can be made quite small&light and less obtrusive compared to a phone on a vane.



Unlike GPS that measures ground glide ratio (which is distorted by wind and dynamic maneuvers such as dives and plane outs), L/D Vario measures true, instant L/D — your aerodynamic finesse — independent of wind and dynamic distortions, so you can maximize your L/D much faster and more reliably. It is also a great tool for wingsuit manufacturers to develop even higher performing suits and do A/B mod tests directly in flight! It can instantly answer questions that used to be a topic of debates for years - palms up or down, legs together or wide for tracking? elbows normal or forward, heels or toes out for wingsuits? How much does hiding the chest strap really increase L/D? Etc. You can find the ideal body position for maximum L/D in much fewer jumps.

Enjoy --->



Android+Wear
iPhone
Windows

does it come with the flying fin?

You have to make your own.

Lowered the minimum Android version to 4.4 (API 19) for the mobile app and to 4.4W.2 (API 20) for the wearable app.

https://play.google.com/...s?id=com.PFM.LDVario

L/D Vario now supports 6,666 different devices running Android 4.1 (Jelly Bean) and higher. Almost 90% of total number of devices in use are now compatible. (Please let me know of any issues with layout or functionality on 4.1-4.4 devices, as it's impossible to test everything.)

So, now you can use some old Android device you had collecting dust in a drawer, as your dedicated L/D variometer.

Remember the old discussions circa 2005-2009 (before facebook ate people's brains) we had in the forums on how to measure L/D? How to compensate for the wind? How to achieve best L/D? Remember claims of 7.0+? People are still looking at the GPS graphs and can't figure out what they're looking at, as glide ratio in general is not equal to L/D. Glide ratio of modern wingsuits can be anything - from 0 to positive infinity and through singularity to negative infinity to some negative number (when gaining altitude during flare). L/D is a true measure of aerodynamic finesse of a flying craft and has a hard ceiling. Nobody in the world has L/D higher than about 3.0-3.1 in wingsuit. The glide ratios of 5.0 you can see in competitions are simply results of insane upper winds, superslow fall rates, and milking of the initial high speed gained during a steep dive.

Now we can stop fooling ourselves. The problem is FUCKING SOLVED.

Fly smart!

https://play.google.com/...s?id=com.PFM.LDVario

- added speech generator
- eliminated audio clicks in tone generator

- added support for GPS altitude if barometer is not present
- improved timeliness of speech generation: if by the time the first digit is finished being pronounced the second digit changes, the "fresh" second digit will be pronounced instead of the old one
- tone is now playing in the left stereo channel, speech in the right

I thought I'd share some pitfalls that I encountered during R&D so other people won't repeat them.

With the iPhone vane mount I jumped before (https://vimeo.com/132279770) there was one significant issue: vibrations. Vibrations introduce a lot of noise to accelerometer readings. These vibrations come from body movements (slight pitch and roll movements we don't even notice result in noticeable accelerations at the end of a long pole), breathing (mounting platform moving), and invisible vibrations from turbulence created by the vane itself.

With the smartwatch mount I've been working on, I wanted not only to make the whole system lighter and creating less parasite drag, but also solve the vibration problem. So I thought, instead of a rigid stick (that blue pole is a telescopic hiking pole), something flexible - like a fishing rod - would damp the vibrations well. Also, suspending the vane on a thin rope instead of a rigid axis should also help.

But as it turned out in testing, both ideas were wrong: rope only increased the wobbling, so I returned to rigid suspension axis; and the fishing rod - compared to rigid pole - also only increased the vibrations, as it happily dances in the wind. This dancing makes L/D measurements unusable.

So, going back to rigid pole and rigid axis... Hope this helps folks building their own vanes. Any suggestions are welcome. Perhaps someone with an engineering experience of damping vibrations can chime in?

Video:

https://www.youtube.com/watch?v=dPZ02IGk78Y

(For some strange reason, all 3 jumps with the fishing rod resulted in linetwists - same direction and amount. Go figure.)

Your need to to add a damping / spring element between your accelerometer and your mount. In principle, you ought to be able to achieve low transmissibility for any type of mount.

There are lots of standard text on vibration isolation, and this is reasonable primer for free:
http://freestuffy.com/...2002%5D/70811_30.pdf

I would suggest something like a thin layer of neoprene between your phone and mount, held on by elastic bands or some other non-rigid connection.

Thank you, dgw, I will try that. I'll start with rigid mount all around and go from there. Perhaps, the first step is to isolate small, turbulence-induced vibrations of the craddle/vane itself by having a rigid axis that smoothly rotates on ball bearings but those bearings' outer shells rest on foam or rubber supports. It will be much harder to damp the body movements and breathing transmitted to the pole as they are much larger in amplitude.

In L/D Magic, I partially fought the vibrations in software: the left-right accelerations of the iPhone are included (Pythagorean-ly) in the component of apparent gravity perpendicular to the screen; the vibrations are smoothed out by low-pass filter prior to feeding to Kalman Filter engine:



and, of course, Kalman Filter also does its magic and as result, the filtered L/D is much much smoother than just taking the apparent gravity perpendicular to screen and dividing it by the apparent gravity parallel to screen in the direction of relative wind:



(here dark green color in the top graph is unfiltered L/D, bright green is filtered)

My comments were on the basis of your thoughts that the vibrations that you were experiencing were from the wingsuit pilot moving the mount pole by small, un-noticeable movements.

Having looked at your data, that seems to me to be either unlikely or not the main problem. Your noise appears to be much higher frequency than the any movement of the pilot could achieve. I think that your main noise issue is to do with the mount pole being long and slender. You will have vortices being shed around it, and the plate that your recorder is on will also have vortex shedding.

It is a good few years since I have had to think about this type of problem. But, if you did a test flight, in as steady a state as is possible (adopting a single position for, say, 20 seconds), the data could be run through a fast Fourier transform, and you will be able to see your 'problem' noise frequency or frequencies. This should give a good handle on where the problem lies. The FFT changes the magnitude / time history of your data into a frequency / amplitude history, and it is very useful in any type of noise / vibration problem. You can do a FFT on your data in MS Excel.

I suspect that you will have one or two main frequencies of noise, and they will probably relate to the properties of the mount (length and stiffness). A few tests with variations in, say, length or rigidity, would go a long way to narrowing the issue. My original suggestion will still address the issue (if it is an issue) of pilot-induced vibration.

Also, your current approach of signal processing is meritorious. The data that you want is all very low frequency (I think). The noise is very likely to be high frequency. You will never have a perfect mount. If I was you, I would decide what frequency of data was of practical relevance (1 Hz?), and go from there. If I still had noise or measurement difficulties at the frequency of interest, then maybe more effort is required.

Yes, the raw data graph above (Gx, Gy, Gz - 3-axis accelerometer readings at 100Hz, time is horizontal scale with gray lines every 1s) clearly shows fast vibrations (~5-6Hz) and slower at about 1Hz. I think the former is from the vane-induced turbulence, and the latter from the pole-induced turbulence. The low-pass filter smoothes them reasonably well, although introduces some delay: ~0.5-1s. I'll see what kind of vibrations I get with the new mount, and go from there.

that's neat. very good work!

if you have it written out somewhere and it isn't too much work, i'd love to see more details (formulas, not code) about that. the old dz.com post was interesting.

armink, here are some materials you may find interesting. I'll be happy to answer any questions!

(the last 4 files are info sheets about Kalman Filter models used in L/D Magic - two for vane mount, and two for body mount with external GPS for iPhone)

very interesting. have you tried imrpoving your result by additionally estimating the windspeed and fusing the models?

Not yet, but thinking about making a Bluetooth Pitot tube and a Kalman Filter model for it in L/D Magic. I've been playing around with SensorTags... (http://processors.wiki.ti.com/...SensorTag_User_Guide)

With a rigid pole and more aggressive smoothing, the stability of the output L/D values is much better compared to a flexible pole.

https://www.youtube.com/watch?v=9Oj8SXvs4GU
https://www.youtube.com/watch?v=u_iPSSV-5qY


On a side note - previously, it was not clear to me if the ratio of perpendicular and parallel components of the apparent gravity is equal to L/D even during turns, not only during straight flight. I now have a mathematical proof of this using Wingsuit Equations for 3D flight with coordinated turns. The calculations are too long and tedious to publish here, you'll have to just trust me on this. It's nothing short of magic when pages and pages of formulas with dozens of terms all collapse into a simple, beautiful result:

g1/g2 = L/D

As long as your flight is coordinated (https://en.wikipedia.org/wiki/Coordinated_flight), L/D Vario will show your current L/D at all times.

- made app load much faster
- removed the inclusion of x-component of apparent gravity in z-component upon more research
- reduced the aggressiveness of the low-pass filter and limited max L/D to 10 to improve responsiveness

L/D Vario is now available on Windows devices! Windows 10 is required as earlier versions do not support pressure sensor.

https://www.microsoft.com/...d-vario/9nblggh22jwg

L/D Vario is now available on Apple devices!

Choose your weapon:

Version 2.0



L/D Vario is now a complete flight instrument, measuring the most important aerodynamic parameters of the gliding flight: lift-to-drag ratio, air glide ratio, current horizontal and vertical airspeeds, and sustained horizontal and vertical speeds normalized to sea level (a.k.a. the polar curve). Advanced multiple-layer algorithms are used to calculate smooth descent rate and vertical acceleration from noisy altitude data. Wingsuit Equations are solved in real time using accelerometer and barometer (or GPS) data to measure flight parameters and provide instant visual and audio feedback. Use of devices with high-speed barometric sensors (60Hz or faster) is highly recommended for the feedback lag not to exceed 0.2s.

Android+Wear
iPhone
Windows

A trivial, yet easy to overlook bug in my custom localization engine caused the app crash on launch if system language was not one of the supported languages (English and Russian). Sorry, Frenchies, that you could not flyaii yer bodeé with my app!

The updates are submitted to all 3 stores, however, while Android is already live, iPhone takes ~7+ days for approval (and submitting updates while the previous version is waiting for review resets the clock! what a shame, Apple), Windows ~2+ days. C'est la vie!


UPDATE: all 3 stores have the latest and greatest now.

Android+Wear
iPhone
Windows

Some news from the development front (may be of general interest for other devs):

#1. Impossible is possible: every one of the 4 apps on each platform consists of just one line of code (C#):

Shared.MainEngine.Instance.Initialize(some platform parameters).Start();

That is fucking it!

All other lines of code - thousands of them - in main engine are absolutely platform-agnostic. Of course, the engine links to some libraries, some of them cross-platform (various math, physics, Wingsuit Equations, etc.), some are abstractions from the platform specifics (UI, sensors, sound, localization), but all these libraries are generic and can be used in other apps, so the relative effort of writing them approaches zero in the long run.

#2. Localization (text, images, sounds) is also fully abstracted from platform specifics (all these horrible platform-specific ways of localization - *.xml, *.resx, *.strings - make me want to puke as you have to manually copy each string between platforms and escape the special characters), now all resources are in one folder which is simply copied between the 4 projects without any changes. Lovely!

#3. The visual designs in each of the 4 projects consist of just one container in the window. That is fucking it! Custom crossplatform layout engine fills this container with all UI elements in such a way that you can't see screen differences between platforms by naked eye, only using bitmap difference in photoshop can reveal small differences caused by slightly different rendering of the same font by platforms - here's the diff between iPhone 5 and Note 4:



Sweet!

These are some invisible things behind the seemingly simple app with some numbers on screen. It's magic, pure fucking magic!

Now I need me some well earned beers!