This app was mentioned in 17 comments, with an average of 2.41 upvotes
Can you try using an app like "Sensor Readout" or "Sensor Multitool" builtin's Step Detector and see if the problem persists? The "step detector sensor" is a virtual sensor, so doesn't really have any basis in reality*. It might depend on the app. I'm curious to see if this one has that issue as well.
https://play.google.com/store/apps/details?id=de.onyxbits.sensorreadout&hl=en https://play.google.com/store/apps/details?id=com.wered.sensorsmultitool&hl=en
Followup: by "basis in reality" I mean "has a physical chip dedicated to just that reading". The BM160 is merely an accelerometer, the rest is software processing of the simple 3-axis acceleration readout into more complicated things. Some of it is done on the sensor itself, other parts are done by the Android OS as needed.
Followup 2: Yep, managed to bug out the step counter in Sensor Multitool. I locked the phone while the app was running, maybe Doze is related to the issue? Can you try disabling battery optimization on your app and see if that fixes it?
If you think it's hardware related, use this app to check the sensor directly. The graphed red line will read "0cm" or "5cm".
If sensor is functional, it is a software issue. Try rebooting into Safe Mode with no Non-Google apps running. (Press and hold power button, then press and hold on Reboot icon until it asks you if you want to restart in Safe Mode.)
Certain call modes and pairings may cause the prox sensor to be ignored, such as Speakerphone (I think?), as others have pointed out. Are you using a Google certified screen protector?
Guide on debugging Hall Effect sensor I wrote back in 2015 for Nexus 6P. Old, but valid.)
Good info, nice to see real measurements! Any chance you could test Cardboard or Google Vr on a non-Pixel phone? I recall seeing that they tried really hard to get various latencies down for their first 100% Google flagship. Also, tiny nitpick, three 240fps frames is 12.5ms.
Sorta OT, but could I also ask you to check the accelerometer and gyroscope refresh rates on your Pixel? The Daydream specification calls for a minimum 200Hz gyro and 400Hz accelerometer and I'm curious what kid of hardware the Pixel is using to get to those numbers. I used sensor readout to check my Nexus 6 (225Hz for both) — long-press on the gyro or accelerometer and it'll report the 'Minimal delay' in µs.
If the Pixel is using higher refresh rates than the minimum spec, it's possible that cheaper Daydream-ready phones could have worse latency. Alternatively, if they hit ~23ms with the minimum 'Hi-Fi' sensors, then a 1000Hz sensor package like the one used with GearVR could shave a couple of ms off.
Just downloaded a REALLY good magnetometer viewer called Sensor Readout: https://play.google.com/store/apps/details?id=de.onyxbits.sensorreadout
Shows my Z-axis value pegged at around 2000uT when normal values are +-60uT
Talked with Nexus Support and they are sending me a new phone. Thanks for your help +sbozzie.
For what it's worth, the numbers I get from Tasker are similar to the numbers I get from Sensor Readout.
I'm not spotting an app named "Lux Level" in Google Play or F-Droid or Amazon Appstore. Do you have a link for it?
> Unfortunately this may significantly increase Tasker's power consumption.
One can use an app like Sensor Readout to see how many milliamperes a sensor consumes.
>My original thought was a Morse code system but that would take time to learn.
You only need one letter for each command, and I'll bet you could come up with unique ones. P for play/pause, T (and B?) for track change, U and D (which, incidentally, are symmetrical) for volume, S for silent/vibrate, R or N for read notifications, A for airplane toggle... I wouldn't think you'd need that last one in a lab, but I don't know. Try learning only one each day, since you're starting from nothing.
> I believe the proximity sensor will work with the screen on after switching on the screen with a hardware button press.
All phones are capable of having it usable with the screen off. Otherwise, it wouldn't work to toggle the display on/off while on a call. You can use an app like Sensor Readout to see how much current or power a sensor uses (in Sensor Readout it's a long-press on a sensor).
Edit: An easier target than your phone's hardware button would be a bluetooth selfie remote. I suspect there are even better bluetooth input devices.
Heres what i found out a couple of days ago:
The original cardboard uses a magnet as a physical "button". You move the magnet and the phone recognizes the changing magnetic field and interpretes it as a button click.
If you open an app like Sensor Readout and have a look at the magnet, you will see it randomly spiking, which the will be interpreted as a click.
I got around this issue by using the Cardboard Viewer Profile Generator. I created a profiles which ignored the magnet. It works fine for apps where you just look around and dont interact. For apps which require input, i have yet to find an alternative.
Phone accelerometers are extremely sensitive. To test this, you can get an app that displays sensor values (one for android) and open the accelerometer readout. If you lay the phone on a table and stomp on the ground a few meters away, it'll still sense a pulse in acceleration.
I think its this one..
"Sensor Readout"
https://play.google.com/store/apps/details?id=de.onyxbits.sensorreadout&hl=en
What app is that he's using in the video?
Edit: found it, it's called sensor readout https://play.google.com/store/apps/details?id=de.onyxbits.sensorreadout
Yes, Proximity Sensor is a boolean for Tasker and for most phones, with an implied True if you don't check the Invert checkbox. You can tap the ? (Help) for more information. You can use Sensor Readout or a similar app to see how sensitive your sensor is. With a recent (4.6 or higher?) version of Tasker, the context will turn green when active, and for me it has an annoying habit of scrolling the Profiles list to the top when a context's condition changes to met or changes to not met.
The hyperlink for collisions probably describes it better than I can. For many tasks, if the task takes less than a second to run, collision handling can be ignored, but if it takes more than that, collision handling should be considered. In your case, it's a question of whether you want the audio to be interrupted and play from the start or just continue playing. Come to think of it, due to how scheduling works, the existing media action wouldn't be interrupted, the audio would just continue playing.
>I could just add Proximity sensor as another context, but wouldn't that be a bigger battery draw?
That depends on your sensors. You can use an app like Sensor Readout (long-press entry) or Droid Examiner to see [a sensor's power (actually current) consumption in milliAmperes](https://developer.android.com/reference/android/hardware/Sensor#getPower(\)). On my Moto G, the proximity sensor uses 3 mA and accelerometer uses 0.25 mA, which aren't much on a 2070 mAh battery.
There's a testing menu available if you enter
##4636##
in the dialer. It gives you some low-level network information, has some toggle buttons that probably shouldn't be touched, but doesn't have any sensor info.
If you're looking for readings from the sensors -- say the magnetometer or barometer -- you can try one of the following apps:
Edit: Note that CPU-Z displays full-screen ads. I believe the other two are ad-free at this point.
Try something like Sensor Readout and check to see if your proximity sensor is working or not.
https://play.google.com/store/apps/details?id=de.onyxbits.sensorreadout&hl=en
Sensor readout displays detailed information about all the sensors in your phone. Mesmerizing!