Android: Improve sensor sampling rate by use of NDK and polling

Question

I want to write an application that reads as many sensor vaulues (per time) as possible from different sensors (GPS, Acc, Gyro, Compass). So I have to investigate if there is an advantage in using NDK.

Here are my questions:

a) What is the bottleneck when reading sensor values from a sensor? Is it the senosr itself or Java? Can I increase the rate by using NDK? (I think for GPS the bottleneck is the sensor itself, but I've read that e.g. the Gyro-Sensor is quite fast) I found this thread and it seems the bottleneck is the sensor. Can someone confirm this?

b) Does polling instead of using EventListener increase the rate? What's the best way to read sensor values fast?

c) Has the use of NDK any influence on the power consumption of the application? I didn't find anything about this.

d) I'm new to Android. Is it much more afford to use NDK instead of normal Java? According to this sample-code it seems to be straightforward to interact with the sensors using an event-queue, but how much afford is it to compile the code and to use it from the application?

Thanks in advance.

Answer 1

a) What is the bottleneck when reading sensor values from a sensor?

(Careful: This is only my impression and my reasoning. I do not have a source for this except my experience in developing the app "phyphox", which records sensor data to be used in physics experiments.)

I am not sure if this should be called a "bottleneck", but it seems like the rate for SENSOR_DELAY_FASTEST is a design choice by the manufacturer. SENSOR_DELAY_FASTEST often results in rates around 100Hz, but some devices (Nexus/Pixel, some Smasung flagships) offer rates up to 500Hz with the same setting. If you read out the manufacturer and the model of the sensor, you can often find the datasheet of the actual device and you will notice, that they usually could be driven much faster. I think that the rate is a trade-off between a fast rate and reasonable noise.

Also, (and maybe even more important) if the manufacturer sets a high rate for SENSOR_DELAY_FASTEST, this may have an impact on battery life. Not only does the phone have to read out each value (and if the phone has a dedicated processor for this, this processor needs to have the necessary bandwidth), many apps use the SENSOR_DELAY_FASTEST setting without much consideration. Each value will call the callback function for a new value, so a phone with a rate of 500 Hz will have to call this function at the same rate and might exhibit a badly coded routine in an app that seems to work just smoothly on a device that offers 100 Hz.

b) Does polling instead of using EventListener increase the rate? What's the best way to read sensor values fast?

I do not know of a method to poll the sensor directly. In the threads you linked, the term "polling" is used to "poll" the data queue which has been filled by the sensor. I would be happy if someone could correct me here by showing a method to poll a sensor directly on Android...

c) Has the use of NDK any influence on the power consumption of the application? I didn't find anything about this.

It obviously has if you can reduce computational load by a more efficient native routine. I would only expect a noticable impact if you can optimize some otherwise heavy computation.

d) I'm new to Android. Is it much more afford to use NDK instead of normal Java? According to this sample-code it seems to be straightforward to interact with the sensors using an event-queue, but how much afford is it to compile the code and to use it from the application?

This is rather subjective, but setting up and learning how to use NDK and its interfaces took me a while. Once you have it running, extending your code and recompiling works seemlessly in Android Studio.

--

I do not exactly know what you plan to do with the sensor data, but you should consider that Java can easily handle audio data, which is typically recorded at 48 kHz. Granted, audio samples are 16 bit values written into a buffer instead of SensorEvent objects handed to a callback, but you can still iterate over each sample in realtime using Java, so unless you plan some fancy analysis, the speed of Java should not be an issue for the sensors.

Another thing you should be aware of is SensorDirectChannel introduced with API level 26. I have not tried it yet, but the documentation mentions RATE_VERY_FAST offering 440 Hz to 1760 Hz. If your phone supports this...