Re: ROHM ALS, integration time

["Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>]

On 1/30/23 15:02, Jonathan Cameron wrote:
> On Mon, 30 Jan 2023 14:04:53 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:

>> However, the values
>> spilled from raw IIO_INTENSITY channels will change when integration
>> time is changed. So, should I use the info_mask_shared_by_type =
>> BIT(IIO_CHAN_INFO_INT_TIME) for IIO_INTENSITY channels?
> 
> Ah. This problem. The mixture of two things that effectively map to scaling
> of raw channels. As _scale must be applied by userspace to the _raw channel
> that has to reflect both the result of integration time and a front end amplifier
> and is the control typical userspace expects to use to vary the sensitivity.
> 
> That makes it messy because it's not always totally obvious whether, when
> trying to increase sensitivity, it is better to increase sample time or gain.
> Usually you do sample time first as that tends to reduce noise and for light
> sensors we rarely need particular quick answers.
> 
> So in the interests of keeping things easy to understand for userspace code
> you would need to provide writeable _scale that then attempts to find the
> best combination of amplifier gain and sampling time.

There is (at least) one more thing which I just noticed when I continued 
writing the code.

Changing the integration time impacts all intensity channels. So, scale 
will be adjusted for all channels when a request to set scale for one 
channel causes integration time to change. (Gain on the other hand is 
adjustable separately for each channel.) Do you think a typical 
user-space application can cope with this?

I am unsure if I should just use the biggest integration time (400mS) by 
default and only decrease this when very small amplification is 
requested by setting scale > 1. TBH, I don't like this. It prevents 
having shorter measurement times with gains greater than 1x - and I 
believe that users may want to have higher gains also in cases where 
they wish quicker measurements from the sensor.

Some other options I am considering:
1. Skip time config for now - easiest but does not give full usability
2. Allow setting the time via devicetree at probe time - slightly better 
but not very dynamic.
3. Custom device-specific sysfs file for setting the time so 
specifically tailored userland apps have access to it - adding new ABI 
for this is probably not something we prefer ;)
4. Allow setting the integration time in situations where the driver can 
internally hide the scale change by changing the gain as well - this 
operation is not atomic in the HW and adds some extra complexity to the 
driver. Also, this fails for configurations where the gain setting is 
such it can't compensate the scale change.

I would be grateful for any suggestions :)

Finally, the BU27034 allows pretty big gains - from 1x to 4096x. After a 
quick look in existing light sensor drivers - I think the available 
scales for IIO_INTENSITY channels are usually from 1.0 downwards. ("1.0 
0.xxx 0.yyy 0.zzz"). 4096x (or 32768x if we take the max measurement 
time into account) will cause some loss of accuracy even with NANO scale 
if we use scale range starting from 1.0. Is there anything that prevents 
starting the available scales for example from 16.0 ending 976562.5 
NANOs (to decrease loss of precision assuming both the full gain range 
and all timing values [except the 5 mS] are supported)? At least I 
didn't see any limitations in the sysfs-bus-iio ;) My guess is the 
userspace usually handles the integer portion of scale just fine(?)

Oh, by the way - I found a publicly available data-sheet for the ALS 
sensor I am working with. :)

https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/light/bu27034nuc-e.pdf

Seems like no public datasheet for the other sensors I mentioned though :(

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

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~