I think I’ve tracked down the problem, and I’m testing a new release candidate.
3 Thanks
For reflector lights, a single intensity measurement (L) at the edge of the spill (with fixed measurement distance to the wall, say 1m), plus a single piece of geometry data, the spill angle (2θ), is enough information to calculate the total output. This is simply due to the fact that at this location of measurement, the light is indistinguishable from a bare Lambertian emitter, whose beam profile is well-understood.
For a non-reflector light that still has a radially symmetric beam, how about the following modification of your idea:
Have the user point the light at a straight wall, and identify a diameter of the light beam. Then, grab the phone, walk to the wall, and sweep the phone’s sensor along said diameter to capture the intensity profile along this diameter. The phone’s accelerometer can possibly detect any unevenness in the user’s motion to rescale accordingly, and the user can enter a manual measurement of the diameter to aid scaling. Then the phone performs integration of this intensity profile, scaled by radius, to estimate the total output.
I imagine that a long measurement distance (say on the order of several meters, longer for throwers) might give the phone more distance to travel along this diameter, and overcome unevenness in motion to produce a more accurate estimate.
My Phyphox app has both an accelerometer and a light intensity meter, so I might try this myself.
Based on my testing, the phone’s accelerometer cannot do that accurately enough to be useful.
I see, the accelerometer is the weak link. Would it be feasible for the user to record intensities at finely discretized intervals (say every 10cm), and record those to avoid using the accelerometer to estimate distance?
For reflector lights, I think the idea of using a single intensity measurement and spill angle to estimate output could work, I will write up a separate post on it later today.
New release Release Ceilingbounce 0.3.1 · zakwilson/ceilingbounce · GitHub
I think this will fix the crashes. Try a runtime graph without first updating the storage directory; it should prompt you if the problem is what I think it was.
4 Thanks
just launched, ran, and closed the app multiple times, your fix seems to have fixed it. Thanks Zak!
**now if only you could fix android’s screen autobrightness glitch where the on-screen font seems to trick the sensor to staying bright, lol…but that’s not you, that’s android being dumb I think
I could give it an even darker theme. It forces a black background regardless of the user’s chosen theme for a reason.
1 Thank
on my phone specifically, I think the light sensor is in some stupid spot below the screen and general sensors bar…I’ll take a screenshot and mark it, one sec…
somewhere in the red circle, Between the “NT” in runtime and the purple underscore bar, so any increase in the peripheral pixels above a certain threshold keeps the screen at or near maximum lol.
It’s probably not far from there on my main phone, but that phone has other issues that make it a poor choice for using the light sensor. I use an old, mostly broken Nexus 5 for runtime graphs. I had to find a newer ROM for it because Ceilingbounce now requires Android 8 or above.
5 Thanks
3 Thanks
I’ve restarted phone to factory defaults and now selecting directory works. Eh these phones 
Now I’m testing some strobe modes how long it lasts and I’ve question how measurement stops at runtime test? When I put low value to 0 it has some delay to stop? Now I am testing and looks fine, but when time between blinks will be too long it can trigger stop test? Thanks!
BTW, if you’re testing runtime on an Anduril light’s strobe mode, be warned… it doesn’t have thermal regulation in strobe modes. So it could overheat. Would not recommend doing this without good cooling… and maybe not at all. It’s meant only for short bursts while held in a hand so it won’t overheat, and if it did, you’d be able to feel the heat and turn it off.
2 Thanks
Thanks for info! I’ll keep it in mind - it would be great not to burn light
Currently I’m testing Sofirn ST10, because its red strobe is sooo high that lasts only few hours. It gets quite warm, but fortunately not hot. Also it is quite interesting if they implemented thermal regulation on strobes…
I have my stop at 10, it takes around 5 seconds to actually auto-stop
1 Thank
It’s 5 seconds on a short graph and 50 seconds on a long one, where long is more than 5000 seconds.
The actual logic is that it stops if 5 readings in a row are under the threshold, otherwise the low voltage blinks many lights have would stop the test early. The sample interval is once a second until 5000 seconds, then it’s once per ten seconds. Reducing the rate is necessary because the graph library gets slow with tens of thousands of data points, at least on old devices. The previous one would freeze the UI thread and never save a graph, which is worse.
I should probably revise it to a variable interval.
2 Thanks
Many thanks for precise info! For most blink modes it will be will be more than enough.
1 Thank
Smart! accounts for the active blinky modes as well, like SOS and most beacons. I havent tested, but some older beacons do 10 second intervals, like 4sevens.
It’s not likely to produce good results with slow blinking modes with the current polling mechanism. It wouldn’t be hard to change to a reactive update-on-change design, but it might need some filtering if the signal is noisy over a long runtime test.
1 Thank
Trying to use this on a Sony Xperia one, the polling rate seems quite low as compared to my Samsung.
I’ve tried a runtime test to compare on a baton 4 pro, with the Samsung it can see the output dropping second by second, but with the Sony it’s a solid line for over a minute without dropping by a single lumen.
Any ideas?
It’s probably a limitation of the sensor. Older phones used sensors with a fairly high resolution, because that’s what was available. But meanwhile they switched to rather limited sensors, able to tell “dark or bright”. Some phones even use the front camera, apparently.