> >> such it can't compensate the scale change.
>
> I started with the option 4) and wrote first 100% untested code draft. I
> don't yet have the hardware at my hands so testing and fine-tuning needs
> to wait for a while.
>
> I wonder if I should send out an RFC to explain what I was up-to, or if
> I should wait for the hardware, do testing and only send out the patches
> when I believe things work as intended :)
>
> Sending RFC early-on would perhaps be beneficial for me as it can help
> me avoid working/finalizing a solution that will not be appreciated ;)
>
> Yet, sending out and RFC with untested code may result reviewers (who
> skip the "small print" explaining the code is untested and to be
> reviewed for a concept only) to do unnecessary work. And in my
> experience, no letters are large enough that all reviewers didn't skip
> the resulting "small print" :)
Who would ever do that? *evil laugh*
RFC is fine. If people spend time reviewing without checking 'why it is
an RFC' it is their own fault. This is one reason I moan about any RFC
I see without the reasons being clearly called otu.
>
> >
> > So we have had a few examples that might apply here (can't remember if
> > any of them actually got implemented).
> >
> > My aim would be to have the normal ABI do the right thing, but...
> > If we were to provide extra ABI that allows switching out of a default
> > mode then we can assume the code using it knows what it is doing.
>
> Hm. Maybe it's because all the virtual waffles and beer (last weekend
> was FOSDEM weekend - but I was participating only remotely) - but I am
> not 100% sure I know what you mean by the default mode.
Have the driver do 'best effort' on scaling etc with default being that
it doesn't care about time to take a reading. But have ABI that allows
an override. Normal user would never use the override but would get something
reasonable. Advanced user can mess with the settings if they want to.
>
> > So maybe something like
> >
> > auto_integration_time_from_scale that defaults to 1/true.
> > When 0/false,
> > integration_time becomes writeable. If you write integration time
> > it would then affect scale appropriately and any change to scale
> > would be clamped within whatever range is possible for the integration
> > time provided.
>
> Hm. Does this mean that writing the integration time would
> 1) Change integration time in HW
> 2) Not change gain in HW
> 3) Change integration time and scale values in sysfs?
Yes. If this magic mode bit was set.
>
> My current attempt if to not provide the 'mode' change flag - but
> provide R/W integration time and R/W scale.
That's best place to start I think.
>
> Regarding the scale:
>
> When scale is changed by user, the driver attempts to maintain
> integration time and perform only the gain change. If requested scale
> can not be supported by any available gain using the current integration
> time, then the driver attempts to change both the gain and integration
> time to achieve requested scale. (If this also fails, then an error is
> returned).
>
> I guess this is what is expected to happen in "normal mode".
Interesting. I was actually thinking prefer to change integration time
but your way may make more sense.
>
> As I mentioned earlier, this does not allow a great control over the
> integration time for users who (may?) wish to have shorter time with
> gain bigger than 1x.
>
> Hence the writeable integration time.
> Now, an user may request different integration time by writing the
> integration time. I assumed this is also normal operation assuming this
> does not cause a scale change?
If magic mode write hasn't happened, then integration time should reject
writes. Interface is too complex otherwise because if a user writes the
integration time then the scale, they'll expect that their integration
time has not changed.
If you ever used a film camera, kind of equivalent of switching between
an auto mode where the camera could adjust aperture (gain) and shutter
timing (integration time) to a shutter priority mode in which the
shutter timing (integration time) remains what you set it to and the
scale can only be adjusted in a fashion that doesn't change it.
> Hence, my current attempt is to
> compensate the caused scale change by adjusting also gain. It appears to
> me (based on the equation from my HW colleagues) that the doubled
> integration time also doubles the reported intensity value. I think this
> is also expected. For example: Let's assume a case where we originally have
> gain 8x, int-time 400 mS
Yes. That's what I'd expect for a light sensor that was fairly linear.
>
> user wants to set new int-time 200 mS.
>
> Halving the measurement time would mean halving the reported intensity
> values, causeing the scale to change, right? Now, in order to maintain
> the scale, the driver would be not only dropping the integration time
> but also internally doubling the gain from 8x to 16x.
yes.
>
> >
> > If you want to write an auto tuning routine you could do that and mostly
> > avoid the problem.
> > We have a few drivers doing that IIRC.
>
> Hm. Yes, it must be the virtual waffles :) I am unsure what you mean by
> autotuning. Do you mean increasing the gain/integration time in driver
> based on the raw-data to ensure values are as accurate as possible w/o
> being saturated?
yup. Then return a _processed value that incorporates the autotuned
scale. If _scale and _integration_time are then provided they are
for info only and not guaranteed to be the values used to grab the reading.
>
> The only signal userspace
> > normally cares about is illuminance and hopefully the calculations
> > take the different settings into account. I never much liked
> > the cases we have of this but there are a few e.g. gp2ap020a00f
> > In my view that should be a userspace problem as the algorithms to
> > tune this could be quite complex.
> >
>
> This definitely sounds like a computation better done in user-space to
> me. I had hard enough time writing a simple lux-calculation in my driver
> resulting bunch of overflow-checks and do_div()s... Luckily the
> performance was not a priority.
It's 'fun' but we have had people do it. I never bothered for the light
sensor I wrote a long time back (which got dropped eventually)
>
> >>
> >> 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.
> >
> > *sigh* someone implemented an insane gain because they happened to be able
> > to. I'd imagine that adds so much noise to be effectively pointless.
> > That dynamic range seems unlikely to be of much practical use.
>
> I can't say anything to this as I don't have the sensor yet :)
>
> >>
> >> 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 easy to agree after only a very brief look on the topic :)
One of those areas of technology where things aren't easily controlled or
well behaved!
J
>
> Yours,
> -- Matti
>
