taux d'événements du capteur « Custom » ne semblent pas travailler avec SensorManager.registerListener (écouteur SensorEventListener, capteur capteur, int rate)

Question

MISE À JOUR:

j'ai pu résoudre le problème spécifique que je faisais en introduisant une classe -scope compteur statique et simplement ignorer x nombre d'événements. Mais j'aimerais quand même savoir ce que je fais de mal: enregistrer l'auditeur avec un indice en microsecondes au lieu d'utiliser l'une des quatre constantes données. Une activité dans mon application consiste à engager les capteurs pour obtenir l'orientation du périphérique, déterminer le rouleau et l'utiliser.

J'utilise

SensorManager.registerListener(SensorEventListener listener, Sensor sensor, int rate)

pour enregistrer mes capteurs. Des Android Documentation for this method:

Paramètres

[...]

taux

Les événements du capteur de fréquence sont livrés à. Ceci est seulement un indice pour le système. Les événements peuvent être reçus plus rapidement ou plus lentement que le taux spécifié. Habituellement, les événements sont reçus plus rapidement. La valeur doit être l'une de SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, SENSOR_DELAY_GAME ou SENSOR_DELAY_FASTEST ou, le délai souhaité entre les événements en microseconde.

Si j'utilise l'une des 4 constantes prédéfinies, l'application fonctionne correctement; Cependant, ces constantes fournissent toutes des indices de taux qui sont trop rapides pour mes besoins. Je dois envoyer un paquet UDP contenant des informations avec chaque changement d'événement, et l'extrémité réceptrice semble être complètement inondée de messages en utilisant n'importe lequel des taux prédéfinis. L'utilisation d'un nombre entier de 30000 (puisque l'API spécifie des quantités en microsecondes) oblige l'application à arrêter de rapporter tous les événements de capteur.

Qu'est-ce qui me manque, qui m'empêche d'utiliser mes propres indices de taux d'événements?

Answer 1

Je suis assez sûr que le taux d'écoute de capteur a fait ce qu'il est censé faire. Dans votre question, vous avez écrit 30000, soit 30 millisecondes. Dans le document, il est dit que le taux est généralement plus rapide que l'indice. Donc vous faites plus vite que 30ms. Est-il possible que vos autres routines liées au réseau soient allées trop vite? Cela peut avoir provoqué un blocage qui vous amène à croire que le signalement du capteur est arrêté.

Dans mon application, je trouve aussi le taux NORMAL donné trop élevé. Par conséquent, j'ai mis un taux à 250000. J'ai également utilisé le calcul de la moyenne mobile pour lisser le nombre de 5. Je trouve le comportement résultant proche de la boussole de l'iPhone. Néanmoins, je ne suggérerais pas que vous fassiez des rapports réseau dans un écouteur de capteur. Ce n'est pas censé être fait de cette façon. Vous pouvez cependant faire un calcul simple dans l'auditeur et enregistrer la valeur. Ensuite, utilisez une minuterie comme Handler.postDelayed avec un nombre élevé, pour gérer l'envoi de réseau entre autres choses.

Answer 2

Cette question a été posée en 2011, mais elle a quand même beaucoup changé depuis; Depuis l'API 19 (2013+), il existe une nouvelle variante de l'API d'enregistrement, dans laquelle vous pouvez indiquer à quel intervalle vous souhaitez recevoir les lectures du capteur. De la documentation:

registerListener booléen (écouteur SensorEventListener, capteur Sensor, int samplingPeriodUs, int maxReportLatencyUs) Enregistre un SensorEventListener pour le capteur donné à l'échantillonnage donnée fréquence et le temps de latence de rapport maximale donnée.

Cette fonction est similaire à registerListener (SensorEventListener, Sensor, int) mais elle permet aux événements de rester temporairement dans le FIFO matériel (file d'attente) avant d'être remis. Les événements peuvent être stockés dans le FIFO matériel jusqu'à des microsecondes maxReportLatencyUs. Une fois qu'un des événements dans le FIFO doit être signalé, tous les événements dans le FIFO sont rapportés séquentiellement. Cela signifie que certains événements seront signalés avant que la latence de rapport maximale ne se soit écoulée.