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