0
yuri_base

Smart Altimeter

Recommended Posts

Meanee

***
"Any interest in porting this to Tizen?" - absolutely no. I've had a Samsung Gear S smartwatch running Tizen and tried to develop for it. Tizen is total garbage, full of security holes and poor programming (search the web) and where most "apps" are actually web browser pages running Javascript. Yikes!



Unfortunately they are only game in town if you want a smartwatch with good design, battery that lasts 4 days, and ergonomic menus. :(

Yes, they're are highly regarded for these qualities. But from the developer's perspective, Tizen is the worst nightmare. Tizen Studio (their development environment) is a complete mess. It took me hours just to figure out how to deploy the app to device. So counterintuitive and poorly done. And these development hurdles are reflected in the scarcity of Tizen apps, compared to Android.

mxk

At my previous job, I spent over a year developing a data collection platform for Tizen, which would stream sensor data to an Android phone. Everything you said is pretty much spot on.

To be fair, Gear S2 and S3 added native app support, so you can implement your stuff in C or C++, which I had to do to get access to the more advanced power and sensor APIs. It was still a nightmare though, especially with each firmware update breaking different APIs. So glad that work is behind me now.



Yes, C++ development was also available when I was playing with Gear S circa 5 years ago. Still, majority of developers would shy away from way more difficult C++ and opt for HTML/Javascript. I don't know if Tizen Studio is much improved now, but the 1.0 was an absolute mess. Trying to do simple things was like reading vertical text in Chinese while making Bruce Lee karate moves. One good thing came out of it for me, though - when I finally pulled all the hair off my head, I actually liked the result.
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
I got to try out my Nixon Mission on some jumps. I actually removed the side door all together to maximize airflow and accuracy. What I found was in the airplane below 10k, the altimeter read about 30' lower than my Viso. Once above 10k, the lag increased to 40 - 50' for whatever reason. In freefall, on the first jump there was a difference of about 300' between the Viso and watch. On the second jump, the difference was upwards of 500'. Under canopy, the watch read about 70 - 110' higher than the Viso.

Playing around with it in the elevator going up and down, I learned that the software seems to lag behind the actions of the watch. The elevator would stop moving and the door would be opening, but the altimeter elevation was still leveling out.That is also what I found using it for skydiving. On the way up, the watch read low. On the way down, it read high.

Overall I'd say it is not suitable for skydiving. It was too inaccurate in freefall and even under canopy it was less accurate than I could reasonably expect from any digital altimeter. I would recommend buying only altimeters designed for skydiving.

Share this post


Link to post
Share on other sites
"The elevator would stop moving and the door would be opening, but the altimeter elevation was still leveling out."

Sounds much like simple averaging of the last few seconds of data to smooth out spikes and other random fluctuations in the data.

Same applies for the 300-500 ft difference in freefall and 70-100 ft under canopy -- either way, subtracting a 30 ft static difference, looks roughly like a few seconds of freefall or canopy descent.

The watch could use some other method than simple averaging, but in any case it seems like it uses a fairly wide time spread of data, and doesn't try to predict the current conditions based on some average using the past.

At least the 30 ft difference over 10k (or even 2500 ft) ft isn't much in relative terms -- easy enough for any altis to differ that much.

Of course we're using just a couple jumps as data but you weren't presenting the data as anything more than that.

Share this post


Link to post
Share on other sites
pchapman

"The elevator would stop moving and the door would be opening, but the altimeter elevation was still leveling out."

Sounds much like simple averaging of the last few seconds of data to smooth out spikes and other random fluctuations in the data.

Same applies for the 300-500 ft difference in freefall and 70-100 ft under canopy -- either way, subtracting a 30 ft static difference, looks roughly like a few seconds of freefall or canopy descent.

The watch could use some other method than simple averaging, but in any case it seems like it uses a fairly wide time spread of data, and doesn't try to predict the current conditions based on some average using the past.

At least the 30 ft difference over 10k (or even 2500 ft) ft isn't much in relative terms -- easy enough for any altis to differ that much.

Of course we're using just a couple jumps as data but you weren't presenting the data as anything more than that.



Yes, I agree with you. The software is averaging some samples. However, all digital altimeters do that. The Viso uses some form of data processing before arriving at the numbers you see on the screen. I say 'some form' because L&B keeps this a secret and wont tell us exactly how it does that.

Regardless, what I can say is that the Visos seem very predictable and repeatable. I can be in freefall with four other people, we can put our hands in the center and all of the Visos more or less read the same, limited by my ability to look at multiple screens at the same time. However, with the watch that is not the case. The amount that it differs by is different from the few jumps I did, both under canopy and in freefall, and there is a relatively large difference between the Viso and watch in freefall.

Of course we could argue that maybe the Viso is off and the watch is accurate. Possible. But I have jumped with other digital altimeters and found they read similar to what my Viso said. I have also jumped with another watch (forgot the brand at the moment) which has it's own altimeter software and it's closer to what my Viso says.

So what I think is happening is the barometer is probably accurate, but the software is lagging behind and what the screen is showing occurred in the past, not in the present which of course wont work.

Share this post


Link to post
Share on other sites
Westerly

I got to try out my Nixon Mission on some jumps. I actually removed the side door all together to maximize airflow and accuracy. What I found was in the airplane below 10k, the altimeter read about 30' lower than my Viso. Once above 10k, the lag increased to 40 - 50' for whatever reason. In freefall, on the first jump there was a difference of about 300' between the Viso and watch. On the second jump, the difference was upwards of 500'. Under canopy, the watch read about 70 - 110' higher than the Viso.

Playing around with it in the elevator going up and down, I learned that the software seems to lag behind the actions of the watch. The elevator would stop moving and the door would be opening, but the altimeter elevation was still leveling out.That is also what I found using it for skydiving. On the way up, the watch read low. On the way down, it read high.

Overall I'd say it is not suitable for skydiving. It was too inaccurate in freefall and even under canopy it was less accurate than I could reasonably expect from any digital altimeter. I would recommend buying only altimeters designed for skydiving.



Thank you for your tests. I haven't touched the app in 3 years after launching just a basic stub version of it. For some reason, I missed this bug with the lag and all this time thought that the lag was only 12 samples; I guess with the type of jumping I do (only wingsuit) it was not easily noticeable. Indeed, there's a bug in the code that ensures that for slow devices (like iphone with its useless 1Hz barometer) the lag does not exceed 2 seconds (12 samples would be 12 seconds!), it was actually setting it to 2 seconds for all devices... Argh! Super-embarassing.

Let me explain what my app does under the hood. It takes raw pressure measurements (and on Android/Wear, it's truly raw) and then passes them through 3 consecutive smoothing filters: 1) Butterworth Low Pass Filter, 2) "vanilla" Low Pass Filter, and 3) Savitsky-Golay smoothing/differentiating filter that not only additionally smoothes altitude, but calculates smoothed vertical speed from it (if one were to calculate speed just by subtracting consecutive altitudes and dividing by time interval, the result will be extremely noisy). Additionally, speed is smoothed by similar 3-layer sandwich. It's the Savitsky-Golay that introduces a lag of 12 samples (which is ok for the Mission, since it outputs massive 167 samples per second). What I missed was the bug in #2, the plain LPF, where by mistake the delay was always set to 2 seconds.

It is fixed now in the new 1.0.4 version for Android/Wear. It is also updated for Wear 2.0, so the app can be downloaded from the watch's app store (and thus should be available even if the watch is paired to an iphone).

Release notes:

- fixed unintended 2s lag due to excessive smoothing; the lag on devices with fast barometers should not exceed 0.1s now or 12 samples, whichever is greater
- increased frame rate of screen updates to 15fps (up from 6fps)
- changed number formatting of altitude to resemble skydiving altimeters: altitude is rounded to 10 units if below 1000 units; displayed in thousands with 2 decimals if above 1000 units
- removed Butterworth and Savitzky-Golay smoothing filters as altitude smoothing layers (with only Low Pass filter remaining) for now to resolve issues with sudden altitude spikes
- reduced jitter in vertical speed by limiting it to values above 1 unit and by removing Butterworth and Savitzky-Golay filters (with only Savitzky-Golay filter for altitude used as a smoothing differentiator to obtain speed, and Low Pass filter for speed remaining)
- added raw altitude AMSL output, for observing sensor sensitivity and accuracy
- fixed a bug where the measured barometer sample rate would multiply if the app is placed in background and entered again

I would be grateful for any feedback on this new version, since the next time I skydive will be probably in a few weeks.

Westerly


The software is averaging some samples. However, all digital altimeters do that. The Viso uses some form of data processing before arriving at the numbers you see on the screen. I say 'some form' because L&B keeps this a secret and wont tell us exactly how it does that.

Regardless, what I can say is that the Visos seem very predictable and repeatable. I can be in freefall with four other people, we can put our hands in the center and all of the Visos more or less read the same, limited by my ability to look at multiple screens at the same time. However, with the watch that is not the case. The amount that it differs by is different from the few jumps I did, both under canopy and in freefall, and there is a relatively large difference between the Viso and watch in freefall.

Of course we could argue that maybe the Viso is off and the watch is accurate. Possible. But I have jumped with other digital altimeters and found they read similar to what my Viso said. I have also jumped with another watch (forgot the brand at the moment) which has it's own altimeter software and it's closer to what my Viso says.

So what I think is happening is the barometer is probably accurate, but the software is lagging behind and what the screen is showing occurred in the past, not in the present which of course wont work.



Now, as far as agreement with other altimeters such as Viso, we need to do some tests with a good GPS to truly compare. It might well be that the Viso is off, not the Mission. I am using the most accurate altitude formula in full accordance to the U.S. Standard Atmosphere 1976:

altitudeAMSLInMeters = 44330.76923076923077 * (1.0 - Math.Pow(1013.25 / pressureInMillibars, -0.19026323650861))

(can be found in MainActivity.cs in the C# project I posted in another thread)

Who knows what formula L&B uses and what kind of float precision its chips have; the emperor might be somewhat naked - let's find out! One absolutely ridiculous example is Samsung Gear watches, see the sample code here, it uses the simplified barometric formula that doesn't take into account temperature lapse:

altitude = -8727 * Math.log(value / reference);

Not only that, but the factor 8727 is actually calculated from physical constants rounded to 1-2 digits after decimal point! (the precise value is 8434, quite a difference) Just another proof that Tizen = garbage; the Samsung's coding monkey just searched the webz for some formula and found this lame one.

pchapman

The watch could use some other method than simple averaging, but in any case it seems like it uses a fairly wide time spread of data, and doesn't try to predict the current conditions based on some average using the past.



Just to emphasize, the excessive smoothing/lag was due to my code, not due to pressure data coming from the watch. Android/Wear is terrific in this regard in that it gives the programmer truly raw data. I'm still stocked about this amazing hardware that fits a real nanocomputer in a wristwatch form factor. Here's a teardown of a 4-year old LG G Watch R:

[inline lg1.png]
[inline lg2.png]

(from https://www.onethesis.com/2015/03/31/the-lg-watch-r-teardown/)

It has an Alps electric Digital Pressure Sensor, outputting 90 pressure samples per second.

[inline lg3.jpg]

I don't know what type of pressure sensor Nixon Mission uses, but if closeness of its sample interval (6ms) to popular Bosch BMP280 (5.5ms) is any indication, it might be using Bosch.

We live in amazing times, and the best is yet to come! (I hear rumors of imminent release this Fall of a new Quallcomm Snapdragon 3100 SoC for smartwatches with more power and better battery life for always-on screens.
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

lg1.png

lg2.png

lg3.jpg

Share this post


Link to post
Share on other sites
A lot of the noise in the pressure readings in skydiving have nothing to do with the internal sensor noise, but rather from turbulence, motions of the skydiver, or things like opening the aircraft door. Since they do not originate from the sensor (more or less fixed time intervals) you'll want to filter them out anyway, and in the end you'll find out that no matter what barometer sampling rate you start with (well, at least beyond 10Hz), you'll end up with the more or less the same frequency response.

Share this post


Link to post
Share on other sites
aonsquared

A lot of the noise in the pressure readings in skydiving have nothing to do with the internal sensor noise, but rather from turbulence, motions of the skydiver, or things like opening the aircraft door. Since they do not originate from the sensor (more or less fixed time intervals) you'll want to filter them out anyway, and in the end you'll find out that no matter what barometer sampling rate you start with (well, at least beyond 10Hz), you'll end up with the more or less the same frequency response.



No, I don't want that. What I want is instant response to pressure changes, but without the sensor noise. If I'm raising my hand by 3.5ft, I want my altimeter to show me that in real time, as if it was a digital caliper. If I stick my arm out of the plane's door, I want to see the effect of dynamic pressure. (I smile every time I see Smart Altimeter go below zero by tens of feet when the plane is accelerating on the runway, due to dynamic pressure build-up in the cabin.) I don't want the phlegmatic Viso's "Keep calm and show 0 until you're hundreds feet in the air." And I don't want its constant silent calibration of 0 on the ground. Pressure changed due to weather - I want to see that, and zero it out myself just before boarding the plane.

For instant response, the lag should not be greater than 0.2s (I think). 0.2s at 120mph is about 35ft. If one were to do a comparison test with a fast GPS and made a special enclosure for the altimeter that eliminates pressure fluctuations and makes the pressure inside equal to static pressure, I don't want the altimeter to noticeably lag behind true altitude. Even 35ft is too much. Max lag of 0.1s is sweet. And there's a huge difference in terms of filtering the sensor noise when you have only 1 sample in that 0.1s window, or 16 samples (like in Nixon Mission). 10Hz for my purposes is way too slow. (I have an LG Watch Sport, it has a 10Hz barometer - it's useless for me, other than maybe for hiking.)

"Faster, faster, faster!" (Cutaway movie)
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
Fair enough. Why are you doing such heavy 3-stage filtering then? A simple low pass filter would suffice to eliminate barometer noise at the cost of bandwidth. In fact many of the MEMS barometers now have built-in low pass filters available. Do you know what's your end bandwidth after all the filtering?

Share this post


Link to post
Share on other sites
Thank you, Peter, for the kind words. I think the time has come to rethink altimeters from the ground up, because powerful and affordable hardware is here. The old concept of a little black box that we don't know what sensor it has, at what sample frequency, what barometric formula it uses (I've seen a few variations, and most of them have some inaccuracies, compared to USSA1976 standard), what floating precision its CPU has (I've done some programming for Texas Instruments EZ Chronos 430 a few years ago and struggling with 8-bit floats was miserable), what postprocessing it does, etc. - is so 1980's or 90's. We now can do so much more. We now live in era of nanocomputers on our wrists. Let's harness this power.

Let's "Make Altimeters Great Again"!
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
aonsquared

Fair enough. Why are you doing such heavy 3-stage filtering then? A simple low pass filter would suffice to eliminate barometer noise at the cost of bandwidth. In fact many of the MEMS barometers now have built-in low pass filters available. Do you know what's your end bandwidth after all the filtering?



Because there's too much fluctuation in raw altitude when the device is just sitting on a table (this is not noticeable in freefall, of course) to my liking. I want to smooth it enough that it fluctuates by inches, not by feet. But at the same time I don't want to introduce too much lag. Simple low pass filter is, unfortunately, too laggy - if, for example, you take 98% of the previous smooth value and 2% of the new raw value, the lag is in the order of 50 samples (1/0.02). Simple LPF is what iphone uses in its GPS data - if you jump with it, you'll observe a ridiculous lag of thousands of feet; you land and it's still thousands of feet in the air.

In search of better smoothing algorithms, I found Butterworth LPF, it's much better than the "vanilla" LPF. Also, I needed to calculate the first derivative of altitude - vertical speed, so I found Savitsky-Golay algorithm that both smooths the altitude data and calculates smooth derivative of it.

Using of 3 layers is purely experimental, and it's an attempt to achieve my goals: obtain very smooth data (reflecting real pressure changes), but without any noticeable lag.

My target bandwidth after all the filtering is now about 10Hz for devices that are capable of it (such as Nixon Mission @167Hz and LG G Watch R @90Hz). S-G algorithm has 12 sample lag (but in the latest update I temporarily disabled it, to investigate why it's sometimes creating spikes), LPF is set to 0.1s lag, BW was set to 5Hz, but again, I disabled it, need to do more work on it.

Now I know what to do next: let the user assemble the chain of filtering themselves! Start with raw altitude, then stack whichever filters (from several choices) you like, configure their parameters, and achieve the end result you like. Maybe even have presets that emulate traditional digital altimeters for those who are old-fashioned. "Want a Viso-like zero from take-off to 400ft? Here, help yourself."
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
One thing that might help is creating a Bode plot of the filters you're using - if you put them one after the other, you can calculate a transfer function, pass band, and the phase difference (lag).

As for the vertical speed, the derivative of a noisy signal will have the noise amplitude multiplied by the noise frequency, so the noise is greatly magnified and makes it quite a challenge :)

Share this post


Link to post
Share on other sites
TheEdge

guys pls ...stop with those altimeters wrist/arm band holders...waiting for a Head Up Display (HUD) directly on the helmet visor...

Tx:P



Anyone know any news/rumors on any compact HUD (like Google Glass, but affordable) coming out in the near future? HUD that just gets data from the phone, not a computer in itself, like Microsoft HoloLens.
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
yuri_base

***guys pls ...stop with those altimeters wrist/arm band holders...waiting for a Head Up Display (HUD) directly on the helmet visor...

Tx:P



Anyone know any news/rumors on any compact HUD (like Google Glass, but affordable) coming out in the near future? HUD that just gets data from the phone, not a computer in itself, like Microsoft HoloLens.

i think this will be the natural evolution...
Safe Landings

Share this post


Link to post
Share on other sites
TheEdge

******guys pls ...stop with those altimeters wrist/arm band holders...waiting for a Head Up Display (HUD) directly on the helmet visor...

Tx:P



Anyone know any news/rumors on any compact HUD (like Google Glass, but affordable) coming out in the near future? HUD that just gets data from the phone, not a computer in itself, like Microsoft HoloLens.

i think this will be the natural evolution...

Yeah, all I need to just mirror phone's display in the eye, that's it. HoloLens and similar AR glasses are just too bulky and expensive.
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
brokenback

There is the Garmin Varia Vision but I think if has to be linked to one of their devices.



Something like this, but non-proprietary and cheap ($100 tops).

I hope Apple will come up with some AR HUD companion for iphone; once Apple starts doing something, many follow and prices drop.
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
brokenback

Could try and find a Recon Jet or Snow, they are no longer made so could be cheap and they run Android.



Recon runs a proprietary OS - ReconOS, which is basically a murdered Android. So, the devs have to use their proprietary SDK and jump through hoops.

I strongly believe that the software is the king, the hardware is secondary. The hardware is so powerful and cheap these days that it doesn't make sense to sweat about it - if there isn't a suitable hardware today, there will be one tomorrow. I personally own several excellent $40-50 Android phones for various dedicated tasks - one for navigation, one for hiking, one for gym, etc. (they're unlocked, no cell service, basically, WiFi devices) It's fantastic. The last time I dropped almost a grand into Apple's or Samsung's pocket was 5+ years ago. The paradise is here!

So, any hardware that makes the developer to jump through hoops, is out of the question for me. I spent countless hours writing hundreds of thousands of lines of C# code that if Visual Studio can't deploy it to a device, that device can GTFO.

I'd rather take my Moto 360 Sport for $50 with wristband removed (it actually strikingly resembles an Oreo cookie, I'll post a pic tomorrow), put a watchmaker's loupe in a short plastic tube in front of it so that the screen is in focus, and voila! - have a "ghetto HUD" which can run any Wear OS app. Anyone can take the Visual Studio altimeter sample I posted in the other thread, customize it to their liking, and have a very personal altimeter/GPS HUD for skydiving.
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites
yuri_base


Anyone know any news/rumors on any compact HUD (like Google Glass, but affordable) coming out in the near future? HUD that just gets data from the phone, not a computer in itself, like Microsoft HoloLens.



Google Glass on ebay is around $400 used. Not "cheap" but skydivers happily pay same price for an N3. Glass fits well under a G3 and runs android.

[inline glass.jpg]
BASEline - Wingsuit Flight Computer

glass.jpg

Share this post


Link to post
Share on other sites
Who likes cookies here? Anyone likes the smart ones packed with sensors?

[inline 20180908_162038.jpg]

Exact same size, dumb and smart:

[inline 20180908_163242.jpg]
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

20180908_162038.jpg

20180908_163242.jpg

Share this post


Link to post
Share on other sites
platypii

***
Anyone know any news/rumors on any compact HUD (like Google Glass, but affordable) coming out in the near future? HUD that just gets data from the phone, not a computer in itself, like Microsoft HoloLens.



Google Glass on ebay is around $400 used. Not "cheap" but skydivers happily pay same price for an N3. Glass fits well under a G3 and runs android.



It can't just mirror phone's display, can it?

(if not, it's a major turn off - adds more friction to development, need to deal with yet another SDK)
Android+Wear/iOS/Windows apps:
L/D Vario, Smart Altimeter, Rockdrop Pro, Wingsuit FAP
iOS only: L/D Magic
Windows only: WS Studio

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account. It's free!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0