Digital LC Meter

[()blivion]

Hello everyone.

Sooner or later, I'm planing to recreate *THIS* LC meter, and make some improvements to it. I was wondering if anyone had any opinions on it and some of the modifications I plan to do to it. My objective is to get a good RF LC meter so I can start getting into minor radio circuits and hopefully broaden my sphere of knowledge. And also have fun.

The main thing I want to do is increase the free running oscillators frequency. I figure I want to do this because, someone somewhere said that it is best to measure an inductor or capacitor at the frequency you plan to use it at. And that persons reasoning seemed valid. As I understand it, they basically said inductors and capacitors have different effective values at different frequency's do to combined stray components and what have you. So, measuring it at one frequency may give you a completely different reading than what it actually is going to effectively be on another.

I also plan on using a different model PIC μC, the PIC18F13K50. I chose it because I own some already, it is small, fast, it has a hardware multiplier, and has an internal comparator. If I am interpreting the datasheet correctly, the comparator is guaranteed to run at ~2.5 Mhz, but typically it can get to ~6.6Mhz. Here is the relevant table I figure this from...


[SUB]1/T[SUB]RESP[/SUB] (response time) in seconds[/SUB]

 

[dr pepper]

I have built one, mine uses the comparator within the '628 so theres less comps.
Its very good and very accurate well worth the bother to build.
100khz seems to be a popular frequency for testing passives, the meter I built goes from around 30kc up to 100kc, the freq isnt fixed and varies with the measured part.
The only problem with using really high freq's is being able to measure bigger c's and l's, maybe you could auto range the measurement freq.

 

[()blivion]

I worried about frequency range too, so I have come up with two basic ways to read a widely varying frequency, each with it's own pros and cons.

(1) Counts per unit time
The first method is to let the frequency to be measured increment a counter for a specified amount of time, then read the number of counts and convert that to frequency. I figure this is good for really high frequencies, and should by nature be more tolerant of inconsistent period. The problem I have with it is that for low frequencies, the error starts to climb really high do to not having a reasonable amount of counts for the specified time frame.

(2) Time per single count
The second method is to start a timer, and measure the input signal from one falling/rising edge to another. I figure this is better for lower frequencies, and allows me to actually measure the stability of the oscillations. The problems with this is that it's hard to measure the period of a wave the higher the frequency is, thus requiring a faster and faster clock to get a decent number of counts to work from.

The obvious solution to the problem with method (1) would be to just use a large enough time frame for capturing counts, that the need to read frequencies which could cause significant error would never arise. For example, if the time frame was 1ms, then one would only start to see a ±5% error in frequency measurement if the frequency was 20KHz or lower. This fix however starts to cause new problems, because a large time base with high frequencies will end up creating a very large count. This leads to either having to locate the MSD and cut off any digits below a certain point, or throwing the whole number into the math routines and simply let the extra precision get rounded off. (floating point helps with this too) Luckily, there is little to no risk of register overflow, because it would take more than 16.7GHz to be able to roll a 24 bit counter over in less than 1ms.

The only solution to problem (2) is to use as fast a time base as conceivably possible when counting the period, to increase the resolution of measurement. For example, if the frequency was 600KHz, then it should take 1.666us for each edge of the waveform to pass. With a clock of 12Mhz, and thus one count a period of 83ns, the number of counts that would happen in the above time would be 20, this brings the estimated precision to 1/20, or about ±5%. The good thing with method (2) is that accuracy gets better and better the slower the frequency to be measured is, similar to method (1), but opposite in direction of effectiveness.

What I'm probably going to do.
As you may or may not have realized, there is a unique secret option number (3), which is to do both methods while being sure to overlap their range. This should allow for greater precision all around. The higher a frequency gets, the more precise option (1) becomes, and the lower the frequency gets, the more precise option (2) becomes. Using the above example frequencies for opposite methods expresses this quite well. At 20Khz for method (2), the accuracy would be about ±0.2%. Consequently, if method (1) were used to measure 600Khz, the error would also be something like ±0.2%. At some center area (call it the "grey zone") both methods will have about the same precision for a given frequency, so using either method won't really matter. With the above numbers, the system comes to a point at about 100Khz, where the indicated precision is about 1%. At this point, the option of doing both methods then averaging the result could possibly improve the precision to it's final level. Provided the system clock is stable to equal or better precision and no other factors play a significant role, this point would probably be the absolute maximum precision of the hardware under worst case part values. It would be best if this area were simply avoided, but it really doesn't matter. The precision relative to universal standard measure will be determined by the calibration capacitor. And at ~$5 apiece for ±1% high grade low thermal drift mica capacitors, ±1% is probably as good as the precision could ever get.

(Note: Math subject to law of reasonable approximation.)

 

[dr pepper]

I was gonna suggest autoranging between 1 and 2, I think this process is used in commercial designs.
I considered it one time when I wanted to read a shaft encoder, is was 4096 pulses per rev, and rotated at speeds from one rev a minut to 3000 rpm, so the freq was a few hz to a couple hundred khz.
Because it was a one off I cheated and used a 4040, made life way easier.
I dont see any reason why you couldnt dump the frequency into a timer i/p, you could use the capture/compare and timer 1 module on a pic, timer1's good for 50mc's.

 

[()blivion]

Because it was a one off I cheated and used a 4040, made life way easier.

I was going to do pretty much exactly the same if I made the main oscillator run in the VHF range. The MC74AC4040 specifically, as it can go up to ~140Mhz.

I dont see any reason why you couldnt dump the frequency into a timer i/p, you could use the capture/compare and timer 1 module on a pic, timer1's good for 50mc's.

I am going to have to do this no matter what. Unfortunately, the internal comp of the 13K50 can't be set to route it's output both to a pin, and to internal capturing mechanisms at the same time. The only way to use the comp as the oscillator, and get it's output back into the chip, is to expose all the comps pins externally, attach it to all the passives, and then rout it's output pin to the input pin for the CCP/timer1. And sadly, the internal comp can only run at ~2.5 Mhz, so this configuration can't ever get up to VHF frequencies.

I would rather make the measuring oscillator run in VHF/UHF, as ISM bands in that area are about what I expect to use the measured caps/coils for. But I am conflicted because I also don't want to deal with HF board layout issues on this project, or add more parts to the design. But if commercial meters measure at low frequencies, and the measured parts are accurate for VHF/UHF, then I think that 2.5Mhz will probably be fine.

I have built one, mine uses the comparator within the '628 so theres less comps.
Its very good and very accurate well worth the bother to build.

Do you also happen to have enough equipment to test if a VHF/UHF oscillator, built using parts measured from this device, is accurate to within ~1% of what the calculated resonant frequency should be? That would really tell if staying with the low frequency design is worth it or not.

If you could do this for me, that would be great. (Edit, No obligation of course.)

 

[dr pepper]

Nope not really, my accuracy quotes where measuring a cap/inductor then comparing it to a good quality lc meter.
I've built filters up to the uhf region the odd time and I've got coils very close, but alas at those sort of freq's its impossible to know whether the inaccuracy is my meter or the layout for the filter.
So I cannot answer that question, and not really being a radio man I lack comprehensive gear for that.

I was going to mention about the layout, if you are going to uhf then you'll need to apply the usual layout rules and use screening cans, but it sounds like you know more than me on that front.

I've never used the 13k50, does that device have slew rate control, if so slowing down the transitions will releive some of your issues at uhf.
I have a frequency counter that uses a 74hc, I put a 74ac in it and it'll go to higher freq's with it, but the counter makes a racket in the uhf band and wipes out a scanner tuned to most freq's in the uhf band, I need to make a screening can for it, another day.

 

[()blivion]

A few minor things to add.

First, I have attached the LTSpice sim of the oscillator for this project (LC parallel Osc.asc). Note that it currently operates at about 1.6Mhz, I probably will increase this farther in the real hardware. Also note that the voltage "Add_Ccal" is just simulating the 5v logic that adds Ccal to the oscillator. It is the measurement of the difference in the two frequencies, one with and one without Ccal, that gives the device it's accuracy. The switching mechanism is just a generic voltage controlled switch. I am considering using a small solid state relay as opposed to a conventional relay for performance and reliability reasons. Relays are antiquated technology, I don't see the reason to include them in new designs.

Second, I have attached a VHF LC oscillator design that I have been playing with (RF Osc 2.asc). If It can work I would consider using it in this circuit as the basis of the measuring oscillator. It would need to be fed into a high speed Schmidt buffer, and then either fed into the before mentioned high speed 4040 to obtain a scaled frequency, *OR* the max frequency lowered to <50Mhz, and fed into CCP/timer1.

Third, is that running with a really high frequency would also increase the small component value resolution. A small component is only going to change the running frequency by an equally small amount. If it is too small, it may approach the limit of the systems ability to resolve the difference. A higher running frequency improves on this problem greatly because the metrics for counting can be smaller, making it harder for the smaller changes to go unnoticed. It would be nice to be able to resolve low enough values to be able to measure even PBC stray components. But that is unlikely and probably best left to board design and calculation really.

 

[()blivion]

I've never used the 13k50, does that device have slew rate control

It dose have slew rate control... for the port pins, and for the MSSP. (Edit: Not that MSSP matters for this of course.)

...it sounds like you know more than me on that front.

No, not likely. Radio is my weak point in electronics.

 

[dr pepper]

Makes sense, I cant look at your files right now, I'm not allowed spice on my works pc.

The thing about using the 4040 is that you can get most of the rf stuff in its own screening can with feedthrough caps to the real world.
Schmidt buffers can be difficult at uhf, using a prescaler that has an unprescaled o/p might be the answer.

I only know what I have to about radio, it seems to be a subject on its own, sometimes it seems like a strange world to me, logic ones and zero's are much more definative.

 

[()blivion]

I guess I sorta lied about the inner workings of the 13K50's comparator. . . /)

It is in fact possible to get it's output to a pin and to the internal data bus simultaneously. What you can not do is internally direct it's output to increment/de-increment Timer0/1/2/3, the ECCP, or any other peripheral. Which is really quite a bummer when what you want to do is high speed counting and measuring like I do. The only way to do things entirely internal to the PIC is to use the comparators interrupt flag and have the interrupt handler deal with things manually. I would rather take the extra pin hit and make use of a peripheral, as interrupting main program operation at a 2.5Mhz rate with a 12Mhz system clock is pretty much impossible.

The whole mess is a fairly obscure problem really. There are only five places the outputs of the comparators go.

(1)The data bus.
(2)The comp interrupt
(3)The comp output pin
(4)The very specific SYNCCOUT
(5)The non-descript "to PWM logic"

(1)The first can only be accessed manually by setting RD_CM1CON0 and reading the bus.
(2)The second should be self explanatory... it is the interrupt.
(3)The third is of course external to the PIC, and thus invalid.
(4)The fourth only goes to the internal SR latch inputs, where the use is very specific.

(5)The interesting one, the non-descript line "to PWM logic" would seem to indicate that the output does in fact go to the ECCP, and it does. But close examination of the ECCP shows that it is intended only for the Auto-Shutdown feature, it doesn't work as an input for the capture mode. It really should be called "PWM Auto-Shutdown flag", or something like that since that's the only damn thing it can do.



It's kinda funny, if I had the PIC's schematic, I could probably add just a handful of logic gates to give it the functionality I need. It's a trivial difference in circuitry for a modest gain in functionality IMO.

 

[Mr RB]

I agree, they could have internally connected the comparator outputs to some useful things, especially the CCP input.

Normally I just wear the loss of an extra pin and connect the comparator output pin to the CCP1 input pin, like this one on my high res cap meter (RA3 connects to RB3 CCP input);

**broken link removed**

 

[()blivion]

That's a pretty neat meter RB. And even though you're using a slightly different oscillator, it's is still quite similar to what is going on with this meter. No offence intended, I'm just talking tech, but I like this meter over yours because by using an LC resonant tank, one gets an oscillator which can be used to measure capacitors and inductors. I don't think it matters for overall measurement accuracy though.

Some questions...
I looked at your web page and it looks like you basically use the first method that I describe in post #3. Is this correct?

Also, have you ever used the measured caps to build an LC RF oscillator? Was the resonant frequency a decent match to the indicated capacitance?

My DMM has a capacitance measurement setting with a range that covers all the most common uses for capacitors. Great for building simple filters and checking if a cap is good. It's not so good for small caps though. I think it stops at around 10nF to 1nF or so, which is fairly reasonable. The good thing about my meter though is that it was made by a "tiny" little local company you have probably NEVER heard of... known as "Fluke Corporation" . So it wouldn't be all that hard for me to physically drive it to them in person and have them calibrate it for a modest fee. But that's entirely unnecessary and far out of my budget.

The only reason I want to build an LC meter, like I had indicated above, is so I can get into building resonant RF circuits, which are going to use small caps, and of course, equally small inductors.

 

[Mr RB]

Answers;
The method I used in neither your 1 nor 2, but a new optimised method lets call it "option 3". I used the CCP to get "time per single count" or actually to get TIMER1 elapsed time per 16 input pulses, then add this into an accumulator variable. If the value is not high enough it repeats contiguously as many times needed until it gets (say) >1 million in the accumulator. Always having a time count of >1million forces accuracy (resolution) to always be >X. Then the actual period of any pulse is known by dividing the accumulator total with the total number of pulses that were counted.

So to answer your question it really measures "time period for an oscillator pulse", but does it in a massive contiguous accumulated way so there is a lot of data to get a really high resolution.

Next, no I didn't use the caps to make an LC RF oscillator.

Re the Fluke multimeter inbuilt cap meter, I have a few Fluke meters and the cap meters are not great. It reads within about 5% of the real cap value and are best used as a "cap ok/broken" test.

Part of the problem with a LC type cap meter is the relationship of cap under test to frequency is not linear. I think the formula then needs square roots to determine the cap value (or the L value) from the measured frequency. That takes a lot of processing and will hurt accuracy compared to a nice linear C=period RC osc like in my meter. I would expect my cap meter to outperform that LC meter in measuring capacitance, although of course mine won't measure inductors.

If you want a good LC meter, this link is about the nicest I've seen, and is also available as a kit or just as a programmed PIC. Personally if you want to get into RF I would get his kit as it looks quite well designed and laid out, it is a refinement from his first LC meter so it has been well optimised over time;
https://www.rfcandy.biz/communication/imp_lc.html

That page also covers some of the math required for that LC osc.

 

[()blivion]

Sorry, Hi. Took a while because I wanted to give a proper, lengthy response.

So, lets see if I understand your measurement algo right. Minus the added complexity of the 16 prescaler, essentially you are counting the elapsed time of the period over and over again(essentially "method 2" in post 3), adding that time up into an accumulator until a certain threshold is exceeded. Then you divide the accumulated by the number of elapsed periods(averaging the result)? Which should essentially be the number of times you have added to the accumulator (times 16 for the prescaler).

The last part may be getting past me, but I think I generally understand otherwise. The accumulator bit is quite interesting, I hadn't thought of doing anything like that. I was considering doing some kind of scheme that measures the frequency/period multiple times then averages the results and displaying it. But after thinking about it, I came to the conclusion that displaying this alone will give a false sense of accuracy as you are filtering out any jitter that a real part may display, do to some what low Q factor. Following this logic, what I think I would rather do instead is measure the frequency and measure the drift, so I can simultaneously display the average frequency(part value) and the Min/max(tolerance). Hypothetically this will reveal a parts 'Q' factor, as changes in value may appear when the leads are moved, temperature drifts, micro-phonics, and so forth. All very important things to account for when making a realistic radio circuit as I understand.

Next, no I didn't use the caps to make an LC RF oscillator.

That's unfortunate. I would really like to see demonstrated if a low frequency measurement of a cap/inductor faithfully represents it's high frequency value. I just shuffled through my locally saved schematic archives and found the link that I remember reading about HF/LF measurement discrepancy. I guess its not that all caps and inductors will change value at different frequency's. But rather that HF toroidal inductors will change value from low to high frequency. I don't plan on making really high power radios, so I don't think I will need anything other than air core inductors. So, I think I may abandon doing the measurement in the frequency I intend to use the parts in, it doesn't seem to have much of an advantage.

*HERE* is the project with the information I was referring to. I personally would almost rather get the stuff for that meter if it wasn't both analog and only for measuring inductors. I have a box full of all kinds of Hf CMOS clocks, lots of ranges. Then again, I could try and make some kind of hybrid of the two designs or something. Who knows.

Re the Fluke multimeter inbuilt cap meter, I have a few Fluke meters and the cap meters are not great. It reads within about 5% of the real cap value and are best used as a "cap ok/broken" test.

That's understandable though. Especially if it's a model intended for repair work and not analytically/engineering work. The average electrolytic is only rated for a surprisingly high ±20% of it's nameplate anyway. So, accuracy up to 5% could even be considered excessive for such things. You're not going to make any VHF radios with it, but simple filters, buck/boost/buck-boost converters, and so forth are perfectly fine at 5%. Hell, the world is not even perfect so they say.

Part of the problem with a LC type cap meter is the relationship of cap under test to frequency is not linear. I think the formula then needs square roots to determine the cap value (or the L value) from the measured frequency. That takes a lot of processing and will hurt accuracy compared to a nice linear C=period RC osc like in my meter. I would expect my cap meter to outperform that LC meter in measuring capacitance, although of course mine won't measure inductors.

Yes, whole bunches of maths. It's all in the link I provided. Also how he managed to actually implement it in code form on the MCU is in there. I personally will be relying heavily on the fact that certain routines can compress down considerably when the PIC has a hardware multiplier. As for accuracy, I don't see how you expect the accuracy to suffer very much. He states that the mathematical accuracy is better than 1% with the 24 bit float routines. Compared to his version, I plan on using the full 32 bit routines plus having larger numbers to work with. Now I'm not great with any math that can't be done on your fingers, but I don't think an order of magnitude improvement on his implementation is unreasonable with these changes. In the end, I think the absolute accuracy, (relative to the universe/truth), comes more down to oscillator hardware and stray values and Q factor and so on. And math aside, an RC implementation is just as susceptible to such things.

If you want a good LC meter, this link is about the nicest I've seen, and is also available as a kit or just as a programmed PIC. Personally if you want to get into RF I would get his kit as it looks quite well designed and laid out, it is a refinement from his first LC meter so it has been well optimised over time;
http://www.rfcandy.biz/communication/imp_lc.html

That page also covers some of the math required for that LC osc.

Not to ruffle your feathers. But that meter is virtually a carbon copy of the meter I linked to in post #1. Yeah, it's details are different, but it's... the... same... meter... Same comparator based parallel oscillator, same maths, about the same MCU. Honestly, I would question if that person didn't just blatantly copy VK3BHRs design, rework it a bit, then claim it as his own design. Though I suppose independent discovery is possible, and there are probably only so many ways one can measure inductors and capacitors digitally. But as far as I know, VK3BHR is the originator of that circuit. Yes, there existed other digital LC meters before his. Yes, he reused a lot of other peoples work, and he gives credit to other people for much of the things he did. However, his exact design exploded in popularity, and now there are literally hundreds of clones out there of it. All very much like the link you provide, though they usually admit to getting the idea from VK3BHR up front. [SUP][1][2][3][4][/SUP]

Almost every one calls that design the VK3BHR meter, so I can't help but conclude he was the originator. And much about the link you provide screams clone. So I can't really think of what I have to say that's positive about it honestly /). A kit/PCB would certainly be nice I guess, but I think I would rather build one myself from scratch. Like I said, measuring jitter/tolerance would be amazing to have. And I think I can do that myself. Make it to understand it, and to customize it, and of course to have it.

Again, not trying to offend, just calling it as I see it.

 

[Mr RB]

...essentially you are counting the elapsed time of the period over and over again(essentially "method 2" in post 3), adding that time up into an accumulator until a certain threshold is exceeded. Then you divide the accumulated by the number of elapsed periods(averaging the result)? Which should essentially be the number of times you have added to the accumulator (times 16 for the prescaler).

You got it, it is basically; total_time_accum/total_pulses, which gives an average time/pulse.

...
The last part may be getting past me, but I think I generally understand otherwise. The accumulator bit is quite interesting, I hadn't thought of doing anything like that.
...

Yeah it's one of those quirky "tricks" I like to think up on the spot to solve particular problems. The benefit is that since the accumulator is always >2million for ANY size cap, the measurement resolution is the SAME for any size cap, and is always very high. So the measured resolution is ALWAYS better than 1 part in two million for any cap value.

... what I think I would rather do instead is measure the frequency and measure the drift, so I can simultaneously display the average frequency(part value) and the Min/max(tolerance). Hypothetically this will reveal a parts 'Q' factor, as changes in value may appear when the leads are moved, temperature drifts, micro-phonics, and so forth. All very important things to account for when making a realistic radio circuit as I understand.
...

Frequency measurement gives a lower measurement resolution, even over a long period like 1 second. For instance with my RC osc a 10nF cap runs at 435Hz. If you measure freq over 1 second, that is 435 pulses, giving you a reading of 434-436 or +/-1 part in 435 error. My system gives a 1 part in 2 million error!

The problem with freq measurement gets worse if you expect to use the same oscillator to test all caps, as a 10pF cap might give ok resolution at 435000 Hz, but a 1uF cap gives a freq of 4.35Hz, measured as only 3,4 or 5 pulses over your gated second, a massive error.

...
(re using the tested caps in RF) That's unfortunate. I would really like to see demonstrated if a low frequency measurement of a cap/inductor faithfully represents it's high frequency value. I just shuffled through my locally saved schematic archives and found the link that I remember reading about HF/LF measurement discrepancy.
...

I don't think thats a big issue. I've measured a heap of RF type caps (ie ceramics in the few pF range) and they measure just fine on my meter allowing for the range of tolerance. So if I measured a heap of 15pF caps the values all average around 15pF +/-. You would have to assume their values would all average around 15pF too used in RF circuits, that's what they were designed for and labeled for.

...
As for accuracy, I don't see how you expect the accuracy to suffer very much. He states that the mathematical accuracy is better than 1% with the 24 bit float routines. Compared to his version, I plan on using the full 32 bit routines plus having larger numbers to work with.
...

It comes back to that initial data you have, before the calc. Re what I said above if you use the same osc for all cap values then some will have very poor initial measurement resolution. My measurement system fixes that and gives really high measurement resolution for ANY cap value.

Now because your proposed LC uses a square root it compounds the problem. The square root is not the math, but is caused by the "rootLC" inherent in the oscillator, this means the resolution problem is squared by changing cap value. ie the ratio of cap to freq is a square, and your resolution gets linearly worse with freq. So doing 24 or 32bit math is almost irrelevant if the initial measurement has a massive error.

...
Not to ruffle your feathers. But that meter is virtually a carbon copy of the meter I linked to in post #1. Yeah, it's details are different, but it's... the... same... meter... Same comparator based parallel oscillator, same maths, about the same MCU.
...

An easy assumption, but if you google "LC meter" that same parallel comparator LC oscillator is used in just about everything since the dawn of time. And the math will likewise have to model that osc.

I have no connection in any way with the link I posted, but for many LC meter kits that i have seen that one is very nicely polished as a kit and has some polished autocalibration features etc. If you are set on making your own PCB etc then a "nicely polished kit" is of little use to you.

Re an LC meter, a few people have asked if my meter could be modded somehow to measure L as well as C, but there is no easy way I can think of. What it really needs is a good reliable linear LR based oscillator design and I don't have one. Some of my rough attempts at a linear freq:L LR osc failed miserably as the inductors behave differently at different currents. If you can come up with a really nice LR osc that has a freq linear inverse to the L value it would be easy to make a high resolution L meter that outperforms all the LC meters on the market for all the reasons mentione here.