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.

LDC1612: No change in the LDC 1612 Output Data Codes, independent of any movement (large or small) in front of the sensor

Part Number: LDC1612
Other Parts Discussed in Thread: TMS320F28069M

I'm using the LDC1612, attached to the TMS320F28069M C2000 MC, and I have the LDC module connected to the M coil from the LDC reference coils.

I'm communicating with the module through an I2C communication, and I am able to read and write data no problem, except that when I move my metal target either away from or towards the sensor, there is no corresponding change on the output code for that channel. I'm reading the data approximately every 1.5 seconds, with the quickest read-time being ~.75 seconds. Yet, I see large distances (during which there was constant movement of the target) where the LDC data register does not change at all.

The target is an aluminum plate roughly 5 times larger than the sensor, and at it's farthest position it is ~3.05mm away, and closest at 1.95mm. As per the Configuration design spreadsheet provided by TI, I configured the module with the following settings:

Register Address Setting
RCOUNT_CH0 0x08 0x131E
RCOUNT_CH1 0x09 0x131E
OFFSET_CH0 0x0C 0x0000
OFFSET_CH1 0x0D 0x0000
SETTLECOUNT_CH0 0x10 0x0021
SETTLECOUNT_CH1 0x11 0x0021
CLOCK_DIVIDERS_CH0 0x14 0x1001
CLOCK_DIVIDERS_CH1 0x15 0x1001
CONFIG 0x1A 0x5401
MUX_CONFIG 0x1B 0x020C
RESET_DEV 0x1C 0x0000
DRIVE_CURRENT_CH0 0x1E 0x9000
DRIVE_CURRENT_CH1 0x1F 0x9000

With the Error Config register set to 0xF800, as well. These settings should permit me a ~.25 micron resolution, according to the spreadsheet. Yet, here is my recorded plot of the distance (relative to 2mm center point):

As very clear, there are entire ranges of axial movement where no change in the data code is recorded at all. If it's relevant, in the DATA_MSB_CH1 register, the Errors bits are all zero, except for CH1_ERR_AE which is high each time I read it (yet the Status Register does not say there is a problem, for some reason). 

Thanks in advanced!

  • Hi Collin,

    First, your sensor amplitude is too high. This is not showing up in the status register because the ERROR_CONFIG register is set to not display this error (bit 4). If the sensor amplitude is too high internal ESD diodes will turn on, and eventually the device can be damaged. Use an oscilloscope to measure the INAx and INBx pins and lower the DRIVE_CURRENT setting until the amplitude of both is between 1.2V-1.8V. When the amplitudes are in this range your SNR will be maximized.

    The output code (DATAx in equation 6 in the datasheet) is a ratio of the sensor frequency to the reference frequency. You will never see a perfectly linear output because we cannot represent all mathematically possible ratios with 28 bits. Sometimes you will see small flat spots. However, these flat spots are much more significant than I would expect to see. See if fixing your sensor amplitude has any effect on them. If not, we will continue debugging.

    Regards,
  • Thanks for the help! I've changed my registers to the following configuration:

    Register Address Setting
    RCOUNT_CH0 0x08 0x0005
    RCOUNT_CH1 0x09 0x1A25
    OFFSET_CH0 0x0C 0x0000
    OFFSET_CH1 0x0D 0x0000
    SETTLECOUNT_CH0 0x10 0x0000
    SETTLECOUNT_CH1 0x11 0x0FFF
    CLOCK_DIVIDERS_CH0 0x14 0x1001
    CLOCK_DIVIDERS_CH1 0x15 0x1001
    CONFIG 0x1A 0x5401
    MUX_CONFIG 0x1B 0x820C
    RESET_DEV 0x1C 0x0000
    DRIVE_CURRENT_CH0 0x1E 0xA000
    DRIVE_CURRENT_CH1 0x1F 0xA000

    With Regsiter 0x19 (the error configuration) set to 0xFFFD.

    I've changed the module to multi-channel sampling, so I can utilize the 40 MHz clock without having to use dividers, so it samples Channel 0 and then 1. I see this behavior on an oscilloscope, with the settling frequency finishing at about ~1.45 V, after a peak Amplitude (during it's settling phase) of ~3.0V

    After looking at the I2C communications between the LDC 1612 and my MC, it appears that the reason for those huge leaps in Data Codes (which correspond to 0xFFFF + 1), is that the DATA_CH1_LSB register is always sending 0xFFFF, independent of any changes in the target. Thus leading to changes in the code when the distance was large enough to adjust a bit in DATA_CH1_MSB. Any suggestions?

  • Hi Collin,

    My apologies for the delayed reply. Based on your newest post, it looks like you've been able to solve this issue. Is this the case?

    Regards,
  • Yes I have resolved this. My problem was a silly mix-up of reading the LSB of Channel 0 and the MSB of Channel 1 (not LSB+MSB of Channel 1). Thus resulting in me only seeing changes in the output every 'large' step of distance. The reason for the staggered effect is because I applied filtering to my data codes to minimize random errors, causing that 'exponential' looking pattern at the end.

    Thanks for the help!