Introducing Ceilingbounce - flashlight testing and runtime graphs for Android

33 posts / 0 new
Last post

Pages

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390
Introducing Ceilingbounce - flashlight testing and runtime graphs for Android

https://github.com/zakwilson/ceilingbounce/releases/

This is a little rough and definitely expects the user to know a bit about both Android and photometrics. If sideloading and file managers are totally foreign concepts, it may not be ready for you just yet.

Please do read the README twice before asking for support.

Will code for food and/or lights.

Ceilingbounce – flashlight testing and runtime graphs for Android

Edited by: zak.wilson on 04/03/2017 - 15:21
zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

Thanks to reddit user kaybi_, I’ve fixed a bug that caused the UI to hang some time into a runtime graph. I’ve also reduced the sample rate, resulting in smaller CSV files.

This app makes it easy to see how your flashlight behaves under a variety of conditions. For example, here’s the intersection of a partly discharged and somewhat worn out 18650 and a timed stepdown.

Ceilingbounce – flashlight testing and runtime graphs for Android

tek-0
Offline
Last seen: 1 month 3 weeks ago
Joined: 03/29/2014 - 09:16
Posts: 22
Location: Finland

This is interesting. I’ve wondered in the past why an app like this doesn’t exist. Now it does, and seems to work fine. I just need to make some kind of light box for my phone. A film can would be handy mini integrating device, if it worked. The reading changes too much when I move it just a hair for it to be of much use. Anyway, I’ll be following any developments of this app.

Here’s a shot of it working in my, um, lab. (The light is Foursevens Atom, with almost empty battery)
postimage

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

I’m working on a way to do integration without any extra hardware, but no promises. I think a film can will act as a diffuser more than an integrator and is probably only good for runtime graphs. An update with improvements to graphing, especially over very long periods of time is coming soon.

Apps that display, graph and log outputs from all the sensors do exist. Physics Toolbox is my favorite of those.

Ceilingbounce – flashlight testing and runtime graphs for Android

DavidEF
DavidEF's picture
Offline
Last seen: 1 day 2 hours ago
Joined: 06/05/2014 - 06:00
Posts: 5093
Location: Salisbury, North Carolina, USA

Thanks for making this app. It should be quite useful.

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

djozz
djozz's picture
Offline
Last seen: 6 hours 14 min ago
Joined: 09/07/2012 - 17:04
Posts: 11011
Location: Amsterdam

This is a great initiative, despite the inaccuracies that (most, some are better than others) ambient light sensors have compared to good lux meters, as you say it is a great way to get a pretty good ballpark measurement of light output, with the added convenience of automatic runtime graphs being made (which is way ahead of my own medieval way of collecting data and making graphs)

When I have time I will try it all out. It looks like a great readme that you made.

(from the readme: “Is this app a flashlight? – NO! Stop using your phone as a flashlight. Why are you even here?” Party )

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

Eventually, I want to put together a website for people to share data so that runtime graphs and such are easy to find for most lights. Studying the accuracy of various phones’ light sensors would also be interesting. My regular phone is a Nexus 5, and somebody donated a Galaxy S3 to the project. The S3 reads significantly high with high-CRI Nichias I’ve tested, but the Nexus 5 is consistent with what I would expect given tests of those emitters with calibrated instruments. The S3 is almost 30% higher with a 219B R9080 when both phones are calibrated such that they read nearly identically with several unspecified-CRI Crees.

The other important issue I’ve noticed is that phone light sensors report some fraction or multiple of lux. My two phones are quite far from each other, but both appear to have a linear response such that with the same light, a mode that should be twice as bright according to independent tests with real meters reads twice as bright on the phone. That means that regardless of accuracy and calibration issues, it will produce runtime graphs with the right shape.

Ceilingbounce – flashlight testing and runtime graphs for Android

manithree
Offline
Last seen: 2 hours 1 min ago
Joined: 01/12/2013 - 01:08
Posts: 104
Location: Orem, UT

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.

And clojure! You must be one of the cool kids!

Thanks!

Tom E
Tom E's picture
Offline
Last seen: 10 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 10822
Location: LI NY

Nice! I just ordered a Pixel Google phone, so could try this out in a few weeks. Android is mostly all new to me though.

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

manithree wrote:
And clojure! You must be one of the cool kids!

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.

Ceilingbounce – flashlight testing and runtime graphs for Android

Chicken Drumstick
Offline
Last seen: 3 months 2 days ago
Joined: 08/27/2012 - 05:00
Posts: 2387
Location: UK

Cool idea. Any plans for an iPhone variant?

Tom E
Tom E's picture
Offline
Last seen: 10 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 10822
Location: LI NY

zak.wilson wrote:
manithree wrote:
And clojure! You must be one of the cool kids!
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 smilefrown. You do get better and better at getting it right the first time.

SoCalTiger
SoCalTiger's picture
Offline
Last seen: 12 hours 5 min ago
Joined: 03/16/2017 - 14:06
Posts: 392
Location: Southern California

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

Maybe I’ll just try another side loader.

This is on a Samsung S7 Edge.

SoCalTiger
SoCalTiger's picture
Offline
Last seen: 12 hours 5 min ago
Joined: 03/16/2017 - 14:06
Posts: 392
Location: Southern California

Okay, I just tried a different loader and it worked fine. Odd.

Tom E
Tom E's picture
Offline
Last seen: 10 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 10822
Location: LI NY

Chicken Drumstick wrote:
Cool idea. Any plans for an iPhone variant?

Already answered in the readme bout iOS. Simple answer is no, iOS and the store have too many restrictions.

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

Tom E wrote:

Chicken Drumstick wrote:
Cool idea. Any plans for an iPhone variant?

Already answered in the readme bout iOS. Simple answer is no, iOS and the store have too many restrictions.


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.

Ceilingbounce – flashlight testing and runtime graphs for Android

Tom E
Tom E's picture
Offline
Last seen: 10 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 10822
Location: LI NY

Well, just thought 1 restriction is one too many, that's why I included a link to your readme.

There are luxmeter apps on the App Store such as this one: https://itunes.apple.com/us/app/galactica-luxmeter/id666846635?mt=8

But maybe they have a different low level method? I see references stating they use the camera.

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

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.

Ceilingbounce – flashlight testing and runtime graphs for Android

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

Updated:

  • The sample rate is decreased to one sample per 10 seconds after 100 minutes to stay responsive in tests lasting many hours.
  • The PNG image of the graph doesn’t start writing until the background rendering is complete, because concurrency is hard.
  • The output graph is scaled appropriately regardless of the user panning or scaling the live graph.
  • A number pad is used instead of a generic keyboard for the calibration fields.

Ceilingbounce – flashlight testing and runtime graphs for Android

The Miller
The Miller's picture
Offline
Last seen: 3 days 14 hours ago
Joined: 12/14/2015 - 12:08
Posts: 9942
Location: Charente France

bump!
(so I can find it faster on the new phone and check it out for some Q8 runtime graphs
thanks for making it Zak!

Barkuti
Barkuti's picture
Offline
Last seen: 3 hours 25 min ago
Joined: 02/19/2014 - 14:46
Posts: 1905
Location: Alhama de Murcia, Spain

Hi Zak,

 

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. 

 

Cheers Party

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

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.

Ceilingbounce – flashlight testing and runtime graphs for Android

EagleShield
Offline
Last seen: 4 hours 29 min ago
Joined: 09/12/2017 - 19:34
Posts: 151
Location: Sweden

Sound like the flicker tester app from visosystems.

Link: http://www.visosystems.com/products/flicker-tester/

It says it’s for both android and iPhone but I can only make it to work on iPhones. On android I only get the “not enough light” message.

I have sent them a mail but got a message back that he won’t be at the office until sometime in December.

Would be great if you could figure out how they do for the iPhone app and try to replicate it to your app on android.

Barkuti
Barkuti's picture
Offline
Last seen: 3 hours 25 min ago
Joined: 02/19/2014 - 14:46
Posts: 1905
Location: Alhama de Murcia, Spain

Saw that post of yours yesterday, EagleShield. That is the reason I asked Zak, I thought it would be a nice addition to his application.

The Viso Systems Flicker Tester application is also not working on my Android, guess they definitively have bugs to sort out in it.

 

Cheers

P.S.: C8T runtime graph coming in.

Pete7874
Pete7874's picture
Offline
Last seen: 4 hours 15 min ago
Joined: 11/23/2011 - 16:47
Posts: 840
Location: USA

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:

Convoy S2+ 4×7135 3B XML2
Convoy S2+ 8×7135 3A XPL HI
DQG Tiny 4th NW
Jetbeam Jet-1 MK

Flintrock
Offline
Last seen: 2 min 51 sec ago
Joined: 09/10/2016 - 20:29
Posts: 1516

https://www.dial.de/en/blog/article/luxmeter-app-versus-measuring-deviceare-smartphones-suitable-for-measuring-illuminance/

 

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.

Flintrock
Offline
Last seen: 2 min 51 sec ago
Joined: 09/10/2016 - 20:29
Posts: 1516

Oh didn't notice the OP is the writer.  Ok great, maybe you can dispute that then?

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

I can’t dispute it. I have two smartphones and no real calibrated light sources. I have a couple lights that maukka also has, and maukka has a real integrating sphere.

I do note in the readme that “lux” readings from the phone’s light sensor are absolutely not lux. It is necessary to calibrate using lights with known lumen and candela values. No attempt is made to calibrate the raw sensor “lux” value to real lux, but I may add the ability. As the article notes, there’s no difference from one app to another in terms of the reported lux value; we all just report what the sensor says.

I wish the testers you linked had tried multiple samples of the same Android device like they did for iPhones. As the article notes, iPhone apps are using the camera rather than the light sensor because some jerk at Apple decided apps can’t use the light sensor. There’s bound to be some variation in that approach.

Somewhat problematic is that the test shows a non-linear ratio of lux to sensor values in all the devices tested. With most devices, it’s not huge, but the Samsung S5 at 500 lux is an exception. Everyone needs to test their own device with different lights on different modes for which there’s reasonably reliable data in order to have a reasonable calibration. If it jumps around as much as the S5, it may be impossible to calibrate accurately.

Ceilingbounce – flashlight testing and runtime graphs for Android

Scorpia
Offline
Last seen: 1 day 5 hours ago
Joined: 09/10/2016 - 17:41
Posts: 57
Location: Down Und3r

would it help you if the app users were able to submit different light source values to you some how?

I would think something along the lines of phone type. light value and light source, the light source would need to be entered manually?

i’m sure there would be a number of people on this board willing to test all there lights to create a sort of reference database

zak.wilson
Offline
Last seen: 2 days 21 hours ago
Joined: 09/29/2014 - 14:27
Posts: 390

I’m planning to make a database website and integrate it with the app. Just haven’t gotten to it.

Ceilingbounce – flashlight testing and runtime graphs for Android

Pete7874
Pete7874's picture
Offline
Last seen: 4 hours 15 min ago
Joined: 11/23/2011 - 16:47
Posts: 840
Location: USA

Scorpia wrote:
would it help you if the app users were able to submit different light source values to you some how?

I would think something along the lines of phone type. light value and light source, the light source would need to be entered manually?


For this to be even remotely comparable, wouldn’t it require that everyone uses the same measuring environment/integrating device?

If my shoebox is different from your shoebox… Smile

Pages