[low prio, just pondering] About the light sensor "sensitivity area"

[Matti Vaittinen <mazziesaccount@gmail.com>]

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@fi.rohmeurope.com> wrote:
>>
>>> On 1/30/23 15:02, Jonathan Cameron wrote:
>>>> On Mon, 30 Jan 2023 14:04:53 +0200
>>>> Matti Vaittinen <mazziesaccount@gmail.com> 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! ~~