Spacing of Coil Springs (Multi-Channel)

Hello,

in my application I'm planning also up to 12 coils close to the other. Coil diameter as per Workbench should be about 12mm in diameter, the distance (centre to centre of next coil) about 25mm, thus making a space of 13mm between (PCB) coils. The 12 Coils are connected to 12 LDC1000's, all beeing active at same time.

Is that a problem? Required resolultion is about 25um. What should I take care of?

Gerardo

Here are some questions that you might want to ponder:

What is the target you are trying to sense (e.g. is it fixed axially, how is it moving relative to the coils, are you trying to discern material)?

What is your coil-to-coil orientation and position?

If you do not need absolute but relative Rp or L values (you can also adjust for the difference in software) then you would have to separate the tank capacitance of each coil (dependent on position) to avoid cross-coil noise.  In other words, the separation in Hz between the resonating frequencies depends on your coil-to-coil orientation and position.

For instance, at high frequencies, coils separated by diameter-lengths oriented in a circle need to be 500-800kHz apart for relative sensing of a fixed material at a fixed height.

Thanks

Hello Charles,

the target I'm trying to sense is a planar stainless steel spring, which will be deformated repeteadly (10..20 Hz) against the coil. The goal is to measure the absolute deformation of this element (in 0.05mm precision is enough). Distance between coil and spring is between 0 and 5mm.

The device should be calibrated only once in lifetime, the deformations happen 24h/365d, meaning it stands almost never still.

This done for 12 springs of about 10mm wide, spaced as stated before. Do you think I will get some crosstalk effects? How to avoid them? Springs & separation can not be adjusted. Are any coil shapes better than others for this kind of application?

Regards

Gerardo

Hi Gerardo,

Are these springs arranged in a grid, on a circle, or in a row (or some polygon, or stacked)?  The closer grouped they are the more prone to crosstalk.

For 100 steps (5mm, and 0.05mm precision) and for 10-20Hz it is definitely possible, and the crosstalk will be minimal, but I would avoid them by sizing the tank cap differently, alternating per sensor if they are oriented in a row.

The stainless steel spring IS the sensor; ends of the spring should be hooked up to INA/INB; see the marketing page: http://www.ti.com/ww/en/analog/dataconverters/inductance-to-digital-converter/application.html.   I would add an inductor in series if the inductance of the spring itself is low.  The lower the inductance of your steel spring the lower the SNR, unless you increase the tank cap to match.  This is because the highest frequency is 5MHz.

Thanks,

Dear Charles!

I have built a device, that creates  highly accurate "topographic carpet  maps" of big  rotating cylinders during rotation(diameter up to several meters, surface speed up to around 60 meters per second, delta of  the radius within less than 5 millimeters typically) with a single eddy current sensor, scanning the surface at well-known points in space. The accuracy of the created map is around 5-20µm depending on the position information of the sensor.

During my holidays the last several days, I accidentally came across  your  new LDC 1000 – and I was somehow shocked from  the wealth of ideas coming to my mind  and  new applications possible with this new chip. After immediately ordering 5 EVBs, organizing ideas and viewing  TI  material and blogs and some metrology-papers I want to follow the following idea very first:

Instead of using one single sensor (with a well-known spatial (µm!) position) I could use a redundant sensor-array consisting of - let's say - 5 (in axis direction) x 4 (in perimeter direction) sensors arranged in matrix- form. I could use the redundant information from these sensors, to be able to recover the surface profile without knowing the exact radial position and angles of the sensor array, but only the current perimeter angle of the sensor and the current position in direction of the axis (which is much simpler than knowing everything with the required accuracy).

For doing this, the array scans one slice of the surface, as the cylinder rotates. For such a measurement the angular resolution in direction of rotation would be selected in a way that all of the 4 sensors of each column are scanning the same perimeter location sub sequentially, leading to a scanning frequency of about 5-10 kHz. After a slice (containing 4-times redundant data for 5 sensor column positions) is finished, the array moves one sensor-to-sensor distance further along the axis and does the same again. This is repeated for the complete cylinder, leading to highly redundant data which can be mapped with least square methods underlying good error models.

Acquiring redundant data in that way should allow to recover the complete surface data  without having exact radial and angular information about the sensor array. Of course all sensors need exact linearization and zeroing. The success of getting a highly accurate surface map depends on the accuracy and  resolution of the single sensors at the given scanning speed of - lets say - 10 kHz (à perimeter resolution of  6mm)

The radial resolution should be below 0,5 µm and accuracy should be around 1µm or better (per sensor) for 10 kHz scanning rate with simultaneous (not multiplexed!) scanning of all 20 sensors.

The sensors I usually take  have a coil diameter of  ~15 mm  air coil (no ferrite) and are proved  to work at the desired accuracy (after exact calibration and software-linearisation)  in a range of around  5 mm ( tested only for single sensor use.).

When I arranged multiple sensors up to now,  the sensors had to have a distance of 3 times the diameter of the sensor between each  sensor, leading to rather big sensor configurations. (In the past I have chosen that, because these are typical distance values recommended from sensor-manufacturers for such applications)

Here are my questions:

1)      Is it feasible for you to get the desired results in the desired quality using LDC1000s? What do you consider to be the main barriers to be mastered  from  “LDC and Senosr-Point-of-View” (besides doing the maths for post processing)?

2)      What would lead to more accurate results: to scan at highest frequency possible for each sensor and filter (low pass, mean,…) afterwards in software? Or to scan at lowest frequency possible (just high enough to get sufficient resolution of points on the perimeter) and do only very minor filtering in software (having considered the spatial aliasing- distances for both approaches, of course…)

3)      According to the manufacturers of industrial EC-sensors, sensors in such arrays need to be “synchronized” in frequency, so that they do not interfere. My typically used sensor boxes, provide inputs and outputs for that…
With the LDC 1000 such synchronization does not seem to be possible or foreseen – is it? If yes, how is that done?

4)      If not, I guess the only choice is to decouple the sensors as good as possible – I have been reading though suggestions in other blogs (distance, ferrite between the sensors (??), different frequencies,…)
Which minimal distances between the sensors would I need in my application?

5)      Using different frequencies by choosing different capacitors seem to follow specific math that I don’t understand (according to your post to Gerardo Vanoni on Nov. 7^th 2013 and the subsequent from Nov. 12^th 2013). What is the relationship between  decoupling of adjacent sensors and their frequency difference (and possibly the accuracy/resolution and the sensing frequency)?

6)      If different frequencies are used: can the distance decrease  then? By how far? Is there any literature on that?

Thank you, for working through that all! I am very curious about your opinion and hopefully your answers on that.

Another application I will follow (possibly together with some students) is the idea, of a real-time multipoint/ multimode detection of the motion trajectories of copperwound bass string, which seems to be unsolved up to now…

Franz Auinger

Hello Franz,

Definitely an interesting application.

To respond to your first question - if the 15mm diameter coils provide the desired resolution at 5mm distance, then the array should be provide the desired performance.

2) Generally, it is better to use the lower data rate (higher response time value) rather than to use a higher sample rate and average multiple measurements. I would like to add that averaging is fine, as the LDC measurements have a gaussian distribution and so they improve with sqrt(# ove averages).   

3) Actually, for the LDC you want to use different sensor frequencies so that the different sensors do not interfere with each other. This can be done by adjusting the sensor cap and hence changing the sensor frequency. If the sensors are more than 1coil diameter apart, then there is a much lower amount of interference.

4) At 1 sensor diameter separation (e.g. if your sensors are 15mm in diameter, separate them by 15mm) you should see minimal interference; If the sensors are physically closer together then you will need to increase the frequency difference.

5) The amount of acceptable interferrence from other coils depends on the application.

6) I assume that you are referring to distance between coils rather than distance to target. The sensing range to the target is pretty much constant across sensor frequency. If I had to come up with a simple approach: the distance+frequency  sum should be >100%. In other words, the difference in frequency as a percentage + the distance between sensors as a percentage of coil diameter should be more than 100. This guideline breaks down with very close frequencies or very close sensors, and may be overly resrictive for some configurations.

Hallo Chris,

thank you for your fast and detailed response. Reading your comments, some other questions arised:

In 2) you stated, that using the lower data rate (higher response time value) is better than averaging later in software... On the other hand, you point out, that averaging is fine (guassian distribution).

Q1: What is the real reason why higher response time values are better?

Q2: What is the LDC 1000 doing, what I can't do afterwards?

Q3: Do I loose information when trying to scan faster? (maybe the sensor restarts a measurment-cycle after each scan and needs time to settle?)

I understand, that the sensor oscillates with let's say around 1MHz - continuously "updating" the impedance at each oszillation. Remember, my target is moving rather fast and the surface is not necessarily flat.

Q4: So what is the mathematical function, that is executed between the readings of one sensor? Do I get a linear mean value? An RMS of all values between two readings? Only a sampled value just before (or when exactly?) the reading? A continuously running (maybe weighted) average?..

Higher scanning frequency (lower response time values) would give me a higher resolution of where the measurement took place.  Otherwise according to your answer, it is better to scan slow.

Q5:What are the criterions for deciding what the best trade-off would be? (Although Q5 sounds stupid also for me, I can't answer it without knowing how the output-data is generated).

Q6: As you state, that averaging is still fine (I interpret that as: Still fine, also for low scan frequencies), it sems that there is no everaging that is done inbetween two scans. Therefore again: where is the best compromise between scanning frequency and filtering afterwards and WHY...

Meanwhile I have been playing around with my first small "array" (2x2 with Eval-Boards) with LabView. Great, to have that all prepared for LabView and Matlab from TI side - also for multiple sensors over USB...

As soon as I have understood these aquisition things better, I will start developing the FPGA- program for simultaneously reading these 20 SPI channels in real-time.

At the moment, using the USB-eval-boards the mapping of values to the surface is difficult (not possible?) because they are not time-stamped.

Doing this with an FPGA with separate SPI-Lines for each LDC would improve that because the data can be acquired in real time, but it would take lots of FPGA IOs to handle it.

Q7: What is the recommended way to save FPGA-IOs without loosing timing information?

Multiplexing sensors is not an option in my application, because doing the maths later on would require to have all 20 sensors acquired synchronously and being able to map the values of the sensors exactly to a position on the cylinder while this is moving fast... Therefore the only chance to save IOs is multiplexing the SPI-Interface...

At - lets assume - 5 kSps it should be possible to connect 10 LDCs together, sharing SCLK, SDI, SDO and using a decade counter for generating chip-selects with one single FPGA-Out. But:

Q8: do I need to read the DRDYs in order to get the data read out from all 10 LDCs within the 200µs?

Q9: Is there a way to read with minimal number of IO-lines without loosing the information, WHEN the data was acquired? (time resolution: scan frequency should be sufficient)

Q10: Is there a good pattern available, how to do that for the LDC 1000?

Thanks a lot for your delighting answers to my previous post..  I am looking forward to your new answers - for the moment especially for questions 1-6. Q7-10 may be answered by pointing me to documents that you surely know of and that I didn't find up to now.

Franz

Hello Franz,

Q1/Q2) Due to timing uncertainty, it possible ot miss a count of the reference during the measurement. This error will of course average out but with more averages you are more likely to lose a few edges. This is not a significant effect.

Q3) no, the sensor does not need to restart after each measurement.

Q4) the measurement is technically the number of counts of the reference frequency in the specified number of sensor periods.

Q5) The measurement interval varies based on the sensor frequency (higher frequency = quicker measurement -> reduced measurement resolution).

Q6) A moving average filter is a good approach.

Q7) This depends on the data rates you need. If the data rates saturate the 4MHz SPI of the LDC1000, then you may not be able to simply use a dedicated CSB per LDC1000 and share the SCLK/SDI/SDO pins.

Q8) You should read the INTB pins if you are trying to synchronize across multiple LDC1000s.

Q9) I will need to look into this further.

Q10) Please clarify this question.

Regards,

ChrisO

Dear Chris,

Your post made me thinking a lot.

Since resolution is a major aspect in my approach, I tried to find out how to calculate the resolution of the “fsensor” measurement. I invested this whole (holi)day to find out more than the hint you gave me in your answers Q1-Q4. The data sheet and all Blogs/Posts/ANs I was studying do not give any hint, about the relationship between sample-rate, response time the external oszillator-frequency with the actual resolution of the to-be-calculated L (or fsens).

In my scanning app with moving target it is essential to know, to which positions the values that I get belong to and what accuracy I can expect under specific conditions (I know, absolute accuracy can only be quantified for a given hardware-configuration, a specific temperature, a specific material after creating a LUT,…) but resolution fundamentally depends on the LDC1000 and its internal processing. I guess that the 24Bit/16Bit are no effective values over all possible register configurations.

So I am trying to get a picture out of the following puzzle-pieces:

*) This "Response Time" value is given in "cycles" in the Evaluation Software.

*) The sensor frequency is derived from counting cycles (- not necessarily exactly the way it is but hopefully sufficient for calculating the actual  resolution for a given configuration -) between let’s say two equally directed  zero-crossings (for one complete sensorperiod) of our sensor-signal at resonance, delivering counts, how many quartz-cycles a fsensor-period does last.

*) The "output data rate" is proportional to fsensor and inversely proportional to the value Fcount from the 3 Registers.

According to these „pieces“ I assume the following (trying to interpret Q4 correctly):

For an 8 MHz – Quartz and a sensor-resonance frequency of 4MHz and tresp=192 Cycles only 64cycles can be counted within a space of 128 cycles of one Sample-Cycle. In fact for this setup the resolution of the counts is only 1/128 of 8 MHz = 62,5kHz…This would never lead to the required accuracy.

Same for the longest possible tresp=6144Cycles would still only lead to 36866 increments which is still far away from 24 bit resolution.

Since this cant’t be the case I am kindly asking you to answer the following questions for me (and possibly others):

Q1: Please provide a general calculus for calculating the effective resolution of the output-values at given parameters: tresp, Fext, and one of the values fsensor/Fcount/outputdatarate (at least for L- calculation).

Q2: Please provide a calculus for the effective resolution of the output “Proximity Data” register also, for a given configuration (RPmin, RPmax, Amplitude, and whatever defines it and whatever maximizes or reduces it).

Q3: Please do explain, what the value for tresp really stands for?

Q4: If it is not intended that the real meaning of tresp is explained to a user, what is the sense to introduce another factor of 3 in the formulas?

If the resolution in the example above is calculated wrong, then from my perspective at least two approaches may lead to increased effective resolution in the chip:

-->  to use an internal frequency that is much higher than the Quartz-frequency from outside (then stability of the Quartz-Frequency would even be much more critical than stated in other posts)

-->  to take much longer internal observation windows to get much more counts. This would lead to longer intervals of observation (longer than sample period). It is essential for me, in order to be able to map the provided value to a “area” of a moving target.

Sure there are many other possibilities to provide higher resolution. As TI customer I’m not interested how it works internally, but what I can expect from the chip in a given situation. Therefore:

Q5: Please explain if simply higher Quartz-Stability is needed for getting internally high resolution within the sample. Then it’s easy to understand, because gathering a new value happens solely within one single sample-period then.

Q6: If no internal frequency- multiplier is used, the sample is building a mean over more than a sample period. In that case: over which time? Over how many samples (running / weighted average)?...

Since I see no need to disclose information about how the LDC1000 works in detail for answering these questions, it would save effort for all sides to provide such information in the data sheet in the future. I is needed to use the piece in a professional way (and answer questions of increasingly interested colleagues and students, willing to use it).

Thank you for all your effort on that.

Best regards!

Hi Franz,

Q1) The effective resolution is the count you obtain at the frequency of interest. Please refer to the measuring inductance section of the datasheet. The effective resolution is 1/Fcount. Combining multiple measurements can provide improved resolution.

Q2) I will need to get back to you on this.

Q3) tresp, is the programmed response time, which is set in the LDC configuration register address 0x04.

Q4) The 3 is used internally. It seems that we have not been as clear in the datasheet on this as it could have been. 

Q5) A higher stability clock does improve the L measurement; the stability across temperature and low drift is desirable, and the jitter is also a consideration. The LDC1000 does not internally multiply the reference, so for many applications it is fine to use commonly available crystals (e.g. the one on the LDC1000 EVM).

Q6) The measurement interval occurs between the first zero crossing of the tank and the Nth zero crossing, where the N is based on the programmed response time.

Please review the EVM schematic, which is available at http://www.ti.com/lit/ug/snau150a/snau150a.pdf in section 4.1.

Finally, regarding the previous post Q9: to measure L, you may be able to simply measure the time between subsequent edges of the INTB instead of using the SPI, if INTB is in DRDTB mode.

Hi Chris,

Thanks again for your answers.

Regarding Q1 (after reading Q6):

--> Please confirm or reject (correct):

*)  For Fext=8MHz, fsensor=4Mhz, tresp=192 --> Resolution of all is 1/128 when looking only to one sample?

Regarding Q6: Could you please help me, what you mean with "based on"? How many crossings are taken exactly?

Thanks for pointing me to the schematic. I already studied it, but it did not help further with coulpling multiple slaves to a master with using as minimal io-count over SPI. That was, what I was asking for - sorry for being imprecise on that. Do you have something in this direction?

Regarding old question Q9: I was already on the way on that, setting up a first test when I got your answer this morning. Anyway I need to configure every single chip over SPI first, so I still Need to find out, how to safe IOs for doing that. But: to what extent does INTB jitter with respect to the original value? is it generated without any delay and jitter so that it does not introduce more "noise" on the measured value?

Looking forward to your answers (also for Q2).

Franz Auinger

Hi Franz,

Q1) yes, you are correct in your calculation. The frequency resolution available is based on the measurement time - the longer the frequency is measured, the more resolution in the measurement.

Q6) The measurement time is the period of the sensor frequency multiplied by the number of cycles of the sensor; the number of cycles is programmed in the register.

old Q9) The delay should be reasonably consistent; as for jitter I don't think it will be a significant error in the measurement.

Regards,

Chris O

Dear Chris,

I think, something went wrong in your last answer: Either Q1 or Q6 is correct. Taking the example from Q1 (resolution was 1/128!) your answer in Q6 would lead to the following:

measurment time = period of sensor frequency * tresp of the Register = 1/(4MHz) * 192 = 48µs. 

In that case the resolution would be 1/(8MHz * 48µs)=1/384. (Here we have this obscure factor of three again).

Q1: So what is correct here? The Q1-version or the Q6 version? Or both and I didn't understand...

Q2: Do you already have information regarding the resolution of the Rp measurement?

Thank you!

Best regards!

Franz

Dear Chris,

do you have further feedback/ answers for me or a contact that can provide me with further details?

Thank you!

Franz

Dear Chris,

no further comment to my questions? Anyone else you could point me to?

Regards!

Franz

Dear Chris,

I am still very interested in the discussed topics and I am still waiting for your replies.

Best Regards!

Franz Auinger

Hello Franz,

I apologize for the delay. As I understand, you are worried about the cross-coupling of the coils. The 'safe distance' will depend on the strength of the magnetic field, which is a function of the coil geometry, material, and amount of power you are driving the coils with. I would like to give you a numerical answer, but I am afraid I cannot in this case. I would strongly advise you to perform simulations on the designed coils.

Best Regards,

Natallia Holubeva

Hello Natallia,

thank you for your response!

My question(s) refer to the page one of this thread - to the topics I discussed with Chris Oberhauser. Could you help me on that?

Franz Auinger

Hello Franz,

Unfortunately we do not have specific information about Rp resolution. It is greatly dependent on your set up: coil geometry, composition of the target, distance between them, etc.

Best Regards,

Natallia Holubeva  

Sorry, but if noone really reads, what is asked for, then this Forum is not worth the effort (at both sides).

I wanted to introduce this piece of interesting new TI-Technology to students (up to 100 Automation Engineering Students per Semester) and encourage them to apply it in their industrial projects, but when neither the data sheet gives exact answers nor detailed questions in a Support Forum from TI lead to consistent answers I am curious to know, what goes wrong here.

Franz Auinger

Head of Department Electrical Engineering

Upper Austria University of Applied Sciences

Hello Franz,

I apologize for your experience. Could you please help me understand what exact answer you are looking for?

Best Regrds,

Natallia Holubeva