On 2/27/23 09:22, Matti Vaittinen wrote:
On 2/26/23 19:30, Jonathan Cameron wrote:
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:
Hmm. There is another approach that I'd not thought of in this case
because
in my head integration time is more continuous than it is for this
part and
that is to fiddle the _raw values (we do this for oversampling or SAR
ADCs
where things tend to be powers of 2). The trick is to shift the raw
value
always so that the 'scale' due to (in this case) integration time remains
constant. That separates the two controls completely.
Holy cow! That's a neat trick which I didn't think of!
Basically, we could do >> 1 for the data when time is 100 mS, >> 2 when
200 mS and >> 3 when 400 mS. We would want to use 19-bit channel values
then.
Please ignore my previous mail. It seems I am once again not knowing
what I am talking about. If we take this approach, we shift << 3 when
int time is 55, << 2 for 100 and << 1 for 200. With 400 mS we would not
shift.
However, I'm not sure that makes sense here where the thing we typically
want to change when scaling due to saturation is integration time.
That's a bit problematic, yes. We could "fool" the user by doing the
saturation check in driver, and then just returning the max value of all
19-bits set if the saturation is detected. This, however, would yield
raw values that are slightly off. OTOH, with max sift of 3 bits that's
only 7 'raw ticks' - which I hope is acceptable. I hope the user will
then be switching to shorter integration time and start getting correct
readings.
It's slightly sad to say "good bye" to the gain-time-scale helpers but I
guess you just helped me to solve this with a _really_ simple way. We
can keep those helpers in "back pocket" for the day when we need them ;)
I will see what comes out of this idea - thanks for the help again!
But as you surely knew from the start, the saturation problems kick in
with the 'non maximum sifts' when the _highest_ bits never get set.
There the 'saturation detection' would cause a huge jump by suddenly
setting the high bits. So, yes - this does not seem like a feasible
option here :/
/me feels stupid...
Sorry for the noise!
--Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
