• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 370 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.

Original question:

[LDC1612] Read wrong Inductive value

LDC1612: Read wrong frequency values

Philippe Venier
Prodigy 30 points
Part Number: LDC1612

Dear TI,

Please give some tips for the following phenomenon we observe

When we read the CH0 or CH1 data of LDC1612, the value are sometimes completely
out of range, usually once per hour. The expected values are approximately 52345000
corresponding to a frequency of 7.8MHz with a variation of +/-0.2MHz according to
the position of the metallic object to be detected, knowing that we use an external
clock of 40MHz.

Typical out of range values we read are between 8.5MHz and 20MHz, always higher than the expected frequency.
Before reading a value from the LDC1612, we always check that no error are reported in the STATUS register.

If you have any question or need more information, please let me know.

Best regards.

  • 0
    TI__Mastermind 18545 points

    Hello Philippe, 

    I would start by checking your deglitch filter setting in the MUX_CONFIG register for this. Make sure that it is set to just above the max frequency you expect. If that is the 7.8MHz, then it should be set to 10MHz. 

    If this does not solve the issue, what are your register settings for this application? 

    Best Regards,

  • 0 in reply to Justin Beigel
    Prodigy 30 points

    Hello Justin,

    The value set in the MUX_CONFIG register is 0x820D so the bandwith of the input deglitch filter is well set to 10MHz.

    The register settings for my application are:

    RCOUNT0                     0x0800
    RCOUNT1                     0x0800
    SETTLECOUNT0          0x0040
    SETTLECOUNT1          0x0040
    CLOCK_DIVIDERS0     0x1001
    CLOCK_DIVIDERS1     0x1001
    ERROR_CONFIG         0x00FD
    CONFIG                         0x1E01
    MUX_CONFIG                0x820D
    DRIVE_CURRENT0       0x9800
    DRIVE_CURRENT1       0x9800

    Thank you for your help

    Best regards,

    Philippe

  • 0 in reply to Philippe Venier
    TI__Mastermind 18545 points

    Hello,

    Since the value you are seeing is much higher than expected, you could try checking for an out of range error by enabling the corresponding bit in the ERROR_CONFIG register. Then seeing if the error pops up before the invalid data.

    Another thing to check is the oscillation amplitude of the sensor (the ideal range for this is between 1.2V and 1.8V). If the oscillation amplitude is too low, the device can become susceptible to EMI.

    Best,

  • 0 in reply to Justin Beigel
    Prodigy 30 points

    Hello,

    I enabled the Under-range Error and Over-range Error bits in the ERROR_CONFIG register but I never observed errors on the ERR_UR and ERR_OR flags in the STATUS register.
    What are the values of the Under-range and Over-range thresholds? 0x0000000 and 0xFFFFFFF? Can these values be changed?

    Since it is not easy to connect an oscilloscope to the coils of my sensor to measure the oscillation amplitude, I set the ERR_AHE (Sensor Amplitude High Error) and ERR_ALE (Sensor Amplitude Low Error) bits in the ERROR_CONFIG register and observed the errors on the ERR_AHE and ERR_ALE flags by varying the IDRIVE0 and IDRIVE1 values in the DRIVE_CURRENT0 and DRIVE_CURRENT1 registers.


    I observe ERR_AHE errors with IDRIVEx = 20 without target .
    I observe ERR_ALE errors with IDRIVEx = 18 if the sensor target distance becomes small.
    With IDRIVEx = 19, I observe no ERR_AHE and ERR_ALE errors whatever the sensor target distance.

    So the value IDRIVEx = 19 of my initial configuration is correct and optimal.

    Thank you for your help

    Best regards,

    Philippe

  • 0 in reply to Philippe Venier
    TI__Mastermind 18545 points

    Hello Philippe, 

    The under-range and over-range thresholds cannot be changed since they are the overall range of the device. 

    For the sensor amplitude, not getting an error is a good sign but it would still be easier to debug the issue knowing how the sensor signal acts around the time the anomaly occurs. Any chance you can send me a capture of the data around this anomaly? 

    Best Regards,