This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FDC1004: Precision problem on CAPDAC values

Part Number: FDC1004

Hello,

I wrote my own driver to get data from FDC1004 and implemented an automatic CAPDAC selection, to have an automatic range selection for input capacity between 0 and ~115pF.

Because 1 CAPDAC bit is 3.125pF and measure range is +/-15pF, for the same input capacity, multiple CAPDAC value can be used.

But I made some tests on a fixed input capacity, and different CAPDAC values, and when passing CAPDAC value from 7 to 8, I have a shift in the measurement result :

CAPDAC value Measurement result (femto Farad)

Input Capacitance (femto Farad)

(CAPDAC value x 3.125pF + measurement result)

1 15725 18850
2 12602 18852
3 9497 18872
4 6352 18852
5 3335 18960
6 142 18892
7 -2862 19013
8 -7370 17630
9 -10490 17635
10 -13595 17655
11 -16002(out of range) 18373(out of range)

We can see that with CAPDAC value from 1 to 7, results are pretty consistent, delta error is ~0.163pF
But between CAPDAC values 7 and 8, there is a serious error, result passing from 19.013pF to 17.630pF, thus ~1.4pF.

How can we explain this problem ? It is exactly the same problem on inputs 2/3/4

Regards

Cyril

  • Hello Cyril, 

    I am not currently seeing the same phenomenon when testing with the EVM on my end. I have a couple questions for you that will help us debug this: 

    • Is this occurring while using the EVM or your own board?
      • If it is your own board, would it be possible to test with an EVM driving your sensor?
    • Can you use an oscilloscope to capture the sensor waveform for both CAPDAC values 7 and 8? 

    Thank you, 

    Justin Beigel

  • Hello, thank you for answer.

    It's on our own board. I have no EVM to test, but our sensor is exactly the same when passing from capdac value 7 to 8, I wondering how its capacity can change.

    Yes I can use a scope, you want to see the waveform between GND and IN1 for example ?

    I made a search in the forum, there are other topics on same problem, for example : https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/979977/fdc1004-different-capacitance-value-measured-when-capdac-change

    What I understand is this chip is not intended to do absolute capacity measurement, CAPDAC should be fixed depending on the fixed parasitic capacity of the sensor, and should not be modified.

    In my project, the absolute water level in the tank is not required. I just need to know when water level is higher than the high level threshold (tank considered full), or when the water level is below the low level threshold (tank considered empty).

    What is the better way to design electrodes to only have these 2 information, without the need to calibrate the system the first time (or just a dry calibration without water to learn the sensor capacity value when there is not water on "empty" input and "full" input). In fact it's like 2 on/off sensors, water is present or not present on the input, like a sensitive touch button.

  • Hello, 

    Yes the scope capture would be between IN1 and GND.

    You are correct that the device is better at looking for a change in capacitance than an absolute and for best resolution, we recommend not changing the CAPDAC.

    If you only need the two determinations, would it be possible to include a small sensor at each end of the sensing range? In the Capacitive Sensing: Out-of-Phase Liquid Level Technique app note, we use an environment and liquid sensor electrode. You could instead use these as alerts to know when the liquid passes above or below the sensing region. Anytime the two smaller electrodes are equal to each other would correlate to the the water being above or below. If you can track the state knowing whether the liquid was increasing or decreasing based on the main sensor, then you should have enough information to help reduce the impact of environmental impacts as well. 

    Best Regards, 
    Justin Beigel