1 person found this helpful
I think it's most likely a plugin restriction. From the time that doc was written, there were various tests done to see which ranges would work best based on hardware and the js-native bridge. However since writing that doc, it might be possible to get a higher frequency you wanted because of new hardware. So, it's probably possible to change but we haven't looked into it.
Thanks for your comment - could the docs be out of date from the code? I only ask as I can't see anything with in the library which shows any resetting if outside the defaults mentioned.
I've been trying to trace the options and frequency to see if the code still does show behaviour of defaulting between 40ms and 1000ms.
I couldn't see anything in the JS for the frequency defaulting the value if outside of these values:
And within the iOS I can see the internval defaults to 10ms... which conflicts with the docs?
Hrm, I think the docs might be out of sync with the code. It does seem to be the case that the plugin can give you about a 100Hz on iOS.
Have you tried giving it a go and see if it works for you?
I've tested on Android, and it is limited.
So where the Android version is using SensorManager.SENSOR_DELAY_UI - which limits to 60,000 microseconds (16Hz).
If I understand this correctly, to make this small change and make the update to me available on PGB, I would need to fork the current API on NPM to increase to SensorManager.SENSOR_DELAY_GAME - which increases to 20,000 microseconds (50Hz).
"You can specify other data delays, such as SENSOR_DELAY_GAME (20,000 microsecond delay), SENSOR_DELAY_UI (60,000 microsecond delay), or SENSOR_DELAY_FASTEST (0 microsecond delay). As of Android 3.0 (API Level 11) you can also specify the delay as an absolute value (in microseconds)."
Out of interest - would a pull request to increase the default frequency on Android go through?
I have found you can now link to APIs from github directly without having to load into NPM - which has helped test changing the Android frequency.
What would I have to do to get the master of cordova-plugin-device-motion changed to implement the faster polling of the accelerometer on Android?
I appreciate polling the accelerometer is heavy on battery use, but I can't see the any decisions on why the plugin is set to SensorManager.SENSOR_DELAY_UI
I have finally created dev certificates and tested on an iPhone 7, and the iOS at 50Hz does create unique timestamps - meaning the docs are out of sync with the API.
Hrm - I'll have to find out about android on changing the frequency of the polling for master. You are probably right in that the default is set so you don't kill the battery.
For the iOS stuff, I'll mark an issue about the docs being out of date. Thanks for the diving into this and finding the dusty corners