IIO: Interface for capacitance inputs (and outputs)

IIO: Interface for capacitance inputs (and outputs)

[Jonathan Cameron]

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..

What:		/sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
What:		/sys/bus/iio/devices/iio:deviceX/out_capacitanceY_raw
What:		/sys/bus/iio/devices/iio:deviceX/in_capacitanceY-capacitanceZ_raw
KernelVersion:	3.1
Contact:	linux-iio@vger.kernel.org
Description:
		Raw (unscaled no bias removal etc) capacitance value from/to
		channel Y. After application of _offset and _scale, units will
		be Farads.

Additional entries for:

What:		/sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offset
What:		/sys/bus/iio/devices/iio:deviceX/in_capacitanceY_scale


With the ad7745 the capdac does seem to be available off chip. If I understand
their use correctly it could just be treated as a _calibbias parameters?
(the complexity being that there are two..)  Naturally there is also a
calibration register so this gets somewhat tricky...  Is there an optimum
combination for a given desire measurement range?


All comments welcom.

Jonathan

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

[Michael Hennerich]

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 ab=
i
> 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?
We need something scanf() and friends can eat...
In addition we have enough scale bits before the decimal point as well.
I would make the scale targeting pF of uF.


> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
> What:           /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_raw
> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY-capaci=
tanceZ_raw
> KernelVersion:  3.1
> Contact:        linux-iio@vger.kernel.org
> Description:
>                  Raw (unscaled no bias removal etc) capacitance value f=
rom/to
>                  channel Y. After application of _offset and _scale, un=
its will
>                  be Farads.
>
> Additional entries for:
>
> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offset
> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_scale
>
>
> 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 internally
to the Cin pin.

>   If I understand
> their use correctly it could just be treated as a _calibbias parameters=
?
Yes - it can be seen as a bias - however why do you have=20
out_capacitanceY_raw then?
> (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=20
Cin(+|-) pin pairs.

>    Naturally there is also a
> calibration register so this gets somewhat tricky...
The calibration register typically holds the zero-scale calibration=20
coefficient.
It's automatically updated following the capacitance offset calibration.
Tricky here is that there is only one on the AD7746, so the values must=20
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 CAPDACs.

from the datasheet:

CAPACITIVE SYSTEM OFFSET CALIBRATION
The capacitive offset is dominated by the parasitic offset in the=20
application, such as the initial capacitance of the sensor, any=20
parasitic capacitance of tracks on the board, and the capacitance of any=20
other connections between the sensor and the CDC. Therefore, the=20
AD7745/AD7746 are not factory calibrated for capacitive offset. It is=20
the user=92s responsibility to calibrate the system capacitance offset in=
=20
the application.
Any offset in the capacitance input larger than =B11 pF should first be=20
removed using the on-chip CAPDACs. The small offset within =B11 pF can=20
then be removed by using the capacitance offset calibration register.
One method of adjusting the offset is to connect a zero-scale=20
capacitance to the input and execute the capacitance offset calibration=20
mode. The calibration sets the midpoint of the =B14.096 pF range (that is=
,=20
Output Code 0x800000) to that zero-scale input.
Another method would be to calculate and write the offset cali-bration=20
register value, the LSB is value 31.25 aF (4.096 pF/217).
The offset calibration register is reloaded by the default value at=20
power-on or after reset. Therefore, if the offset calibration is not=20
repeated after each system power-up, the calibration coefficient value=20
should be stored by the host controller and reloaded as part of the=20
AD7745/AD7746 setup.
On the AD7746, the register is shared by the two capacitive channels. If=20
the capacitive channels need to be offset calibrated individually, the=20
host controller software should read the AD7746 capacitive offset=20
calibration register values after performing the offset calibration on=20
individual channels and then reload the values back to the AD7746 before=20
executing a conversion on a different channel.
> All comments welcom.
>
> Jonathan
> --
> 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
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

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

[Jonathan Cameron]

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 s=
o
>> 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 un=
its...
>> 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 ne=
ed those
>> types with holes in them..
>=20
> Hi Jonathan,
>=20
> These devices typically feature an single digit pF input range(2..8 p=
=46).
> 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  Thus t=
here are quite a
few leading zeros.
> We need something scanf() and friends can eat...
Yup.
> In addition we have enough scale bits before the decimal point as wel=
l.
Please give an example why. Do we have a calibscale type attribute here=
?
> I would make the scale targeting pF of uF.
I thought about that but then we are back to having a fairly illogical =
set of
units for the different types of devices.
>=20
>=20
>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
>> What:           /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_ra=
w
>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY-cap=
acitanceZ_raw
>> KernelVersion:  3.1
>> Contact:        linux-iio@vger.kernel.org
>> Description:
>>                  Raw (unscaled no bias removal etc) capacitance valu=
e from/to
>>                  channel Y. After application of _offset and _scale,=
 units will
>>                  be Farads.
>>
>> Additional entries for:
>>
>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_off=
set
>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_sca=
le
>>
>>
>> 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 internally
> to the Cin pin.
Oops. That was meant to be doesn't not does... Sorry for the confusion.
>=20
>>   If I understand
>> their use correctly it could just be treated as a _calibbias paramet=
ers?
> Yes - it can be seen as a bias - however why do you have out_capacita=
nceY_raw then?
:) Because I hadn't looked at the datasheet properly when I wrote that =
bit and forgot
to go back and edit it.  This really wasn't my most coherent email ever=
=2E  Google isn't
feeding me any digital to capacitance devices so looks like the output =
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 C=
in(+|-) pin pairs.
As you state below that you tend to save and restore the zero offset, c=
an we not do the
same with the capdac values?  If so they can be treated from a userspac=
e point of view
as completely independent.=20
>=20
>>    Naturally there is also a
>> calibration register so this gets somewhat tricky...
> The calibration register typically holds the zero-scale calibration c=
oefficient.
> It's automatically updated following the capacitance offset calibrati=
on.
> Tricky here is that there is only one on the AD7746, so the values mu=
st be saved
> and restored when switching between the input pairs.
>=20
>> Is there an optimum
>> combination for a given desire measurement range?
>>
>>
> Yes there is - large offsets > 1 pF should be eliminated by the CAPDA=
Cs.
=46air enough.  So what is the conclusion for what interface elements w=
e
actually need to control this?
>=20
> from the datasheet:
>=20
> 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 not
> 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 pF
> 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) to
> that zero-scale input. Another method would be to calculate and write
> 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 controller
> and reloaded as part of the AD7745/AD7746 setup. On the AD7746, the
> register is shared by the two capacitive channels. If the capacitive
> 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 AD7746
> before executing a conversion on a different channel.
>> All comments welcom.
>> Jonathan
>> --=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

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

[Michael Hennerich]

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 uni=
ts...
>>> Doing it with Farads leaves us with a lot of needed decimal places, b=
ut then
>>> we need a lot anyway for these so what the heck.  We are going to nee=
d 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  Thus t=
here are quite a
> few leading zeros.
The part has a full range of +/- 4.096pf and it is a 24-bit converter.
We like to store the conversion result as 3-byte direct readings from=20
the device result register.

Thus the Farad scale would need to be
8.192E-12 / 2^24 =3D 4.8828125E-19 =3D 0.00000000000000000048828125.

I don't think this makes any sense?

>> We need something scanf() and friends can eat...
> Yup.
>> In addition we have enough scale bits before the decimal point as well=
.
> Please give an example why. Do we have a calibscale type attribute here=
?
I don't understand, why calibscale would matter here?

But sure we have a in_capacitanceY_scale.
If we say the in_capacitanceY_scale targets pF.

Then we still need enough fractional digits, due to the 24-bit nature of=20
the device.

Now not talking about this part, maybe something that can measure ranges=20
up to 1mF
- which is quite a huge capacitance.
If the scale targets pF, then we actually use the pre-decimal point=20
positions we have.


>> I would make the scale targeting pF of uF.
> I thought about that but then we are back to having a fairly illogical =
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.
Either move to an floating point exponential notation, or balance the=20
scale somewhere in the middle.

>>
>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
>>> What:           /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_raw
>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY-capa=
citanceZ_raw
>>> KernelVersion:  3.1
>>> Contact:        linux-iio@vger.kernel.org
>>> Description:
>>>                   Raw (unscaled no bias removal etc) capacitance valu=
e from/to
>>>                   channel Y. After application of _offset and _scale,=
 units will
>>>                   be Farads.
>>>
>>> Additional entries for:
>>>
>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offs=
et
>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_scal=
e
>>>
>>>
>>> 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 internally
>> to the Cin pin.
> Oops. That was meant to be doesn't not does... Sorry for the confusion.
>>>    If I understand
>>> their use correctly it could just be treated as a _calibbias paramete=
rs?
>> Yes - it can be seen as a bias - however why do you have out_capacitan=
ceY_raw then?
> :) Because I hadn't looked at the datasheet properly when I wrote that =
bit and forgot
> to go back and edit it.  This really wasn't my most coherent email ever=
.  Google isn't
> feeding me any digital to capacitance devices so looks like the output =
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 Ci=
n(+|-) pin pairs.
> As you state below that you tend to save and restore the zero offset, c=
an we not do the
> same with the capdac values?  If so they can be treated from a userspac=
e 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 co=
efficient.
>> It's automatically updated following the capacitance offset calibratio=
n.
>> Tricky here is that there is only one on the AD7746, so the values mus=
t 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 CAPDAC=
s.
> 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.

>> 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 not
>> 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 pF
>> 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) to
>> that zero-scale input. Another method would be to calculate and write
>> 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 controller
>> and reloaded as part of the AD7745/AD7746 setup. On the AD7746, the
>> register is shared by the two capacitive channels. If the capacitive
>> 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 AD7746
>> before executing a conversion on a different channel.
>>> All comments welcom.
>>> Jonathan
>>> --
>>> 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
>>>
>>
> --
> 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
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

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

[Jonathan Cameron]

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

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

[Michael Hennerich]

On 08/02/2011 05:18 PM, Jonathan Cameron wrote:
> 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 a=
n abi
>>>>> for them.
>>>>>
>>>>> So lets make one up. How about the following?  Main choice is the u=
nits...
>>>>> 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 n=
eed 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  Thus=
 there are quite a
>>> few leading zeros.
>> The part has a full range of +/- 4.096pf and it is a 24-bit converter.
>> We like to store the conversion result as 3-byte direct readings from =
the device result register.
>>
>> Thus the Farad scale would need to be
>> 8.192E-12 / 2^24 =3D 4.8828125E-19 =3D 0.00000000000000000048828125.
>>
>> I don't think this makes any sense?
> It's certainly uggly.
>>>> We need something scanf() and friends can eat...
>>> Yup.
>>>> In addition we have enough scale bits before the decimal point as we=
ll.
>>> Please give an example why. Do we have a calibscale type attribute he=
re?
>> I don't understand, why calibscale would matter here?
> Because it's the only item I can think of where a value of
> 0.99999999999999999999999999999999999992 would make sense and that's th=
e one
> nasty case that requires a 'lot' of digits to represent currently).
>> But sure we have a in_capacitanceY_scale.
>> If we say the in_capacitanceY_scale targets pF.
>>
>> 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.
>> Now not talking about this part, maybe something that can measure rang=
es up to 1mF
>> - which is quite a huge capacitance.
>> If the scale targets pF, then we actually use the pre-decimal point po=
sitions we have.
> Fair point and using that we can go up to very large capacitances if th=
ere is ever the need.
>>
>>>> I would make the scale targeting pF of uF.
>>> I thought about that but then we are back to having a fairly illogica=
l 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_ra=
w
>>>>> What:           /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_r=
aw
>>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY-ca=
pacitanceZ_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_of=
fset
>>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_sc=
ale
>>>>>
>>>>>
>>>>> 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 internall=
y
>>>> to the Cin pin.
>>> Oops. That was meant to be doesn't not does... Sorry for the confusio=
n.
>>>>>     If I understand
>>>>> their use correctly it could just be treated as a _calibbias parame=
ters?
>>>> Yes - it can be seen as a bias - however why do you have out_capacit=
anceY_raw then?
>>> :) Because I hadn't looked at the datasheet properly when I wrote tha=
t bit and forgot
>>> to go back and edit it.  This really wasn't my most coherent email ev=
er.  Google isn't
>>> feeding me any digital to capacitance devices so looks like the outpu=
t 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 usersp=
ace 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 calibrat=
ion.
>>>> Tricky here is that there is only one on the AD7746, so the values m=
ust 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 w=
e
>>> actually need to control this?
>> Let me think about this a bit more.
> Will do.
Hi Jonathan,

I don't think it's practical or fits the typical use case to just have=20
_calibbias handling both.
How about following -

The cap offset calibration register maps to _calibbias and handles the=20
small calibration offsets.
We also need a do calibrate attribute...

For the larger CAPDAC offsets, we introduce in_capacitanceY_bias.
in_capacitanceY_offset would be nicer, but we already use it for other=20
purposes.

Thoughts?

>>>> 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 not
>>>> 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 pF
>>>> 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) to
>>>> that zero-scale input. Another method would be to calculate and writ=
e
>>>> 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 controlle=
r
>>>> and reloaded as part of the AD7745/AD7746 setup. On the AD7746, the
>>>> register is shared by the two capacitive channels. If the capacitive
>>>> 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 AD7746
>>>> before executing a conversion on a different channel.
>>>>> All comments welcom.
>>>>> Jonathan
>>>>> --
>>>>> 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
>>>>>
>>> --
>>> 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
>>>
>>
> --
> 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
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

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

[Jonathan Cameron]

>>>>>> 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  Thus there are quite a
>>>> few leading zeros.
>>> The part has a full range of +/- 4.096pf and it is a 24-bit converter.
>>> We like to store the conversion result as 3-byte direct readings from the device result register.
>>>
>>> Thus the Farad scale would need to be
>>> 8.192E-12 / 2^24 = 4.8828125E-19 = 0.00000000000000000048828125.
>>>
>>> I don't think this makes any sense?
>> It's certainly uggly.
>>>>> We need something scanf() and friends can eat...
>>>> Yup.
>>>>> In addition we have enough scale bits before the decimal point as well.
>>>> Please give an example why. Do we have a calibscale type attribute here?
>>> I don't understand, why calibscale would matter here?
>> Because it's the only item I can think of where a value of
>> 0.99999999999999999999999999999999999992 would make sense and that's the one
>> nasty case that requires a 'lot' of digits to represent currently).
>>> But sure we have a in_capacitanceY_scale.
>>> If we say the in_capacitanceY_scale targets pF.
>>>
>>> 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 move everything to
>> 64 bit just to give us the space. This stuff is all ready relatively slowly anyway.
>>> Now not talking about this part, maybe something that can measure ranges up to 1mF
>>> - which is quite a huge capacitance.
>>> If the scale targets pF, then we actually use the pre-decimal point positions we have.
>> Fair point and using that we can go up to very large capacitances if there is ever the need.
>>>
>>>>> I would make the scale targeting pF of uF.
>>>> I thought about that but then we are back to having a fairly illogical 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_raw
>>>>>> What:           /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_raw
>>>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY-capacitanceZ_raw
>>>>>> KernelVersion:  3.1
>>>>>> Contact:        linux-iio@vger.kernel.org
>>>>>> Description:
>>>>>>                    Raw (unscaled no bias removal etc) capacitance value from/to
>>>>>>                    channel Y. After application of _offset and _scale, units will
>>>>>>                    be Farads.
>>>>>>
>>>>>> Additional entries for:
>>>>>>
>>>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offset
>>>>>> What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_scale
>>>>>>
>>>>>>
>>>>>> 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 internally
>>>>> to the Cin pin.
>>>> Oops. That was meant to be doesn't not does... Sorry for the confusion.
>>>>>>     If I understand
>>>>>> their use correctly it could just be treated as a _calibbias parameters?
>>>>> Yes - it can be seen as a bias - however why do you have out_capacitanceY_raw then?
>>>> :) Because I hadn't looked at the datasheet properly when I wrote that bit and forgot
>>>> to go back and edit it.  This really wasn't my most coherent email ever.  Google isn't
>>>> feeding me any digital to capacitance devices so looks like the output 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 userspace 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 calibration.
>>>>> 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 CAPDACs.
>>>> 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.
> Hi Jonathan,
> 
> I don't think it's practical or fits the typical use case to just have _calibbias handling both.
> How about following -
> 
> The cap offset calibration register maps to _calibbias and handles the small calibration offsets.
> We also need a do calibrate attribute...
> 
> For the larger CAPDAC offsets, we introduce in_capacitanceY_bias.
> in_capacitanceY_offset would be nicer, but we already use it for other purposes.
> 
> Thoughts?
Works for me.  Will need to document this very clearly to stop people mixing up
_bias and _offset.