Android: Improve Sensor Sample Rate with NDK and Poll

Question

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

Here are my questions:

a) What is the bottleneck when reading sensor values ​​from the sensor? Is it senosr or Java itself? Can I increase my bid using the NDK? (I think that for the GPS the bottleneck is the sensor itself, but I read that, for example, the Gyro-Sensor is pretty fast) I found this topic , and it seems the sensor is the bottleneck. Can someone confirm this?

b) Does polling percentage increase instead of using EventListener? What is the best way to quickly read sensor values?

c) Does the NDK have any effect on the power consumption of the application? I did not find anything about this.

d) I am new to Android. Is using NDK much more affordable instead of regular Java? According to this sample-code, it seems that it’s easy to interact with sensors using the event queue, but how much is it necessary to compile the code and use it from the application?

Thanks in advance.

Answer 1

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

(Caution: this is only my impression and my reasoning. I have no source for this, except for my experience in developing the phyphox application, which records sensor data that will be used in physical experiments.)

I'm not sure whether to call it a bottleneck, but it seems that speed for SENSOR_DELAY_FASTEST is the design choice of the manufacturer. SENSOR_DELAY_FASTEST often results in a frequency of around 100 Hz, but some devices (Nexus / Pixel, some Smasung flagships) offer frequencies up to 500 Hz with the same setting. If you read the manufacturer and model of the sensor, you can often find the data table of the actual device, and you will notice that usually they can be controlled much faster. I think speed is a compromise between high speed and reasonable noise.

In addition (and perhaps even more importantly), if the manufacturer sets the SENSOR_DELAY_FASTEST level to SENSOR_DELAY_FASTEST , this may affect battery life. The phone should not only read each value (and if the phone has a dedicated processor for this, this processor must have the necessary bandwidth), many applications use the SENSOR_DELAY_FASTEST setting without much attention. Each value will call a callback function for the new value, so a phone with a frequency of 500 Hz will have to call this function at the same speed and may show a poorly encoded subroutine in the application that seems to work smoothly on the device. which offers 100 Hz.

b) Does polling increase speed instead of using EventListener? What is the best way to quickly read sensor values?

I do not know how to poll the sensor directly. In related threads, the term “polling” is used to “polling” a data queue that has been populated by a sensor. I would be happy if someone could correct me here by showing the sensor polling method directly on Android ...

c) Does using NDK affect application power consumption? I did not find anything about this.

This obviously makes sense if you can reduce the computational load with a more efficient native procedure. I expect only a noticeable impact if you can optimize some heavy computing.

d) I am new to Android. Is there much more to let you use NDK instead of regular Java? According to this code example, it seems that interacting with sensors using the event queue is quite simple, but how much does it allow you to compile the code and use it from the application?

This is pretty subjective, but it took me some time to set up and learn how to use the NDK and its interfaces. After it is launched, the code extension and recompilation work without problems in Android Studio.

-

I don’t know exactly what you plan to do with the sensor data, but you should bear in mind that Java can easily process audio data that is usually recorded at 48 kHz. Of course, audio samples are 16-bit values ​​written to the buffer instead of SensorEvent objects passed to the callback, but you can still iterate over each sample in real time using Java, so if you don't plan on some unusual analysis Java speed should not be a problem for sensors.

Another thing you should know about is the SensorDirectChannel , introduced with API level 26. I haven't tried it yet, but the documentation mentions RATE_VERY_FAST , offering 440 Hz to 1760 Hz. If your phone supports this ...

Answer 2

When you register your sensor listener, you need to pass SensorManager.SENSOR_DELAY_FASTEST to registerListener() .

See http://developer.android.com/reference/android/hardware/SensorManager.html for details.

Answer 3

From experience, I can at least answer the first of your questions:

a) Using basic Java fast enough to handle multiple sensors. In one of my applications, I immediately read the accelerometer, gyroscope, magnetometer, rotation vector and non-calibrated magnetometer with SENSOR_DELAY_FASTEST.

In addition to this, I also did a bunch of filtering and data storage, as well as some mathematical quaternions for tracking rotation. Looking at the raw data (which I also saved in a .txt file), there were no missing data or delays (the average difference between the timestamps was the same as starting a single sensor without any calculations).

So, in my case, the sensors worked as fast as they could, and Java continued normally.

...

However, if you do very large amounts of computation, using NDKs may be worth it.