LDC1101: Noise in LHR measurements with

Hello Arthur,

I need to consult with one of my colleagues on this next Monday. Initial guess is that your RC time constants are too short, which leads to an improper tuning of the internal oscillation circuitry.  I suspect discrepancies in your fabricated coil, total capacitance, size of target might affect whether it tunes properly, however, I need to check with my team on that.  

Hello Arthur,

I noticed that the register 0x04 setting is a little different than what you used in the excel tool posted on the other thread. Could you provide the excel form corresponding to the design you have proceeded with building? Aside from that, the probes you have can potentially load the sensor and shift the frequency. We typically recommend placing a 1k resistor between the probe and the LC tank, have you tried doing that?

Hi Patrick,

The probe connected in my setup is a TDP1500 - it has 200K differential input resistance, is that fine? https://www.tek.com/en/datasheet/differential-probes

sensor min freq 8/3 = 2.67MHz seems a better fit for our device which operates at 4MHz nominally (with no target). That's where the upper nibble 0xD in register 0x04 comes from.  Using 0xE7 as given by the spreadsheet seems like a bad idea, as that would set the minimum frequency to 4MHz.

The 0x5 lower nibble in register 0x04 comes from this thread.  https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1372291/ldc1101-dig_conf-measurement-response-time

LDC_Tools-EVT1 recheck.xlsx

Hey Arthur,

Thanks for providing those details.  We need to look those over a bit.  Will try to have a response either by the end of today or tomorrow morning.

Hello Arthur,

It looks like the LC entries in the LDC1101_calc tab are based upon the design Spiral_inductor_design.  Can you confirm no intentional modifications have been made to the coil not captured in the design?  Were these measurements you performed with a target and if so can you clarify the size, shape, and material of your target?   Lastly are these also collected from single conversion cycles when waking from sleep mode?  We are trying to get a more complete picture of your test setup to find possible sources of error and if necessary define the test conditions we should use to replicate the issue on the bench.

Hi Patrick, I'm sorry it looks like I missed the update from you and just now noticed it.

The coil was fabricated as recommended by the spiral inductor calculator and no intentional modifications made. 

For the data points I shared above, please consider them "no target".  I was just characterizing the sensor frequency in the state where no metal is nearby.

These are all collected from single conversion cycles when waking from shutdown mode -> sleep mode -> active conversion mode.

If you are interested to replicate the issue on your bench, maybe I could send you a sample unit for your efforts?  We could open up a Direct Message to arrange that.  Let me know & thanks,

Arthur

Hello Arthur,

Thanks for confirming those details.  We are just trying to get a more complete picture of what you are working with.  Shipping us an EVM will not be necessary. I need to do a little more digging and possibly do some bench tests with regard to your inquiry.  I will try to have an update for you tomorrow.

Hey Arthur,

So on my end, It does look like manipulating the Time Constant 2 configuration register can influence the measurement.  If you change register TC2 to x70, x4F, xA5 does the reading similarly start matching closer to what you expect based on your frequency calculations?

Hi Patrick,

Thanks for your response, please allow me some time while I figure out a good way to change register settings on the fly in this oscilloscope test setup that I'm working with.

In the mean time can you tell me about the TC2 register change?  Which values would you expect to be the most accurate?

Register "tuned"  "untuned"  Trial 1  Trial 2   Trial 3

0x03      0x7E        0xA0        0x70     0x4F     0xA5

 Neither the LDC1101 datasheet nor the LDC calculations spreadsheet give much insight into how the TC2 value is chosen.  Is there any way to check our empirical results of "frequency accuracy" with some proper parameter for expected device operation (like a proper rise time or fall time measurement maybe?)

Hey Arthur,

As this is one of our older parts and all individuals involved in the original development are no longer here, I am having some difficulty determining the exact purpose of that register.  With the limited information I can find, my hypothesis is as follows:

I think the TC2 register provides a sampling window duration for calculating the frequency. I suspect some sort of zero crossing counter is used for determining the frequency.  The ratio of counts to a base value determined by TC2 is likely multiplied by a frequency value derived from TC1. Based on your values and some calculations I have done, it looks like you initially had a smaller RC constant corresponding to a higher frequency (shorter sampling period).  As the device expected a higher frequency it provided less time to count zero crossings, thereby leading to a smaller calculated frequency.  After increasing you RC time constant in TC2 it looks like you started measuring something that matches what you expect based upon measurement.  I noticed that your no target frequency is 3.78MHz while the coil design show 4.03MHz.  So I suppose your device is setup to expect a base frequency of 4.03MHz, when in reality it should be expecting a base of 3.78MHz or lower.

What tolerance capacitor are you using in parallel with the coil?  My tool suggests your cap value might actually be around 150pF.  That could be including parasitic board and device capacitance.  However, it is possible your coil also might have some tolerance leading to the lower frequency

Hi Patrick,

The 130pF sensor capacitor is 1% tolerance; I specified Murata GRT1555C1H131FA02*

I sent you a link in a direct message with the full data from the register experiments.

In summary here is a table with the results.

Does this align with your expectation?

Hey Arthur,

Thank you for providing those details.  I need a little time to go through all the data you shared in the direct message.  However, from your table, it does look like the results were aligning with my hypothesis, that you need a larger TC2 constant to accommodate a lower base sensor frequency than what was originally calculated in the tool.

Sure, no problem Patrick.  I think there may be some issue with Register 0x01 and 0x02 as well.  The oscilloscope method can't gather a large amount of samples, but when I watch each Config for a while, I see some measurement noise on all the Configs except Config 0 (and Config 5 which I added in the link I sent).  I don't have a good way to trigger the scope on these outliers. 

Hey Arthur,

I was looking over the figures you placed in the last column in your table you shared via direct messaging.   There I noticed that whenever LHR is noisy your L plot is also noisy.  Im thinking that this could possibly be improved by adjusting the RCount value you have in Register x30 and x31.  Is it possible you could share what value is in the register?  Also, if you increase that value for config 2 and 3, does the measurement noise decrease?

Hi Patrick,

The full register programming is captured in the Event Table for each config screenshot.  The write to register 0x30, 0x31 comes out to 0x258 (decimal 600) in all configs.

Thanks,
Arthur

Hey Arthur,

Thanks for sharing that, have you noticed any improvement when increasing that RCOUNT value?

Hi Patrick,

We can't increase RCOUNT due to power consumption targets.  We just need the best register settings that are compatible with an RCOUNT of 600.

Thanks,

Arthur

Hello Arthur,

I think a larger TC2 is the best path forward as of now.  Have you done any isolated measurements of the LC tank to see if the fabricated design conforms to expectation?

Hi Patrick,

I tried an updated Rpmax of 12 k ohms.  The calculator spreadsheet tells me "Too large" for this value of 12k ohms.  The results from testing look good though, you can see them at the link.  Please let me know your thoughts.

Hey Arthur,

I started looking into the unlocked tool, but was out of office yesterday.  I will try to have some information regarding that and your latest inquiry later this afternoon.

Hey Arthur,

So I went through some of the hidden cells and found that for Rpmin bounds, the tool compares a frequency ratio to some bounds.  The frequency ratio in this case appears to look like a cutoff frequency (fc=1/(2*pi()*Rpmin*Csensor)) over the sensor frequency found at D8.  From what I see, your Rpmin should yield a ratio value between 0.00025 and 0.1 or .25% and 10%.  How those ratio values are derived is not clear to me.  I will let you know if I find the justification for those values.

As for your latest results, I need some more time to look into it.  Trying to make sense of what was in the hidden cells took some time.

Hey Arthur,

So I do see a specification for Rpmax being between RPD∞ and 2RPD∞.  Perhaps the value you entered for Sensor Rp was a little off.  I would double check that with a vna or lcr meter and try to calibrate out the effects of the cable used to connect to the coil.

Patrick,

I agree that the spreadsheet does seem to use cell D9 (RPD∞) per the relationship  RPD∞<Rpmax<2RPD∞ to check the value in cell F22. The problem with Rpmax is that by my experimental results, a 6k ohms (in range) setting gives me worse performance and a 12k ohms (too large) setting gives me better performance.  So I have to go against the published guideline to get good performance.

Also, RpMIN continues to show me too small, can you tell me what check is being done there?

Thanks,

Arthur

Hello Arthur,

Im glad that the 12k gets you closer.  I would use what works and verify that it works on multiple boards before going to production.  You might want to go so far as to source parts from different vendors for each build, like one from digikey, mouser, and arrow.  I think that would guarantee different lots and a wider spread in variability.

As for Rpmin, I cannot really provide more than what I said 3 threads up.

One more thing about Rpmax: the Rpmax in Config 0 (which established my good working baseline) is actually 96 k ohms.  So that one is extremely far off from the guideline of RPD∞<Rpmax<2RPD∞.  (Rpmax would be 18.8*RPD∞.)

So an Rpmax of 12k isn't performing better than an Rpmax of 96k, but both perform better than an Rpmax of 6k.  The 12k setting is  less far outside the datasheet's recommended range than 96k is.

Hello Arthur,

Thanks for that feedback.  I will need to do some investigation on why that is so.  However, given that the original development team is not here anymore and the documentation provides few clues, I likely will not have good explanation anytime soon.