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.

LDC1312: different inductance values at different devices

Part Number: LDC1312

Dear support,

we're using LDC1312 for weight sensing using 2 coils: cell and reference coils.

The main idea is to always use the inductance differences between them to estimate weight.

Metal target is placed atop of cell coil, reference coil is "free" of metal atop of it.

Our issue is that inductance values is very different on a different devices.

E.g. on my prototype I see ~200 in decimal form, whenever my teammate estimates ~4000.

The binary file we have flashed in our microcontrollers is the same -> configuration is the same.

The only thing is can be different is a different values of C tank. Nominally they're the same, but their values can differ inside the declared accuracy.

I'm confused in my investigations on what's wrong so please help.

Here's a piece of code where configuration is takes it's place. I believe everything should be clear.

	{LDC13xx16xx_CMD_REF_COUNT_CH0,0xFFFF},
	{LDC13xx16xx_CMD_REF_COUNT_CH1,0xFFFF},
	{LDC13xx16xx_CMD_OFFSET_CH0,0x0000},
	{LDC13xx16xx_CMD_OFFSET_CH1,0x0000},
	{LDC13xx16xx_CMD_SETTLE_COUNT_CH0,0x0400},
	{LDC13xx16xx_CMD_SETTLE_COUNT_CH1,0x0400},
	{LDC13xx16xx_CMD_CLOCK_DIVIDERS_CH0,0x0000}, // bypass dividers
	{LDC13xx16xx_CMD_CLOCK_DIVIDERS_CH1,0x0000},
	{LDC13xx16xx_CMD_ERROR_CONFIG, 0xFFFF},
	{LDC13xx16xx_CMD_CONFIG,0x0000}, // CLKIN pin
	{LDC13xx16xx_CMD_MUX_CONFIG, REG_MUX_CONFIG_AUTOSCAN_EN | REG_MUX_CONFIG_DEGLITCH_1MHZ},
	{LDC13xx16xx_CMD_RESET_DEVICE, 0x0000},
	{LDC13xx16xx_CMD_DRIVE_CURRENT_CH0,0x0000}, //
	{LDC13xx16xx_CMD_DRIVE_CURRENT_CH1,0x0000}, //

CLKIN pin is chosen to be internally clocked due to the errors with PWM on my microcontroller.

Thanks !

  • Also,
    I've forgot to mention one important note: we're powering our devices from the batteries.
    The power booster is used, but I think that voltage dropdown may take place.
    If so, then my question is: may the internal oscillator of LDC1312 fluctuate due to voltage dropdown ?
  • Hello,

    Thanks for posting your question as well as your register settings. I would first try to make your setup as similar as possible to your colleagues. You can check the following items:

    • There are part-to-part variations of the nominal internal oscillator frequency. We say typically that it is 43.4MHz, but it has a minimum value of 35MHz and maximum value of 55MHz depending on which lot the device was selected from. Having two devices with different internal oscillator values will result in a different DATA value even if the sensor is the same for both. I would check for this by driving both your demo and your colleagues demo with the same external oscillator to rule that out.
    • There are part-to-part variations of the sensor components themselves as you've already pointed out. Namely the capacitor tolerance provides the largest source of variation especially if the inductor is a PCB-based inductor. You can minimize this issue by selecting tighter tolerance capacitors such as C0G type.
    • You mentioned the circuit is battery powered. There is a slight dependency of the internal oscillator to supply voltage. This is characterized in figure 9. I would try to connect an external supply of the same voltage just to rule this out as well.
    • CONFIG register for 0x0000 which enables Auto Amplitude Correct. This means that the idrive setting may be different everytime the device boots up. There is also a slight dependency of the IDRIVE setting to the sensor oscillator frequency. What is more recommended is to disable AUTO_AMP_DIS (set to b1), enable RP_OVERRIDE_EN (set to b1), then monitor the sensor amplitude with an oscilloscope and adjust the IDRIVE setting for CH0 (register 0x1E) until the amplitude is between 1.2V and 1.8V with no metal present or at its maximum distance.
    • You're currently setting the clock dividers to 0x0000 which is an invalid setting. You should at least set the clock dividers to a value of 1. This most likely won't be the problem you are seeing, but I wanted to point it out.

    Also, just a performance improvement suggestion. You're currently setting the GAIN value to 0 (RESET_DEV register 0x1C). Depending on your resolution requirements you can increase the resolution by up to 4 bits. You can refer to the following blog for more information: https://e2e.ti.com/blogs_/b/analogwire/archive/2015/06/24/inductive-sensing-improve-the-enob-of-a-multichannel-ldc-by-4-bits-in-3-simple-steps

    Let me know if the above information helps. If you're still running into issues then I would ask you to provide more information about the sensor components themselves, the mechanical arrangement of the sensor and metal, and potentially scope shots of the sensor waveforms.

    Thanks!

    Luke LaPointe

  • Luke,

    Thank you so much for your reply ! That's very helpful.

    Before seeing your answer, I've learned that I didn't set AUTO_AMP_DIS to b0 so that I've had a wrong device operating mode.

    But I left auto amplitude correction enabled for device startup for short time to read CHx_INIT_IDRIVE in DRIVE_CURRENT_CHx and set this into CHx_IDRIVE. Am I  doing right thing ?

    Anyway, that helped us to keep the DATA value in the sane limits.

    >> I would check for this by driving both your demo and your colleagues demo with the same external oscillator to rule that out.

    Definitey, make sense. At my initial LDC1312 driver stages, I've tried to drive LDC by external PWM from host microcontroller. But due to host microcontroller IC hardware issues, I've needed to switch to an internal oscillator.

    >> You're currently setting the clock dividers to 0x0000 which is an invalid setting. You should at least set the clock dividers to a value of 1. This most likely won't be the problem you are seeing, but I wanted to point it out.

    Yes, that wasn't a problem. At the moment I've set that to 0x0001 the problem is has to be continued.

    We'll take your suggestions and notes into account.

    Thanks !