Difficult to activate on drops

[vixsomnis]

I tested by dropping my phone (LG G2) onto a bed.

At 5g, it was oversensitive to hand movements and barely sensitive enough for drop triggering.

Decreasing or increasing the threshold doesn't allow both to function. From what I can tell, it's related to the accelerometer having different sensitivites to forces from different directions.

Can anyone corrobrate this? I don't believe it's device specific.

[SyntaxBlitz]

This is true. I don't have a great idea on how to fix it.

Right now, the app uses the TYPE_LINEAR_ACCELERATION sensor to get the device's acceleration. This is often implemented in software, using the TYPE_ACCELEROMETER sensor internally and then cancelling out 9.81 metres per second from whatever axis is upright. I'm not sure if it does this just by calculating the magnitude of the vector or by using trigonometry and the orientation of the device, but it does a pretty good job.

I have a feeling this sensor doesn't report negative values when it's in free-fall, so it doesn't allow for the phone to determine whether it is in free-fall. And once the phone ends up on the surface, the values just go back to zero.

There seem to be two ways to 'solve' this:

• I can start using the raw TYPE_ACCELEROMETER sensor, attempting to calculate the acceleration's combined magnitude manually. This would provide some value around 9.81 whenever the device is at rest, regardless of its orientation. Then the threshold would be tested after subtracting 9.81 from the result; this would effectively test whether the device is in free-fall, returning a negative value if it was. I've tried this in the past, and... I don't like the results. It seems like it's really easy to accidentally activate the lock and very difficult to do it intentionally. I'm not quite sure why. This would also (if my understanding is correct) only activate the lock on free fall if the threshold were lower than g; otherwise, it wouldn't even activate once the phone hit the ground.
• I can also start checking for changes in acceleration over time. This seems like it would be effective in determining a drop, but it adds complexity to the code and I don't actually know how well it would end up working to determine plucks. The derivative of acceleration is "jerk", which seems to be just about what I'm looking for. But for now, using just acceleration and a threshold is effective; I'm not sure whether it's totally worth it to start caching values so I can determine a ghetto rate of change for acceleration. I will play around with this to test its merit.

Thanks for the input; I had almost forgotten that dropping is an issue that needs to be resolved.

[vixsomnis]

If there's some way to get the vectors (x,y,z) of acceleration, and look at each individually, then it's just a matter of finding some calibration constant to relate the magnitudes.

I'm unsure if this exists.

By the way, the accelerometer reports net acceleration on the phone (I assume -- the other way makes no sense). In the case of an object at rest, it'd have a net acceleration of zero. It's only under an acceleration of magnitude g when it's in freefall.

Cancellation of force vectors and all that jazz.

[SyntaxBlitz]

It's possible to get all three vectors separately.

The docs mention that, indeed, the accelerometer's data include the acceleration from F_g. I've verified this with the values that I actually get from the accelerometer. I'm using the LINEAR_ACCELERATION soft-sensor because it performs the cancellation of these values for me.

Realistically, it makes more sense for PluckLock to use jerk, rather than acceleration, to make these determinations. Then I wouldn't need to cancel anything out. In the future, this is probably what I'll end up doing.