Sweet! You beat me to it (probably by a number of years). It seems to work great on my current phone (Droid Turbo 2), but I have a Droid RAZR and Galaxy S4 with 4g problems that I plan to actually use to measure runtimes. Now I just need to build an integrating shoe box.
Well, I certainly wasn’t going to write Java when not forced and/or paid a lot.
While it’s fundamentally a pretty simple app that doesn’t require much in the way of fancy language features, it has been really nice to have watchers, futures and promise/deliver. And the REPL, of course. I don’t know how people get anything done in environments where they can’t interact with their running code in real time.
Try developing/testing flashlight drivers. Take your best shot, take apart your light, rig up the clip/USB dongle, dnld, assemble the light, test -- over and over again . You do get better and better at getting it right the first time.
Any plans to put this on the Google Play store? I’m not sure if this would incur any cost to you.
I’ve side-loaded stuff on Android before but for some reason, the app that I normally use to load APKs isn’t recognizing the file at all. I copied the APK into 3 different directories on my phone and it’s not recognizing the APK automatically or even if I manually navigate to the folder. I’m using “APK Installer” by “Mobile Manager” (this same app has been used before to side-load other stuff).
It’s not simply that there are too many restrictions. It’s that use of the API required to access the ambient light sensor is specifically restricted from being used in any app sold or given away in the app store (and there are no sane options for end-users to sideload). If you look at cross-platform general sensor-monitoring apps like Physics Toolbox, you’ll see they don’t support the light sensor on iOS while they do on Android.
As for the Play store, yes, I do plan to put it there eventually. It costs $25 to do so.
There are some iOS apps that try to detect light levels using the camera. As far as I can tell, that method would only be accurate with really low-level control over the camera that isn’t available on iOS. So, yes, one restriction is too many when it’s the core functionality of the app that’s restricted.
Been tinkering a bit with your app in my rooted good ol' Moto G 2013. Nice it is despite its simplicity, though I have to remember avoiding my usual screen auto-rotate setting because the app resets if the screen rotates, ?
I'm trying to get some valid throw values for a Sofirn C8T, the thing does up to 6+A at the tailcap, but I guess I need to make some more table room, it's a small spot at just 0.75m. Already got 102.4Kcd.
0K, here's the main question I came here for, ¿do you think a PWM detector functionality could be implemented in the app? I believe this can be possible by polling the light sensor at two non-multiple useful frequencies with custom selectable polling frequency up to whatever limit please (this is just in case we start polling at exactly the PWM frequency LoL!), looking up for noticeable variations in the measurements over a very brief lapse. Any non-PWM beam values would be nearly identical, and it would just take a second of polling or much less. Graph time of up to half or 1s would be plenty, I believe.
The maximum sample rate of the sensor on my Nexus 5 seems to be 0.2 seconds. That’s not a viable way to detect PWM.
What could work is to use the camera. At a high shutter speed with the electronic rolling shutters used in most smartphones, ripple and PWM look something like this. That kind of pattern should be detectable with an algorithm and it may even be possible to estimate frequency.
Thanks for the app. Just installed it on my Nexus 5X.
My biggest challenge is finding some known/verified lumen outputs for the flashlights that I own so that I can calibrate it. Is there a database of such info somewhere? I’ve been searching through various reviews on BLF and not getting what I need. Some of the common lights I own:
Seems the situation is pretty bleak. Even if you calibrate you can have factors of 3 errors across the dynamic range. And if you think establishing detailed calibration curves for various devices will help, nope.. they found no consistency across identical devices. I'd strongly suspect there are wild variations depending on the color distribution of the source too. Seems like these smartphone meters are kind of toys.