LDC1101: Blips in L values

Luke,

It's the latter -- we're trying to meet an aggressive power budget by gating power to the LDC1101 via a FET, and turning on and sampling at a low duty cycle.  The waveform you see is the result of a script that powers up the LDC1101, takes one sample, and powers down.

Hi Zach,

We can only recreate the issue if we read the data before DRDYB has been asserted. Note, that asserted in this case means reading a 0. Can you run the test where you read back the status of the DRDYB along with the data? I would expect the blips to occur when DRDYB is 1 and valid results when DRDYB is 0. Can you confirm this point?

Zach Williams said:

We're noticing that, after power-on, it takes a few sample time intervals for DRDY in Rp+L mode. We're pretty bummed about this because we were basing our aggressive power budget on the expectation that we would be able to immediately grab a sample after RESP_TIME has elapsed. Is there anyway to speed this up, short of reducing RESP_TIME? With our current settings, we were expecting to have a sample 1.024ms after the start of sampling. Currently, it's taking more like 4-5ms.

RP+L mode sample rate is based on the RESP_TIME and fsensor. If you decrease RESP_TIME or increase fsensor you can get a faster sample rate. The restriction of FCLKIN > 4 fSENSOR_MAX ÷ SENSOR_DIV only applies to LHR mode. However, if you are primarily interested in RP data then a lower sensor frequency will actually produce a larger response. Therefore you may find a compromise by reducing sensor frequency and decreasing RESP_TIME. 

Zach Williams said:

With our unique setup (large ferromagnetic steel target ~15mm away from our coil) we're seeing a much better SNR from Rp data than we are with L data. Is there a way to disable L measurements while in Rp+L mode?

Regards,
Luke

Thanks Luke --

We can only recreate the issue if we read the data before DRDYB has been asserted. Note, that asserted in this case means reading a 0. Can you run the test where you read back the status of the DRDYB along with the data? I would expect the blips to occur when DRDYB is 1 and valid results when DRDYB is 0. Can you confirm this point?

We're recording the status register with every sample - it always reads 0x28, or binary "0010 1000"... so DRDYB = 0, which means new data is ready.

RP+L mode sample rate is based on the RESP_TIME and fsensor. If you decrease RESP_TIME or increase fsensor you can get a faster sample rate. The restriction of FCLKIN > 4 fSENSOR_MAX ÷ SENSOR_DIV only applies to LHR mode. However, if you are primarily interested in RP data then a lower sensor frequency will actually produce a larger response. Therefore you may find a compromise by reducing sensor frequency and decreasing RESP_TIME. 

RP + L mode always gives you both readings. 

The device is not fully powered up until after 0.8ms. Therefore if you write the register settings beforehand then they may not be accepted. A quick check you can simply read back the registers you wrote to make sure they were accepted.

All good to know- thanks!

Hi Zach,

That is strange. Have you tried adding a wait after you receive the interrupt before reading the data to see if that fixes the issue?

We tried several different configurations and we can only get invalid data if we read before the 4 conversion cycles have completed (DRDYB = 1).

Here is what we see on the bench.

Settings

Conversion time=720uS

RESP_TIME=6144

Fsensor=2.9MHz

The cursors show 4 conversion cycles (~2.8ms) after settling time.

#1: Exit sleep mode

#2: Read Status & RP+L Output Codes

Invalid data read: DRDYB Bit=1, Rp=7450=2.2562kohm, ODR=6770=2.42MHz=14.416uH

Valid data read: DRDYB Bit=0, RP=44264, 6.1619kohm, ODR=5769=2.84MHz=10.468uH

Regards,

Luke 

Thanks Luke.

Another thing I just realized: all our bypass capacitance for the LDC1101 is downstream of the FET we're using to gate power.  When we switch it off, it takes ~10s to fully decay.  Is it possible we're browning out the LDC1101 when sampling repeatedly, such that it's giving us funny data?

Below, Ch1 is the LDC's power rail at a couple different time scales:

Hi Zach,
It does look like the decay on the supply line is quite long. From the scope shot if you're switching the FET back on after about 0.5s you may not be allowing the device to go into a POR state and the LDC could still be converting! How often are you turning on the FET? Also, are you writing the register to return to sleep mode after the conversion before switching off the FET? It could be the case that if you don't enter sleep mode after your final conversion and then turn off the FET, the device could still be converting when there is a significant drop in supply level and that is the code you read next time around. 
It could also be likely that the CLKIN signal is causing issues. Are you running the CLKIN for the entire conversion or are you cycling that on and off as well? If you are gating the supply to both the CLKIN signal and the LDC, then it is possible that the CLKIN signal doesn't start up at the beginning of a conversion or if it shuts off before the conversion ends then this could certainly cause the blip you are seeing.
If you confirm that the CLKIN signal looks good then you could also set the LOPTIMAL and DOK_REPORT bits to 1 and see if the spike on L goes away. Since this mode doesn't report RP, this would be for debugging purposes only.
Thanks for your patience on this one!
Luke

Thanks Luke!

One thing that I just uncovered: when I switch off the FET gating current to the LDC, the fall time for the power rail is pretty long -- ~10s with the recommended 1uF + 0.1uF bypass caps, and ~2s after removing the 1uF cap. Is it possible that, by switching the FET on and off in order to sample a couple times per second, we're perpetually browning out the LDC1101 and it's giving us junk data for the first sample as a result?

Oops.  Ignore the above.  Was looking at an old version of this page and thought my comment above hadn't been posted.

Luke,

Some more questions related to this project --

We're finding that, depending on how our system is installed, we're getting target distances that are just beyond the capabilities of our current coil circuitry -- with system noise and the amount of play in our target position, the signals for target present and target absent are overlapping slightly (even when the "blips" are disregarded):

Question 1) - we're trying to determine the source of the noise in this system.  A differential probe hooked up to the coil outputs shows minimal noise when the LDC1101 is not in active mode, so it may not be coming from elsewhere on the PCB. We're using Rp+L mode with RESP_TIME set to max.  What do you think are likely noise sources? 

Question 2) I've scoured the literature available and come up with these ways to increase sensitivity and/or and reduce noise - are there any that aren't on this list?

• Increase fclkin (can't with existing HW)
• Increase coil diameter (can't with existing HW)
• Increase coil Q factor by increasing copper weight (can do with L sense coil board spin)
• Increase Q factor by DNSing ESD components on coil output (can do with stuff option change)
• Increase permeability of ferrite backing and/ or add ferrite disc to center of coil (can do with board spin)
• Increase drive amplitude to reduce noise (decrease RPmin setting?)
• Take multiple samples and filter (no design change needed)
• Switch to LHR mode with high Rcount setting (may break our power budget)
• Increase sensor frequency to above 2MHz (looks like this might help for our steel target, per fig. 13 of SNOA957)

We'd like to combine a reduction of noise with an increase in response, because we're worried that in the field, the case as graphed above could be even worse, and we'll need some margin.

Hi Zach,
Earlier you mentioned that you were interested in RP measurements, which should give a better response for stainless steel at lower frequencies. L measurements will give a better response for steel at higher frequencies, so it is a tradeoff which measurement type you're looking for or if you need the combination of both.
As far as noise sources, the jitter of the clock can play a role, specifically the low frequency wander. As an experiment you could connect the CLKIN to a clean generator and see if your noise significantly drops. If so, then you could consider using an external oscillator on the board instead of the MCU clock. For this test you'd want to leave the FET on the board to avoid supplying CLKIN and violating the abs max spec when LDC1101 is off. Otherwise, your list for improving the response for L is good. I would just try to narrow down the problem with your existing hardware and debugging the noise before spinning the next board. Using a clean external clock source as well as changing the sensor frequency by changing the cap (higher frequency better for L, lower frequency better for RP).
Regards,
Luke

Thanks Luke.

Re: frequency and Rp vs L measurements -- we've been focusing on Rp partly because of this blog post, which alludes to Rp being better than L for some magnetic materials:

e2e.ti.com/.../inductive-sensing-should-i-measure-l-rp-or-both

"Most metal types can be equally well-measured with L or RP. However, there are some magnetic materials where the L response at certain frequencies is significantly smaller than the RP response. For those materials, RP is a more appropriate choice. We will cover this topic in more detail in an upcoming blog post."

I never found the follow-up post on this topic, and I'm wondering if our target materials (4140 carbon steel or 416 stainless steel) are on this list.

Anyway, we've focused on sensing Rp at 2MHz, but are running into the problem of target Rp drift over temperature meeting or exceeding our total dynamic range (our target temperature will track with that of our PCB, so we can't compensate using on-board temp measurements).  I'm opening up to the idea of optimizing for L, since we can put thermistors near our coil and tank cap and account for temp changes in firmware.

I'm wondering - what's an optimal frequency for measuring L of a ferrous metal?  At what point does it stop getting better with further increases in frequency?

Hi Zach,

Thanks for the additional info. Yes, RP can produce a larger response for magnetic materials especially for lower sensor frequencies. However,  even for materials like stainless steel 416, increasing the sensor frequency can greatly improve the L measurement response similar to figure 13 from SNOA957 as you've pointed out. The reason being has to do with skin depth which is a function of how conductive a target material is and the sensor frequency you're oscillating at.

For L measurements, increasing the sensor frequency reduces the skin depth for the conductor. The net effect is that more of the eddy currents are formed on the surface of the metal creating a stronger opposing magnetic field to the sensor and hence more inductance shift. Materials like stainless steel have a significantly lower conductivity than that of copper, so you will need to increase the sensor frequency significantly to achieve a similar response. This concept can be visualized with the following plot which is frequency shift normalized to the response from copper.

This data was taken with the LDC1614 which is essentially LHR mode of the LDC1101, but the response should be the same.

Regards,

Luke