Re: [PATCH v5 6/6] iio: adc: ad4851: add ad485x driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/9/24 9:39 AM, Jonathan Cameron wrote:
> On Thu, 7 Nov 2024 10:47:52 -0600
> David Lechner <dlechner@xxxxxxxxxxxx> wrote:
> 
>> On 11/7/24 10:13 AM, David Lechner wrote:
>>> On 11/7/24 4:51 AM, Miclaus, Antoniu wrote:  
>>
>>
>>>>> I'm pretty sure that calibscale and calibbias also need to take into
>>>>> account if resolution boost is enabled or not.  
>>>>
>>>> Can you please detail a bit on this topic? I am not sure what I should do.
>>>>  
>>>
>>> We haven't implemented oversampling yet in ad4695 yet, so I don't know
>>> exactly what we need to do either. ;-)
>>>
>>> But this is how I would test it to see if it is working correctly or
>>> not. We will need to test this with a 20-bit chip since that is the
>>> only one that will change the _scale attribute when oversampling is
>>> enabled.
>>>
>>> First, with oversampling disabled (_oversampling_ratio = 1), generate
>>> a constant voltage of 1V for the input. Read the _raw attribute. Let's
>>> call this value raw0. Read the _scale attribute, call it scale0 and
>>> the _offset attribute, call it offset0.
>>>
>>> Then we should have (raw0 + offset0) * scale0 = 1000 mV (+/- some
>>> noise).
>>>
>>> Then change the offset calibrate to 100 mV. To do this, we reverse
>>> the calculation 100 mV / scale0 = calibbias (raw units). Write the
>>> raw value to the _calibbias attribute. Then read the _raw
>>> attribute again, call it raw0_with_calibbias.
>>>
>>> This time, we should have (raw0_with_calibbias + offset0) * scale0
>>> = 1100 mV (+/- some noise).
>>>
>>> Then set _calibbias back to 0 and repeat the above by setting the
>>> _calibscale attribute to 0.90909 (this is 1 / 1.1, which should  
>>

After a bit more testing, I realized I was testing with a
differential channel, this math only applies to that.

For a single ended channel, applying a calibscale of 1.1 with
a generated signal of 1V will cause the measured value to change
from 1V to 1.1V as one might expect.


>> Now that I have written this, this has me second-guessing if I
>> implemented calibscale correctly on ad4695. It would seem more
>> logical that if we have an actual input voltage of 1 V and a
>> calibscale of 1.1, then the resulting processed value we read
>> should be 1100 mV.
>>
>> Jonathan, can you set me straight? The sysfs ABI docs aren't
>> clear on this point.
> 
> Deliberately vague in this case.  calibbias is kind of the wild west
> of ABI. Often we have no meaningful information on what the tweak
> register settings actually do beyond 'up vs down'.  In some cases
> the datasheets even refer to them as taps up or taps down.
> 
> I don't think we've ever said if it should be consistent as you
> change other parameters.  If you care about calibration you probably
> need to redo it for your new settings anyway and tweak the calibbias
> /calibscale till it gives the right values.
> 
> Obviously that is easier to do if you have a consistent scheme for
> a given device and if possible allow calibrating at just one setting
> but I don't think we can apply general rules.
> 

Thanks for the clarification.

> Jonathan
> 
>>
>>> add 10% to the measured raw value). Read, the _raw attribute again,
>>> call it raw0_with_caliscale.
>>>
>>> This time, we should have (raw0_with_caliscale + offset0) * scale0
>>> = 1100 mV (+/- some noise).
>>>
>>> Set _calibscale back to 0. Then set _oversampling_ratio to 2. Read
>>> _scale and _offset again, call these scale1 and offset1.
>>>
>>> Then repeat the steps above using scale1 and offset1 in the
>>> calculations. The raw values will be different but the resulting
>>> processed values (mV) should all be the same if the attributes
>>> are implemented correctly.
>>>   
> 





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux