сб, 22 лют. 2025 р. о 14:05 Jonathan Cameron <jic23@xxxxxxxxxx> пише: > > On Mon, 17 Feb 2025 16:32:33 +0200 > Svyatoslav Ryhel <clamor95@xxxxxxxxx> wrote: > > > пн, 17 лют. 2025 р. о 16:24 Jonathan Cameron <jic23@xxxxxxxxxx> пише: > > > > > > > > > Hi, > > > > > > > > > +static int al3000a_read_raw(struct iio_dev *indio_dev, > > > > > > + struct iio_chan_spec const *chan, int *val, > > > > > > + int *val2, long mask) > > > > > > +{ > > > > > > + struct al3000a_data *data = iio_priv(indio_dev); > > > > > > + int ret, gain; > > > > > > + > > > > > > + switch (mask) { > > > > > > + case IIO_CHAN_INFO_RAW: > > > > > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain); > > > > > > + if (ret < 0) > > > > > > + return ret; > > > > > > + > > > > > > + *val = lux_table[gain & AL3000A_GAIN_MASK]; > > > > > > > > > > I may have misinterpreted the other thread. IS this value in lux? > > > > > If it is make this channel IIO_CHAN_INFO_PROCESSED instead. > > > > > > > > > > > > > This is actually a really good hint, I will check if this works out > > > > and if yes, then definitely will use it. Thank you. > > > > > > From your other reply it seems we have no idea of the correct scaling. > > > If that is the case, then channel type should be IIO_INTENSITY as > > > I assume we also have no idea if the light sensitivity curve is > > > matched to that required for illuminance (which approximates the > > > sensitivity of the human eye). Various datasheets provide completely > > > garbage conversion formulas btw so even if we have data this can > > > be problematic. One recent sensor was using a green filter and > > > saying illuminance in lux was 1.2 * green which was assuming their > > > own definition of white light. > > > > > > Jonathan > > > > > > > Then why IIO_LIGHT exists at all? If you state that datasheets provide > > garbage formulas and sensors cannot be trusted and all is around human > > eye, then why IIO_LIGHT is still the case? I did not recall any > > drivers for human eyes (thank god). Please be more consistent. Thank > > It exists because some sensors do this correctly, or at least a good > approximation to the standard sensitivity curves. This is done two > ways. > > 1. Good light frequency filtering in front of the sensor to compensate > for the difference in sensitivity between the measuring element > and that the standard curves. CIE1931 (there are a few other standards > but they are close enough that we don't care). > https://en.wikipedia.org/wiki/Illuminance > 2. Multiple sensing elements. A common reason for this is to remove > bit of infrared that we don't want. Often the calculation is a > non linear combination of the various sensor outputs. Such a driver > usually presents several IIO_INTENSITY channels and a calculated > IIO_LIGHT channel. > > In both cases the datasheet tends to include a comparison the the > CIE1931 etc standards. There will be small differences but that is > very different from taking a sensor that is only sensitive to green > and weighting it which is the example I gave above. > > These sensors will compensate for the different sensivity > of the human eye to different wavelengths. E.g. if you > think blue and green light LEDs have the same brightness then > the sensor will give close to the same output. > > Anyhow, light sensors are a hole I have gone far too deep in over > the years. Key is some manufacturers provide insufficient information > or take the view it is a problem for the integrator of the sensor > to deal with. For those we do not pretend to know the answer and > use intensity channels instead. > This is quite an explicit explanation. Thank you. > Jonathan > > > > you > > >