On 2/6/23 16:34, Vaittinen, Matti wrote:
On 2/2/23 18:57, Jonathan Cameron wrote:
On Tue, 31 Jan 2023 09:31:53 +0000
"Vaittinen, Matti" <Matti.Vaittinen@xxxxxxxxxxxxxxxxx> wrote:
On 1/30/23 15:02, Jonathan Cameron wrote:
On Mon, 30 Jan 2023 14:04:53 +0200
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
As a side note - I had always thought measuring the light is just simple
value reading from a sensor. I never regarded the fact that human eye
sees only certain wavelengths or that the sensors sensitivity changes
depending on the wavelength. It's funny how I always end up knowing less
when I know more ;)
Light sensors are a pain in many ways! We've had a few datasheets over the
years that have insisted that the color channels have well specified units
despite there being no such definition that I'm aware of (and no means
to define one for cheap sensors. What is standard Red? :)) All the
illuminance values are just approximations to the official curve.
Sometime in the past we debated trying to describe the curves, but it's
hard to do as they aren't nice shapes (so 3DB points don't make much
sense).
This is a low-priority mail with just some very initial pondering. Feel
free to skip this if you're in a hurry.
I guess the problem of telling what the sensor values represent for
sensors where the sensitivity is a poor match to a colour has been
dwelling in the background :)
I don't have any long experience on these devices so I have seen only
couple of the light sensor data-sheets, and mostly just for ROHM
sensors. Maybe this is the reason why the common thing I have seen in
these data-sheets representing the sensitivity to wave lengths has been
a "spectral response" curve. All of the data-sheets have represented a
curve where "sensor responsivity" is in the Y-Axis and wave length at
the X-axis. And yes, in many cases this curve (especially for a CLEAR
light) is of arbitrary shape for example like this:
S ***
e * *
n * *
s ** * *
i * ** * *
t * * *
i * *
v * *
i ** *
t * *
y * *
* ***
* ******
* *
* *
400 500 600 700 800nm
W a v e l e n g h t
Having this in mind it seems to be impossible to have just one or a few
categories of sensitivity, or to describe it accurately by just some
"peak-sensitivity" wave-lenght and a value representing "width of the
curve".
So, maybe we should abandon the idea of having a great categorization /
abstraction in-driver or IIO framework (other than the R,G,B,C,IR,UV -
which works fine for some sensors). What I could think of is providing a
set of 'data points' representing the sensitivity curves. Say, we had
in_sensitivity_wavelength_calibpoints and
in_sensitivity_wavelength_num_calibpoints (or what ever could fit for
the IIO naming scheme) - where user could get sensor provided datapoints
that represent the sensitivity as a function of wavelength. Userland
could then decide the best curve fitting for the data-points and compute
the sensitivity according to the best available algorithms. I think this
kind of curve-fitting-to-datapoints is quite standard stuff in the
user-space these days - but it feels like an overwhelming task in the
kernel land/drivers...
This all is just some pondering. I do not have a proper use-case for
this kind of a sensitivity curve data as I work for a component vendor
instead of doing actual systems utilizing these components :/ It's
actually a little sad as I seem to keep thinking what kind of a device I
could build using these components - just to end up noticing that I am
not in a position where I was building these devices :p (You wouldn't
believe how cool imaginary clocking device for driving a camera clock
with light sensor detecting flickering I just designed in my head the
other night XD).
Well, I still hope I can help creating device driver/framework stuff
people can use to build devices - in the end of the day it will also
benefit the component vendor as the components are typically used in
these devices ;)
Oh. Got carried away. Anyways, have you considered just offering an
entry with sensitivity data-points instead of offering wavelength and
3DB-limits? Do you think that could be useful?
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
