GeezerVison

Seems to be working well for me.

After running it for a couple of days, I think the speed and threshold could be lowered a bit.

I've been testing this a bit too, it seems like an improvement but I am still getting some false positives, usually when I'm lying down/on the sofa when my arm is close to horizontal but angled slightly up, a small movement will wake the display. It's difficult to pin down as it only seems to happen accidentally, if I try to replicate it I can't! I'll keep testing and try get more info.

Rebased onto latest develop.

I've just updated it to use either the y or z values depending on which is more accurate. This means that it also works when the facing down and towards you. The threshold values and speed values are now also variables so it's easier to adjust them, and I've increased them.

I'm aware that the code is a bit of a mess of if-statements and returns, it should be possible to make it a oneliner like my last version was. Edit: just noticed I left some define macros in that I used for testing, I'll take them out when I change the code again.

I don't think using Z in place of Y is correct, because the axis don't receive comparable acceleration. Y is basically detecting wrist rolling, which is what we want. Z detects moving the arm up, which can be useful data, but it's not the same as Y.

I think motion algorithm changes are difficult to test, because it only depends on feeling. What should we look for when testing this? Please explain your thoughts behind the changes in detail and for each future revision, so we can get an idea of how this should work. People with two PineTimes can help compare the behaviour.

I believe that using Z is fine, because Y and Z are both the same axis, just offset by 90 degrees. This means that when Y is at (-)1024, Z is at 0, and vice versa. I've noticed that the larger the values are, the less they change with the same motion (A.K.A they are less accurate). For example, if the watch is facing up, Y is at 0 and Z is at -1024, and a slight movement will have more of an effect on Y than on Z.

In the current state of this PR, you should need around the same movement speed to get it to wake up all the time. It should also work when the watch is facing down and towards you, so that should help when you're lying down. When the Pine64 EU store (finally) opens, I'll be getting another PineTime, so then I can make sure that I'm not just catering to my specific device's quirks :).

because Y and Z are both the same axis, just offset by 90 degrees

I don't think I understand what you mean. Z is from the front of the screen to the back of the device. Y is from the top of the device to the bottom. When you tilt the device, the acceleration due to gravity will affect one of the axis more than the other, but the tilting of the wrist only affects the Y acceleration, since there's no movement along Z.

A visual might help, but my drawing skills are not up to par, especially not with a mouse ;-). It's quite difficult to explain using words, but maybe you can try it on your own device using the motion app.

If the screen is facing up, the Y value is 0 and the Z value will be shown as -64. Then, if you slowly roll the screen towards you, the Y value will drop below zero, and the Z value will increase. Once the screen is completely facing you, the Y value should show as -64 and the Z value should be 0.

I personally haven't looked at the spec sheet, so I don't know what the values are supposed to represent, I just figured it out through a lot of testing. I can't see anything that the Z value could be other than roll offset by 90 degrees, but maybe I missed something.

Here is a very crude visual I just made.

If there was no gravity, these would all show 0 by default. What you're showing is acceleration due to gravity. An accelerometer shows device movement and gravity combined. Please note the difference between a gyroscope and an accelerometer.

Ah, I see now. I did make a mistake, I misunderstood what Z does. In the code, I do use the values of Z in a way that doesn't align with what it means, but I think that because of the X threshold it can't cause incorrect behaviour.

This change should be the final change (bar maybe some tweaking of the values if people think it's necessary). I think the is good and readable enough to be merged. I have made it so that the required speed to wake the device is slightly dependent on the current y value, because the bigger it is, the less sensitive it is.

I would like some testing on it, because at the moment the values are right for me, and I would like to know if that is also the case for other people.

There are still a lot of changes here and reading the commits individually isn't proving any simpler. Not sure why shakewake was changed in the same PR and also the same commit where a lot of other stuff was done. LVGL has cheap sine functions that are already used in the analog watchface if that would be useful. _lv_trigo_sin().

I think this is ready to be reviewed now. I have made some changes that mean that this has as few false positives as possible, while making sure it does wake when the user wants it to. It checks that the accelerometer values can reasonably be assumed to be from gravity, then checks that the wrist was rolled more than 45 degrees within 6 SystemTask cycles (around 600ms).

To make the recovery firmware not fail when linking, I've added an ifdef to the arcsin function so it doesn't use lvgl. This is the best solution I could think of, other than creating a separate SystemTask for the recovery firmware.

There are a lot of separate cases in the DegreesRolled function, but I'm quite sure that's the only way to make it work in every situation.

Hey @FintasticMan ! Thanks for this PR and for taking the time to refine it over and over again :)

I've just tested this PR and compared it with the current implementation. At first sight, this new implementation reject more false positives that the current one. It's also a bit slower, but the reaction time is still reasonable, in my opinion.

About the code, I'm very bad at signal processing, and I can't really judge if this new algorithm "makes sense" or is "mathematically correct". It does however seem to work fine :+1!

Did you have the opportunity to get feedback from other users?

All in all, if this new implementation is still comfortable enough bug avoid waking up the watch when it's not necessary, it'll probably help with unwanted display and touch activation, and will also improve the battery life!