Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the exact sampling rate of the "fastest" sensor rate? #49

Open
vYLQs6 opened this issue Nov 21, 2024 · 1 comment
Open

What's the exact sampling rate of the "fastest" sensor rate? #49

vYLQs6 opened this issue Nov 21, 2024 · 1 comment

Comments

@vYLQs6
Copy link

vYLQs6 commented Nov 21, 2024

Hi there,

I'm really impressed with Sensors2OSC and its potential for real-time applications.

I'm curious about the exact sampling rate of the "Fastest" sensor rate(of Gyro) in Sensors2OSC's settings. Is it higher than the 200Hz (5ms) offered by HyperIMU?

I've tried looking through the code, but as I'm not familiar with Android app development, I'm unsure where to find this information.

Any insights would be greatly appreciated. Thanks again for creating such a fantastic app!

@residuum
Copy link
Member

residuum commented Nov 21, 2024

The sampling rate is not settable by the app itself, but depending on the device.

From the official documentation (emphasis mine):

The default data delay is suitable for monitoring typical screen orientation changes and uses a delay of 200,000 microseconds. 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).

The delay that you specify is only a suggested delay. The Android system and other applications can alter this delay. As a best practice, you should specify the largest delay that you can because the system typically uses a smaller delay than the one you specify (that is, you should choose the slowest sampling rate that still meets the needs of your application). Using a larger delay imposes a lower load on the processor and therefore uses less power.

There is no public method for determining the rate at which the sensor framework is sending sensor events to your application[...]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants