On Sat, 18 Feb 2023 20:08:10 +0200 Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote: > Thanks a lot Jonathan, > > You have been super helpful :) Thanks! > > On 2/18/23 19:20, Jonathan Cameron wrote: > >>>> such it can't compensate the scale change. > >> > >> 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. > > I agree that changing the integration time set by the user could be > unexpected. OTOH, if we take the approach I explained above (Eg. try > keeping integration time intact when scale is changed and only change > int-time if gain alone can't provide requested scale), then the > integration time would not change is user asks for scale we can support > with the set integration time. > > There is few bumps on the road though... I am not exactly sure how to > decide available scales to advertise. Nor am I sure how to deal with the > scale settings when requested scale can't be met with gain change alone > but where scale is also not at the one of the extreme ends (which could > clearly warrant the integration time change) - but is somewhere in the > mid-range. This can happen because the supported gains have "jumps". 1x > to 4x (skipping 2x), to 16x (skipping 8x) to 32, 64, and then to 256 > (skip 128), 512, 1024, 2048 and 4096. > > Integration times are 50, 100, 200, 400 - which means that some of the > 'mid range' scales can be only supported by some integration times. Tricky corner indeed. I'd be tempted to say don't always give people what they request. Generally speaking (ignore the complexity of your case) the aim is to increase scale to the maximum that can be done without saturating for the range people care about. It is rarely a problem if we undershoot a little in order to map to something that works on the hardware. That freedom might help you a little in this case. > > I will try to cook an RFC next week to show what I have drafted if there > is no big surprizes on the road.. > > Yours, > -- Matti >
