PIC based high-resolution cap meter

Discussion in 'Microcontrollers' started by Mr RB, Jun 27, 2011.

Joined:
Jan 4, 2007
Messages:
21,223
Likes:
644
Location:
Ex Yorks' Hants UK
hi CIII,
Roman has not posted here for a very long time.
He has a web page 'Roman Black' , try a Google search
E

http://www.romanblack.com/

2. CesarIIINew Member

Joined:
Aug 22, 2006
Messages:
3
Likes:
0
I see.
I'll try to disassemble the code and try to make some mods. Although it may me easiest to write another one. Whatever.
CesarIII

Last edited: Sep 10, 2016
3. eblc1388Active Member

Joined:
Jan 25, 2005
Messages:
2,228
Likes:
18
Location:
UK
I have built the HiRes Capmeter and it is really a helpful tool to own.

A few posts popped up in this long discussion thread regarding excess error about the linearity of measurement results, which were explained away with reasons of bad bread boarding and various other factors. The author Roman Black maintains that the meter is perfectly linear because the underlying principle is so simple. A capacitor is charged and discharge between two well defined voltage levels of 33.3% and 66.6% supply voltage via a fixed resistor and thus the frequency of switching is proportional only to the capacitance. Yes, very true indeed.

The following describes how the problem was located and how I resolve the issues and ended up with a great meter.

After building and rebuilding the meter for a second time, I still encountered the same non-linearity problem that several posters here had reported. You can check by yourself too. Get ready a 22pF(less than 100pF will do) capacitor and a 1000pF or higher capacitor. Measure the capacitance of each and then do a final measurement with both capacitors in parallel. If your measurement result of the paralleled capacitors don't match the sum of the two individual measured values to within a few picoFarads, then your meter is non-linear.

By then I was convinced that the meter is non-linear, but why? It seems all Roman Black said in his previous posts were indeed simple truth which is indisputable. In desperation, I poked around with my scope probe on various PIC pins and did the measurement again. Then, I noticed something unusual. The pk-pk voltage level on the PIC comparator inverting input(RA0) is not the same when measuring different capacitors. In theory, this should be switching between 33% and 66% of 5V, and should be the same as the Vref pin(RA2). Capacitance calculation depends on this voltage to be switching exactly as the Vref, namely 33.33% and 66.66% of supply positive. Suspecting the comparator inside the PIC, I built on my breadboard the same oscillator using the well known LM393 instead. Well, the result was still the same, the pk-pk voltage was not stable. It seems the comparator inside the PIC was not the culprit after all.

In order to locate what actually causes the discrepancy, I simulated the oscillator circuit in LTspice. The simulation result is attached below. In the simulation, I used a control switch U1 to change the capacitor value from 0.2uF into 200pF and observe the change of pk-pk voltage on the capacitor(Vcap). The oscillator frequency changes from 700Hz up to 200KHz. In the top graph, the difference in levels is clearly seen which matches exactly my physical scope test on the breadboard. In the expanded time scale graph below, both the Vref and Vcap are plotted. The reason is now plain. The comparator output is NOT switching well after Vcap has reached Vref, in both directions. The switching only comes after some 300ns later. Well now you know this is the propagation delay of the comparator. It is this propagation delay that led to the non-linearity when the capacitance is small and the switching frequency is in the high 200KHz range.

Now I have located the cause, what can I do about it?

My first solution is to lower the switching PIC comparator frequency ten times from 200KHz to 20KHz so the propagation delay affects the linearity less. This is easy to do by using a 10 times higher charge/discharge resistor and changing the scaling factor inside the PIC firmware to ten times more. The result is satisfactory but the range of the meter had decreased by 10. Now the meter can only measure a maximum 5uF capacitor before overflowing. Obvious that's not good.

My final solution is to do away with the PIC comparator and use an ultra fast external comparator LT1016 instead. I used the typical circuit inside the data sheet and got very good results, as seen in the attached image. The difference I got in the above linearity test was within half a picoFarad. The modified schematic is also attached should you wish to make the change. I have to stress that this will only made a difference if you often measure small capacitors in the pF range. It might not worth the effort for capacitor higher than several thousand picoFarad.

Again, my thanks to Roman Black for providing us such an useful meter in the first place.

• Informative x 3
• Thanks x 1
4. DaveNew Member

Joined:
Jan 12, 1997
Messages:
-
Likes:
0

Joined:
Sep 11, 2004
Messages:
6,359
Likes:
586
Location:
ONLINE

Excellent work, well done.
JimB

• Agree x 1
6. jjwMember

Joined:
Apr 16, 2012
Messages:
267
Likes:
15
Location:
Helsinki, Finland
ONLINE
If the propagation delay is known, it might be possible to correct it's effect in software, at least to some degree?

7. eblc1388Active Member

Joined:
Jan 25, 2005
Messages:
2,228
Likes:
18
Location:
UK
IIRC, Roman Black had once commented there isn't memory space left in the 16F628A to include additional features. A PIC with larger memory space might be required for a piecewise linear lookup table or a correction polynomial.

8. throbscottleWell-Known Member

Joined:
Feb 1, 2012
Messages:
1,805
Likes:
113
Location:
Nuneaton, Warwickshire, UK
Thanks for this eblc1388! I thought it was my pcb layout or crowded wiring or use of a switching regulator that was causing mine to have the non-linearity. Or something else of my own fault.
I don't think I'm up to modifying the PIC's code, but I'll have a go at re-building it with a superfast comparator!
Thanks

9. eblc1388Active Member

Joined:
Jan 25, 2005
Messages:
2,228
Likes:
18
Location:
UK
Yes, its a bit difficult as Roman Black had hard coded the value in firmware.

I have replaced the values inside the firmware by two EQU constant statements at the start of an asm file so user can easily change their values and reassemble the file to get the HEX.

Changing the value might be preferable for some users especially if they use very low temperature coefficient metal foil 10K resistor for RCAL and 270pF mica capacitor for input capacitor, as they can do away with adjustment POT and fine tuning the proportional constant value instead.

Code (text):

; original File = D:\down\CapMeter_HiRes_V11.hex

processor 16F628A
#include <P16F628A.INC>
__config 0x3F02
;   _CP_OFF & _DATA_CP_OFF & _LVP_OFF & _BODEN_OFF & _MCLRE_OFF & _PWRTE_ON & _WDT_OFF
;   & _HS_OSC
;
;  The scaling factor 919(dec)= Hex 0x397 is found hard coded in firmware,
;  therefore it has been replaced by a EQU constant statement PConst_H & PConst_L
;  at all these locations, so changing the values would be easy by changing the
;  next two lines
;
;  To reduced the comparator toggle frequency to 1/10(1/5) of
;  the design by RomanBlack, using a 100K(or 50K) resistor instead of a 10K one.
;
;  As a result, the displayed value is 10(5 if uses 50K) times bigger as captured frequency is
;  0.1(0.2)times the design value. This however, can be rectified by changing the
;  proportional constant from 919 to 9190(4595). i.e. from 0x397 to 0x23E6(0x11F3)
;
;  Because of the now low toggling frequency, max. cap value measurable is 5uF(10uF)
;
;  Proportional Constant
;  ==================================================
;  PConst_H equ 0x03   // as from RomanBlack original
;  PConst_L equ 0x97   //

PConst_H equ 0x03  ;
PConst_L equ 0x97  ;

Attached Files:

• CapMeter_HiRes_V11_eblc1388.asm
File size:
56.4 KB
Views:
118
Last edited: Jan 27, 2017

Joined:
Apr 12, 2012
Messages:
470
Likes:
37