Re: IIO: Interface for capacitance inputs (and outputs)

[Jonathan Cameron <jic23@cam.ac.uk>]

On 08/02/11 15:58, Michael Hennerich wrote:
> On 08/02/2011 11:06 AM, Jonathan Cameron wrote:
>> On 08/02/11 09:11, Michael Hennerich wrote:
>>> On 08/01/2011 07:21 PM, Jonathan Cameron wrote:
>>>> Hi Michael / All,
>>>>
>>>> We have a quite a few capacitance drivers. They are all simple and=
 so
>>>> would be easy to clean up, except for the fact that we don't have =
an abi
>>>> for them.
>>>>
>>>> So lets make one up. How about the following?  Main choice is the =
units...
>>>> Doing it with Farads leaves us with a lot of needed decimal places=
, but then
>>>> we need a lot anyway for these so what the heck.  We are going to =
need those
>>>> types with holes in them..
>>> Hi Jonathan,
>>>
>>> These devices typically feature an single digit pF input range(2..8=
 pF).
>>> Going with a scale in Farads is probably not going to work.
>>> What do you mean by types with holes in them?
>> IIO_VAL_INT_PLUS_FEMTO where FEMTO bit has maximum of 999999999  Thu=
s there are quite a
>> few leading zeros.
> The part has a full range of +/- 4.096pf and it is a 24-bit converter=
=2E
> We like to store the conversion result as 3-byte direct readings from=
 the device result register.
>=20
> Thus the Farad scale would need to be
> 8.192E-12 / 2^24 =3D 4.8828125E-19 =3D 0.00000000000000000048828125.
>=20
> I don't think this makes any sense?
It's certainly uggly.
>=20
>>> We need something scanf() and friends can eat...
>> Yup.
>>> In addition we have enough scale bits before the decimal point as w=
ell.
>> Please give an example why. Do we have a calibscale type attribute h=
ere?
> I don't understand, why calibscale would matter here?
Because it's the only item I can think of where a value of=20
0.99999999999999999999999999999999999992 would make sense and that's th=
e one
nasty case that requires a 'lot' of digits to represent currently).
>=20
> But sure we have a in_capacitanceY_scale.
> If we say the in_capacitanceY_scale targets pF.
>=20
> Then we still need enough fractional digits, due to the 24-bit nature=
 of the device.
Sure, it's a large number of digits. I'm increasingly wondering if we m=
ove everything to
64 bit just to give us the space. This stuff is all ready relatively sl=
owly anyway.
>=20
> Now not talking about this part, maybe something that can measure ran=
ges up to 1mF
> - which is quite a huge capacitance.
> If the scale targets pF, then we actually use the pre-decimal point p=
ositions we have.
=46air point and using that we can go up to very large capacitances if =
there is ever the need.
>=20
>=20
>>> I would make the scale targeting pF of uF.
>> I thought about that but then we are back to having a fairly illogic=
al set of
>> units for the different types of devices.
> That's in the nature of these units.
> 1V, 1A is pretty common 1F is not.
I know, but despite that it would be nice to be consistent.
> Either move to an floating point exponential notation, or balance the=
 scale somewhere in the middle.
We could do the exponential notation I suppose.

Maybe picofarads is the right option.
>>>
>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_r=
aw
>>>> What:           /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_=
raw
>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY-c=
apacitanceZ_raw
>>>> KernelVersion:  3.1
>>>> Contact:        linux-iio@vger.kernel.org
>>>> Description:
>>>>                   Raw (unscaled no bias removal etc) capacitance v=
alue from/to
>>>>                   channel Y. After application of _offset and _sca=
le, units will
>>>>                   be Farads.
>>>>
>>>> Additional entries for:
>>>>
>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_o=
ffset
>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_s=
cale
>>>>
>>>>
>>>> With the ad7745 the capdac does seem to be available off chip.
>>> Why do you think the CAPDAC is off-chip on the AD7745?
>>> The CAPDAC can be seen as a negative capacitance connected internal=
ly
>>> to the Cin pin.
>> Oops. That was meant to be doesn't not does... Sorry for the confusi=
on.
>>>>    If I understand
>>>> their use correctly it could just be treated as a _calibbias param=
eters?
>>> Yes - it can be seen as a bias - however why do you have out_capaci=
tanceY_raw then?
>> :) Because I hadn't looked at the datasheet properly when I wrote th=
at bit and forgot
>> to go back and edit it.  This really wasn't my most coherent email e=
ver.  Google isn't
>> feeding me any digital to capacitance devices so looks like the outp=
ut side of things
>> is irrelevant.
>>>> (the complexity being that there are two..)
>>> Yes - one for each Cin(+|-) pin.
>>> More tricky on the AD7746, since there are only two CAPDACs for two=
 Cin(+|-) pin pairs.
>> As you state below that you tend to save and restore the zero offset=
, can we not do the
>> same with the capdac values?  If so they can be treated from a users=
pace point of view
>> as completely independent.
> Sure
>>>>     Naturally there is also a
>>>> calibration register so this gets somewhat tricky...
>>> The calibration register typically holds the zero-scale calibration=
 coefficient.
>>> It's automatically updated following the capacitance offset calibra=
tion.
>>> Tricky here is that there is only one on the AD7746, so the values =
must be saved
>>> and restored when switching between the input pairs.
>>>
>>>> Is there an optimum
>>>> combination for a given desire measurement range?
>>>>
>>>>
>>> Yes there is - large offsets>  1 pF should be eliminated by the CAP=
DACs.
>> Fair enough.  So what is the conclusion for what interface elements =
we
>> actually need to control this?
> Let me think about this a bit more.
Will do.
>=20
>>> from the datasheet:
>>>
>>> CAPACITIVE SYSTEM OFFSET CALIBRATION The capacitive offset is
>>> dominated by the parasitic offset in the application, such as the
>>> initial capacitance of the sensor, any parasitic capacitance of
>>> tracks on the board, and the capacitance of any other connections
>>> between the sensor and the CDC. Therefore, the AD7745/AD7746 are no=
t
>>> factory calibrated for capacitive offset. It is the user=92s
>>> responsibility to calibrate the system capacitance offset in the
>>> application. Any offset in the capacitance input larger than =B11 p=
=46
>>> should first be removed using the on-chip CAPDACs. The small offset
>>> within =B11 pF can then be removed by using the capacitance offset
>>> calibration register. One method of adjusting the offset is to
>>> connect a zero-scale capacitance to the input and execute the
>>> capacitance offset calibration mode. The calibration sets the
>>> midpoint of the =B14.096 pF range (that is, Output Code 0x800000) t=
o
>>> that zero-scale input. Another method would be to calculate and wri=
te
>>> the offset cali-bration register value, the LSB is value 31.25 aF
>>> (4.096 pF/217). The offset calibration register is reloaded by the
>>> default value at power-on or after reset. Therefore, if the offset
>>> calibration is not repeated after each system power-up, the
>>> calibration coefficient value should be stored by the host controll=
er
>>> and reloaded as part of the AD7745/AD7746 setup. On the AD7746, the
>>> register is shared by the two capacitive channels. If the capacitiv=
e
>>> channels need to be offset calibrated individually, the host
>>> controller software should read the AD7746 capacitive offset
>>> calibration register values after performing the offset calibration
>>> on individual channels and then reload the values back to the AD774=
6
>>> before executing a conversion on a different channel.
>>>> All comments welcom.
>>>> Jonathan
>>>> --=20
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ii=
o" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>> --=20
>> To unsubscribe from this list: send the line "unsubscribe linux-iio"=
 in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>=20
>=20