Help to interpret Accelerometer data...

Looking at your graphs one can come to a conclusion, that this data shows acceleration working on the sensor in all 3 axes. They are represented in milli-G units where 1 G (i.e. 1000 units) is equivalent to earth's gravity acceleration, and this is why you get values close to 1000 (i.e. 1 G) on the Z axis, as it is constantly exposed to gravity.

Looking at your graphs one can come to a conclusion, that this data shows acceleration working on the sensor in all 3 axes. They are represented in milli-G units where 1 G (i.e. 1000 units) is equivalent to earth's gravity acceleration, and this is why you get values close to 1000 (i.e. 1 G) on the Z axis, as it is constantly exposed to gravity.

You're perfectly right... I wonder why I did not think of that... I probably need another cofee :-D

As far as how to use the data, look at the AccelMag sample in the SDK.

The API documentation has this information as well: https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Sensor/AccelerometerData.html

The API documentation has this information as well: https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Sensor/AccelerometerData.html

Yes but there is no info on what "means" the values. I'm not used to accelerometer data thus it's not easy to figure it out...

The vector values for pitch & roll... not very clear for me how it is coded..

And what is power (as a vector of floats) ?

Yes but there is no info on what "means" the values.

It states that the numbers in the arrays for each axis are in a unit representing acceleration, so probably safe to assume they represent acceleration. There is some ambiguity though in how the axes map physically to the device, but that is not difficult to work out (as done by tmk2 above) and in my experience the mapping has been consistent across all of the watches and edge units I have been able to test it on. There is also some mixing of the plural and singular when referring to each individual axis, heh.

Pitch and roll refer to the rotational orientation of the device and are in degrees.

Power is the euclidean norm, or magnitude, of the acceleration vector. I would agree that this attribute isn't clearly documented either as I have not seen the norm referred to as a 'vector power' and my first instinct would be to think that it consists of power values as reported by a Vector power meter.

Power is the euclidean norm, or magnitude, of the acceleration vector. I would agree that this attribute isn't clearly documented either as I have not seen the norm referred to as a 'vector power' and my first instinct would be to think that it consists of power values as reported by a Vector power meter.

But what's the use of that. If your watch is flat and not moving, you'll have a high power (due to the 1g component on z axis). And if you're watch is falling the power will be near 0....

If your watch is flat and not moving, you'll have a high power (due to the 1g component on z axis). And if you're watch is falling the power will be near 0....

Exactly, since it is the normalization, it will only deviate from the 1 G reading when experiencing translational acceleration. That metric alone won't respond to rotational motion assuming it is rotating perfectly around the accelerometer, would need a gyroscope for that. If you care just about total motion, then this pre-computed norm makes things much easier. The computational cost of obtaining these values in monkey C would be significant in comparison to the native implementation provided through this field. Even if you are just trying to normalize the instantaneous vectors for display to a user, then this already does a good chunk of work for you.

Another example, lets say you are trying to work out an algorithm to detect a repetitive motion such as walking or rowing. The watch could be oriented any number of ways on either wrist. Instead of applying a filter to each axis and attempting to identify orientation, you might find it sufficient to just look at the magnitude, and that would in turn save you the cost of running two unnecessary filters.

It states that the numbers in the arrays for each axis are in a unit representing acceleration, so probably safe to assume they represent acceleration. There is some ambiguity though in how the axes map physically to the device, but that is not difficult to work out (as done by tmk2 above) and in my experience the mapping has been consistent across all of the watches and edge units I have been able to test it on. There is also some mixing of the plural and singular when referring to each individual axis, heh.

I agree we need to clarify this a little more. I suppose we assumed that since it's accelerometer data, that it's implied these are acceleration values, but it wouldn't hurt to spell that out. I created a ticket a while ago to clarify how the axes map to device orientation, too, since that's not apparent (though it can be determined empirically). From my perspective, we should ensure the mappings are pre-defined so we can verify they're correct. :)

The singular/plural mixing is my mistake--I'll get that fixed.

Great discussion. :)

UPDATE: I've already got tickets open for all of these updates, and in fact I authored several of the changes at some point. We just haven't gotten them added to the API docs yet. They're planned for a future release, however!