Re: ROHM ALS, integration time

[Matti Vaittinen <mazziesaccount@gmail.com>]

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@gmail.com> 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! ~~