The number shown on the graph tab is the raw reading from the sensor, not calibrated. The graph itself is a percentage relative to the reading at 30 seconds.
That’s what I figured thanks
It took way too long for me to figure this out. It’s ok that it doesn’t show lumens in the runtime tab. You just divide the number by your ratio number (mine is 4), and that is the lumens
There’s a lot I’d like to update, but the dev tools it uses are abandoned and bit-rotted to the point that I haven’t been able to compile new releases for years. To make matters worse, it seems like a lot of newer smartphone light sensors will only update when there’s a large change in the reading, making them unsuitable for this kind of use unless there’s some trick available to force updates.
I was in no way complaining. It’s just fine as it is for me anyway. I don’t mind doing simple math. I was just surprised it took me far too long to put the two into together. Getting this app and a light box is probably my greatest flashlight upgrade in 2023. I now know what my lights are putting out instead of guessing based on emitter tests and guesses about light losses. Does this information actually matter? No, not really. But it’s fun.
I cannot install ceiling boince on my Samsung A52S and Zfold 4, both with android 14 because aplication is not compatible with this new anroid.
If someone know way how to install it please help?!
Does some alternative aplication with similar function exist?
You should be able to install it by plugging into a PC with Android dev tools and running
adb install --bypass-low-target-sdk-block APKNAME.apk
There are a variety of other tools that can record data from phone sensors; Phybox is one.
Thanks for the explanation and tip.
I have used ceilingbounce on my old phone but its screen failed.
New release 0.3.0!
No more ADB install for newer devices, several new features, and more releases coming soon.
Wow! Greats news!
I’d to play with phyphox app to do some tests and it was quite painful ![]()
A commenter elsewhere is getting crashes on starting a runtime test. If anybody who knows what adb logcat is for experiences that, I’d appreciate a stacktrace as I’ve been unable to reproduce.
it might require permissions to access storage? mine crashes on the runtime test as well. 1 sec, lemme disable some stuff
**“ceiling bounce closed because this app has a bug”.
I tried disabling Samsung’s autoblocker, no good, lol.
***Just thought of something, @zak.wilson
Is it possible that the app doesn’t automagically populate the extension type, leading to an error when writing?
I thought maybe at least there would be a corrupted file or something in the directory I wanted them saved to, but the folder was empty
Zak be like…
- announces a new version
- doesn’t even mention he had to port an entire programming language to the current Android APIs first
What a legend.
It gets permission when you pick the storage directory. It should detect when something has gone wrong with that and show a popup message, and I’ve tested that by putting a debug build into invalid states like using a directory the user didn’t actually select.
File extensions are optional on Android and not the standard way that it gets file type information, but it definitely gives the files it writes extensions (.csv and .png).
I think it’s more likely to fail to write at all than to write a corrupt or incomplete file.
doesn’t even mention he had to port an entire programming language to the current Android APIs first
Well I did mention that before as a reason there were no updates.
It would have been less work to port it to another language, but now I get to make another announcement in another forum this week and I hope it will bring people some joy.
I’ve the same issue with storage, but in my case it crashes when I try to select directory in settings. Permission to local storage is granted.
When error appeared I click “send” so maybe Zak will receive some logs - I don’t know really how it works ![]()
The idea I had in mind long ago was to use the phone’s accelerometer to trace its path as the user stepped back from the position of the flashlight and moved the phone through the light beam. I’ve done the positioning part of that experiment now and I don’t think it’s possible to achieve enough precision or accuracy to be useful.
I did a thing, I manually created a new folder in that directory through the CB app rather than allowing “loose” files to populate in the selected directory.
Looks like there’s some correlation there?
**it’s working as intended now.
I have tested selecting a pre-existing directory created by another app and did not get a crash that way on either device I’ve been testing on.
let me do a reinstall after deleting any associated folders…BRB
Initially, it worked for one or two tests with the above message, but then subsequent tests crash the program. I went ahead and cleared the cache for that program, and was able to consistently run 10+ tests.
I closed out of the program, then relaunched it, same issue with crashing. I went and re-established the directory to allow permissions again, and it works fine again. **I did this multiple times to be sure
Maybe the “resource saving” or “security” features on android, such as “revoke permissions when not in use” are interfering with persistent access permissions of the app?
**BRB again, I’m going to test allowing it to have permissions exceptions
***so I’m back, Allowing memory residence and exclusion from permission revoke does not work, but reselecting the particular storage directory to allow access fixes it, but pops up that java.lang.null warning
