>>>>>> 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@xxxxxxxxxxxxxxx >>>>>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
