9

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.

Community
  • 1
  • 1
steckl
  • 404
  • 8
  • 16

3 Answers3

2

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...

Sebastian Staacks
  • 317
  • 2
  • 10
0

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

Refer to http://developer.android.com/reference/android/hardware/SensorManager.html for more details.

Sergey K.
  • 24,894
  • 13
  • 106
  • 174
  • Thanks for you answer, but that's not what I was asking for. The question was if there is a benefit in using C++ (NDK) instead of Java (SDK). – steckl Sep 23 '12 at 14:18
  • We are using JNI to pass the G-sensor data from Java to native and found no problems with that. – Sergey K. Sep 23 '12 at 14:43
  • Do you gain any benefit from your method? Why don't you use the Sensor-Interface of NDK directly? For me your method has no benefit, since I don't do any computation with the sensor data, I just forward it to a server. – steckl Sep 23 '12 at 15:06
  • Our application has to run on Android 2.2 so we had to stick with the Java code. – Sergey K. Sep 23 '12 at 16:12
  • Can you help me out on this [question](http://stackoverflow.com/questions/34997669/android-acceleration-down-smash) please? – Skizo-ozᴉʞS ツ Feb 01 '16 at 16:10
0

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

a) Using base Java is fast enough for handling multiple sensors. In one of my applications, I read Accelerometer, Gyroscope, Magnetometer, Game Rotation Vector and Uncalibrated Magnetometer all at once with SENSOR_DELAY_FASTEST.

On top of this I also did a bunch of filtering and storing of data, as well as some quaternion maths to keep track of rotation. Looking at the raw data (which I also saved to a .txt file), there didn't seem to be any missing data or delays (average difference between time stamps was the same as running a single sensor with no calculations).

So in my case, the sensors were working as fast as they could and Java was keeping up fine.

...

That said, if you're doing very large amounts of computations, using NDK might be worth trying.

Svj0hn
  • 454
  • 5
  • 19