• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 487 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LDC1614: Temporal drift of the absolute value.

Léon MARI
Prodigy 10 points
Part Number: LDC1614

Hi Team,

We use two LDC1614 for detecting 8 steel rode of 6mm each. 

The antennas we're using have 22 turns and 4 layers, with an external diameter of 16mm and an internal diameter of 2mm. Our bulk capacitor is a 470pF in X7R. The operating frequency is approximately 1MHz, and we have an external oscillator running at 40MHz. We have approximately 1.7V at the antenna.

During testing, we observed that the frequency variation is initially satisfactory for detecting the rods, with around 40,000 counts. However, over several hours or days, we encounter a drift in the sensor readings that exceeds the threshold value.

To illustrate, we created a chart depicting the values of one antenna over a week. We sampled the sensor every 100ms, and every 5 minutes, we recorded the maximum and minimum values. Despite having low noise, we are experiencing a significant drift.

The same mesurement are made during 20h over all 8 antennas while incorporating temperature data from one of the sensors.

We are seeking your insights on the potential causes of this drift. Could using a higher or lower frequency result in greater stability?

Thank you,
Regads,
Léon MARI

  • 0
    TI__Mastermind 18545 points

    Hello Léon, 

    I have a couple follow up questions for you on this issue: 

    • Does your data collection include any of the interaction with the steel rod or is it without the target present? 
    • Can you provide your device configuration? 

    Thank you, 

    Justin Beigel

  • 0 in reply to Justin Beigel
    Prodigy 10 points

    Hello Justin,

    - The data collection is without the target.
    - This his our device configuration:

    • LDC_REG_VALUE_CLOCK_DIVIDER 0x1001
    • LDC_REG_VALUE_SETTLECOUNT   0x0400
    • LDC_REG_VALUE_RCOUNT        0x3000
    • LDC_REG_VALUE_ERROR_CONFIG 0x0001
    • LDC_REG_VALUE_DRIVE_CURRENT_BITS 0xB040
    • LDC_REG_VALUE_MUX_CONFIG 0xC20C
    • LDC_REG_VALUE_CONFIG_SLEEP  0x3E01
    • LDC_REG_VALUE_CONFIG_RUN    0x1E01

    Sensor number: 1
    Idrive: 22
    Sensor number: 2
    Idrive: 23
    Sensor number: 3
    Idrive: 22
    Sensor number: 4
    Idrive: 22
    Sensor number: 5
    Idrive: 22
    Sensor number: 6
    Idrive: 22
    Sensor number: 7
    Idrive: 22
    Sensor number: 8
    Idrive: 22

    Thank you,

    Léon MARI

  • 0 in reply to Léon MARI
    TI__Mastermind 18545 points

    Hello Léon, 

    Thanks for sharing the additional details. I don't see anything in the configuration that would be a red flag for this issue. One thing you could do is enable the error reporting to the status register and take a status register read to go with the data collection. If any error conditions are appearing when the data spikes, it could help indicate what is occurring. 

    One other test I have in mind is to increase your sample rate when you notice the data is spiking. Would it be possible to collect more frequently than every 5 min to see if the spikes have increased noise occurring as well? 

    Best Regards, 

    Justin Beigel

  • 0 in reply to Justin Beigel
    Prodigy 10 points

    Hello Justine,

    When we zoom in on the data, the peaks are not noisy. And this is not really the problem, it is rather the global drift. "Spikes" appears around 8:30AM.

    Cordially,

    Leon Mari

  • 0 in reply to Léon MARI
    TI__Mastermind 18545 points

    Hello Leon, 

    There are a couple things that you can do to 

    • You could check your power supply to make sure it is low noise and does not drift over time/temperature. 
    • Make sure your sensor capacitors areC0G to reduce drift, especially drift due to temperature.
    • If you want, we could perform a schematic review for you to make sure there is nothing that sticks out as a problem. 

    Additionally, I have a question about how you check your 40,000 count threshold. Are you just comparing the data to a threshold or do you have any averaging or data filtering to check for a fast change in data that would signify the placement or removal of the steel rod? 

    Best Regards, 

    Justin Beigel

  • 0 in reply to Justin Beigel
    Prodigy 10 points

    Hello Justin,

    We are currently conducting tests with COG capacitors in an oven, as we believe this may be our best solution.

    Our main objective is to achieve absolute detection, especially during startup when we are unsure if the rods are present or not.

    Best Regards,

    Léon MARI

  • 0 in reply to Léon MARI
    TI__Mastermind 18545 points

    Hello Leon, 

    Sounds good. Let us know if the results of the C0G test are good enough for your application or if you are still having issues. 

    Best Regards, 

    Justin Beigel