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

[Jonathan Cameron <jic23@kernel.org>]

On Sat, 25 Feb 2023 11:35:14 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> 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:

That is indeed typical info to find on a datasheet though IIRC the
y axis meaning varies a bit (log values sometimes for example)

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

Can't abandon them in general as ABI we need to carry on supporting and
in many cases that's enough info for the application.  Can expand beyond
them though.

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

A more general approach would be to mandate the curve fitting then require
drivers to provide sufficient values that the approximation is within
X percent of the value from the datasheet.

Otherwise it becomes a question of what wavelengths to use.
> 
> 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).

They are fun. I'll admit my main experience of these has come with devices
that 'happen to have them' rather than ever having designed them into
anything (and last actual board design I got involved in was many years
ago).

> 
> 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?

As you've noted, 3DB doesn't work for this, but I think remains
useful for time domain filters. 

I think it would potentially be useful to have better data, but what
we really need is a user to tell use what they need.

Until that happens we may well be either over or under designing
the solution.

Jonathan
 
> 
> Yours,
> 	-- Matti
>