Rotational Eular maths

No mathematicians here ? 

Well, not too sure to understand your question... but if you are trying to measure accel on the axis to center of earth then...

I tried to do that to develop a dynamic variometer to measure when the watch climb or fall (glider app for example). The variation of pressure was not fast enough to help glider pilot for example to catch the ascending air.

This required 3 axis gyro values and some math.

The problem is that you do not have access to gyro value... 

So, project stopped ;) 

I would be very interested if you find a different way to measure this accel.

Good luck

Actually, gyro data is coming in System 5, and with the 4.1.0-beta 1 SDK you can try it in the sim with the preview devices.

https://developer.garmin.com/connect-iq/api-docs/Toybox/Sensor/GyroscopeData.html

Fantastic ! thank you very much ! I did not notice... this opens new horizons!

As Jim said below. 3 axis Gyro data is coming shortly, we all ready have 3 axis acceleration data, and 3 axis magnetometer data.  My issue is trying to understand the limitations of the maths, with a similar  problem you had with your glider, there is gravity and then there is induced gravity by the glider, and then also induced by the pilots' wrist moving around.  So time to crank up your project as well. 

My concept was to be able to accurately measure jump height... for example you throw your watch in the air, a gust of wind comes and blows it up or down mid flight,  and then  it lands, then tells you how high it went ( 3.3 meters ) for example. That is not my use case, but that is essentially what I am trying to number crunch. My thinking was that I did not have to record the data for the entire throw, and landing of the watch, but rather at some point in time on the way up, until after it had landed. 

That would then rely on probably an accelerometer figure to recognise the throw had happened. ( easy ) 

After landing the watch would have recorded at 25Hz, the accel / gyro and magnetic values for the entire descent portion of the jump until after landing.  The figures after landing ( the last figures ) would be under the least amount of acceleration, and I could use those figures to orient the watch, and then calculate vertical velocities and integrate backwards to the apex of the jump where vertical velocity changes. I would then have the vertical jump height.

Hence I was wondering, do I need to solve the entire Eular maths, to figure out the X/Y/Z rotation translations of the watch with respect to all axis, when the only axis I am actually interested in is the acceleration in the vertical axis, and none of the other data actually matter.

The limitations I have are that there is an extra force that opposes gravity ( the kite that pulls a kitesurfer up in the air)  It always opposes, and will never "add" - which means during launch the watch will overread the net gravity, near the jump apex it will start under reading gravity, and during descent it may under-read and overread at times, as the kite can produce acceleration vertically upward in the descent phase that may stop vertical velocity.

After landing, the vertical acceleration from the kite stops, and it commences horizontal + wrist movement type accelerations. In the launch of the jump, acceleration is never directly up either, it could be 30 degrees off vertical for example.  

To "integrate backwards", you need the value of g in each (tiny) step and the discrepancy between the size of g and the size of the accelerations induced by external factors swamps the precision you need for the exercise.

I am (was) a mathematical/ physicist and wasted many hours attempting this.

jim_m_58 said:

Actually, gyro data is coming in System 5, and with the 4.1.0-beta 1 SDK you can try it in the sim with the preview devices.

As discussed elsewhere, you can "try" it in the sim with the System 5 preview devices, but all that means is the code will compile and run without errors. You won't actually get any simulated gyroscope data from the sim (if anyone is looking for that.)

I don't think the external factors actually matter to the calculation. 

It doesn't matter for example that that the watch rotates as it is being accelerated upwards, because the 3 axis gyro can correlate with each G reading the exact orientation the watch is actually in, and if a person moves his hand up 10 cm higher when jumping - then the jump height will read 10 cm higher, I don't see a problem with this.

They already use similar technology in the WOO device, North PIC and various others, which have proven to work.

I was thinking of once getting the vertical component of acceleration, multiply it by the update time period, then add half the difference between the pervious G and current G times by time to smoothen out the acceleration figure. 

What you are planning is as explained here: https://youtu.be/BoMO-Peobsw. In the real world of 3D you have to allow for g. Whatever value you use for g, it will be sufficiently imprecise (how many decimals are you going to use for g? ) or inaccurate (the value of g varies from place to place) to introduce swamping inaccuracy in your integral.

It's called "inertial navigation" and is beyond the capability of watch sensors.

The sensor on the watch measures in milliG.  The noise level seems to be approximately + or - 15 milliG, which if all the errors compound on the same side, we are only talking about a 24 centimeter error for a 6 to 12 meter high jump, which is fine for me. even up to 10% error  would probably be acceptable.