$20 LCR ESR Transistor checker project

[Feliciano]

As by your measurements, I don't mind disipating additional 100mW or so as long as the equipment work properly.

(Perhaps a more precise schematic could help).

[indman]

Besides what Kim Christensen reported earlier, R7 goes between pin 41 and Vcc. On that side of the PCB, pin 41 also goes to the tip of EN test point. Therefore, EN don't go to the Crystal array, that part of the schematic need rework. /Reset is pulled high by R14. And regarding C13 C10, it would have to be removed to be measured, because on circuit it detects a diode in both cases (and I ran some wires over it, so it would require extra work for my case). FWIW, with a DMM C13 measures 100nF or 470nF and I couldn't get a reading for C10.

OK! I updated the circuit diagram again, it remains to clarify where the PD0 (9pin) port of the controller is connected?
C13 - I believe that on your board it is set to 100nF. C10 should be 1nF, in principle it can be safely removed from the board, this should not affect the measurement results in original firmware. But it is advisable to check this!

And the new self tests/corrections:

The results of your tests indicate that the +5V voltage is poorly stabilized. You need to replace the 7805 with a better LDO.

[Yuriy_K]

From what I can see, it looks identical to mine. I'll do some double checking of the schematic against my unit:

Several years ago I assembled my testers on the ATMega 644. Now I don’t remember why, but I had to change some of the capacitance values. Here in your diagram I indicated my values...

Added. In the Hiland M644 C13, according to your circuit, the manufacturer initially installed 220nF.

[Feliciano]

it remains to clarify where the PD0 (9pin) port of the controller is connected?

Pin 9 goes to RxD, pin 10 to TxD and pin 7 of U8. And the rest of U8 part of the schematic seems right.

C13 - I believe that on your board it is set to 100nF. C10 should be 1nF, in principle it can be safely removed from the board, this should not affect the measurement results in original firmware. But it is advisable to check this!

IIUC, C13 is the Capacitor used for Adjustement, and C10 is the bypass Capacitor of the Aref, right? Yuriy_K thinks these Capacitors should be higher, though.

[indman]

C13 is the Capacitor used for Adjustement ?

Yes, this capacitor must be high quality and stable. In the config.h setting, you can disable this installed capacity so as not to unsolder it from the board. Instead, you can use an external high quality capacitor for the Adjustement procedure. Then you will need to measure this capacity 3 times in a row before the Adjustement procedure.

C10 is the bypass Capacitor of the Aref, right?

C10 is the setting of the ADC voltage scale switching speed. For correct operation of autors firmware, its capacity should not exceed 1nF. As I wrote above, it can be removed from the board and this should not affect the test results in any way.

P.S The circuit diagram has been updated once again in my post #9226

[madires]

One thing I did notice with this version is that there is a discrepancy in the capacitance measured depending on what mode it is operating in. Does your unit also show vastly different capacitance readings between "Probing..." mode and "LCR Monitor" mode for certain values? I did perform both a "Test" and an "Adjustment" thinking that was the issue but it wasn't. For example this is what I measured in uF:

Cap       "Auto"   "LCR mon"
1uF        1.039    1.038
10uF      9.929    9.953
39uF      36.29    37.02
120uF    99.79    120.1
270uF    155.6    262.5
680uF    328.3    599.5
1000uF  392.9    932.0
3900uF  3017     3657

There's something very wrong! The values in the normal probing cycle and in the C or RCL monitor should be nearly the same. For electrolytic caps a small difference (about 1%) is normal. This is caused by the different checks run in both modes before the capacitance measurement. Despite discharging and offset compensation a small charge difference can build up and lead to a small error. Anyway, both modes use exactly the same capacitance measurement functions. Your problem could be related to the power supply or some component drawing excessive current.

[Kim Christensen]

madres,

If "both modes use exactly the same capacitance measurement functions", shouldn't they both give the same reading even if there was a hardware fault?
The readings are highly consistent and repeatable in both modes. So there must be some differences between the two measurement modes firmware wise, because code is the only thing that changes between modes.
My unit was working Ok with the original Chinese firmware, but that firmware had a bit of a bug where it wouldn't consistently measure ESR so I decided to try changing the firmware. ie: It would randomly give me vloss only and other times give both vloss and ESR.
In the end if I can't figure it out, I'm OK with just using my unit in LCR monitor mode when measuring capacitors. But it'd be nice if it worked properly in both modes.

[Feliciano]

If "both modes use exactly the same capacitance measurement functions", shouldn't they both give the same reading even if there was a hardware fault?
The readings are highly consistent and repeatable in both modes. So there must be some differences between the two measurement modes firmware wise, because code is the only thing that changes between modes.

+1

madires:

As Kim says, if allegedly being the same algorithm for normal measurements and for LCR monitoring, I don't understand why the big inconsistence,

and on the other hand, why indman's configuration reflect way so different values than mine's for both scenarios. Maybe he set a very different compensation or default values? (because his readings varies a lot after adjustment, but still doesn't reach the expected values), and more important, why his LCR monitoring somehow works and mine doesn't.

Code: [Select]

#define CAP_FACTOR_SMALL      -25    /* -2.5% */
#define CAP_FACTOR_MID        -15    /* -1.5% */
#define CAP_FACTOR_LARGE      10     /* +1.0% */

Maybe Kim Chirstensen wants to try my attached binaries for a separate comparison.

Lastly, regarding the power supply, I modded the booster to 7V, and upgraded C9 from 100nF to 1uF.  For my config I didn't notice major difference. As shown in the photos versus my previous posts.

[Kim Christensen]

Maybe Kim Chirstensen wants to try my attached binaries for a separate comparison.

Here's my results with your firmware. I had the same thing as you. Looks better in auto probing mode, but now LCR Monitor mode is messed up with larger caps:

Cap       "Auto"   "LCR mon"
1uF        1.054    1.053
10uF      10.64    10.64
39uF      42.48    -----
120uF    144.5    -----
270uF    312.7    -----
680uF    740.4    -----
1000uF  1144    8.36uH 0.0R
3900uF  5212     8.36uH 0.0R

----- = no reading

I also noticed that if I short the leads in LCR monitor mode, then it reads 0.05R 8.36uH.

[Feliciano]

Anyway, both modes use exactly the same capacitance measurement functions.

You know the code better. Could it be the LCR monitor uses a particular pin that the normal testing function doesn't use, and we, or a least me defined it wrong?

Kim: Your equipment and mine behave the same. Have you tried the LCR monitor of 2hry firmware posted few pages back?

[madires]

If "both modes use exactly the same capacitance measurement functions", shouldn't they both give the same reading even if there was a hardware fault?
The readings are highly consistent and repeatable in both modes. So there must be some differences between the two measurement modes firmware wise, because code is the only thing that changes between modes.

Again, the same capacitance measurement function is called in both cases. The only difference is the frontend function (user interface).

As Kim says, if allegedly being the same algorithm for normal measurements and for LCR monitoring, I don't understand why the big inconsistence,

Neither do I. It's the first time that such an issue is reported. I've checked a 1000µF electrolytic in normal probing mode, C monitor and  RCL monitor running 1.51m and the values are fine. I think there is something else wrong.

[madires]

You know the code better. Could it be the LCR monitor uses a particular pin that the normal testing function doesn't use, and we, or a least me defined it wrong?

The monitor functions use probes #1 and #3, You could check if the probe pins and the resistor pins are all correct and that there are no additional components (besides the input protection).

[Feliciano]

I tried again 2hry's binaries, observing similar behaviour as indman's.

I also checked the configuration against the schematic, and seems correct. There is something else we're overlooking, or the schematic still doesn't match the PCB and/or values. (BTW: I think C26 is not on the PCB, the one near pin 17 is C8. Before modding, I measured a total of 600nF from Vcc to GND).

indman or 2hry: please compare my config against yours, so we can figure out why the same firmware work so different, and get the best of each settings. (Of course madires is welcome to have a look at it as well).

[Kim Christensen]

Feliciano,
Was looking at the 1.51m source on GitHub, and noticed there was a change to the file "cap.c". I wonder if you are using the same "cap.c" file as indman and 2hry.
There are some differences (lines 881 onward) in the routine "LargeCap(Capacitor_Type *Cap)" that may explain why your routine behaves differently than theirs:

old 1.51 code:

Code: [Select]

    /* consider zero offset */
    if (U_Cap > U_Zero)            /* voltage higher than zero offset */
      U_Cap -= U_Zero;                  /* subtract zero offset */
    else                           /* shouldn't happen but you never know */
      U_Cap = 0;                        /* assume 0V */

new 1.51 code:

Code: [Select]

    /* consider zero offset */
    U_temp = (int16_t)U_Cap;       /* explicit type conversion */
    if (U_temp > U_Zero)           /* voltage higher than zero offset */
      U_temp -= U_Zero;                 /* subtract zero offset */
    else                           /* shouldn't happen but you never know */
      U_temp = 0;                       /* assume 0V */
    U_Cap = (uint16_t)U_temp;      /* take result */

There may be other differences, but it's interesting that the differences are in the LargeCap routine...

[Feliciano]

Hmmm. I wasn't aware of that. According to your observations, the 1.51m I downloaded from github is the old one, from december I think.

UPDATE:
I applied my same configuration to 1.46m, and I get 997uF under normal mode, and 955uF under RCL monitoring, which seems a lot better, but makes me wonder there could be something in the code. I will try 1.48m tomorrow and report.

[carl1961]

Hmmm. I wasn't aware of that. According to your observations, the 1.51m I downloaded from github is the old one, from december I think.

UPDATE:
I applied my same configuration to 1.46m, and I get 997uF under normal mode, and 955uF under RCL monitoring, which seems a lot better, but makes me wonder there could be something in the code. I will try 1.48m tomorrow and report.

in the firmware folder is the fixed cap.c

[Feliciano]

yes, I know. I opened the 1.51m and found the code you mention, but around line 955:

Code: [Select]

    /* consider zero offset */
    if (U_Cap > U_Zero)            /* voltage higher than zero offset */
      U_Cap -= U_Zero;                  /* subtract zero offset */
    else                           /* shouldn't happen but you never know */
      U_Cap = 0;                        /* assume 0V */

    /* end loop if charging is too slow */
    if ((Pulses == 126) && (U_Cap < 75)) TempByte = 0;
   
    /* end loop if 300mV are reached */
    if (U_Cap >= 300) TempByte = 0;
And the file modification date is dec 2nd, 2023.

[Feliciano]

I have backported my 1.51m config to 1.48m, and it shows a capacitor close to the expected value either under normal measurement or RCL monitoring. Therefore something on the code and/or the configuration is messing my 1.51m. I can try to download and customize 1.50m tomorrow to confirm/discard.

[carl1961]

yes, I know. I opened the 1.51m and found the code you mention, but around line 955:

Code: [Select]

    /* consider zero offset */
    if (U_Cap > U_Zero)            /* voltage higher than zero offset */
      U_Cap -= U_Zero;                  /* subtract zero offset */
    else                           /* shouldn't happen but you never know */
      U_Cap = 0;                        /* assume 0V */

    /* end loop if charging is too slow */
    if ((Pulses == 126) && (U_Cap < 75)) TempByte = 0;
   
    /* end loop if 300mV are reached */
    if (U_Cap >= 300) TempByte = 0;
And the file modification date is dec 2nd, 2023.

Yes around  time of madires post

https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5234115/#msg5234115

[Kim Christensen]

Kim: Your equipment and mine behave the same. Have you tried the LCR monitor of 2hry firmware posted few pages back?

I guess I shouldn't have skipped that one, since 2hry's capacitor functions do work in both "auto probe" and "c-monitor" modes:

Cap       "Auto"   "C mon"
1uF        1.086    1.079
10uF      10.44    10.40
39uF      41.88    41.60
120uF    130.1    126.8
270uF    285.3    274.7
680uF    674.5    649.6
1000uF  1046     999.1
3900uF  4765     4688

[indman]

I guess I shouldn't have skipped that one, since 2hry's capacitor functions do work in both "auto probe" and "c-monitor" modes:

What m-firmware version number is shown on the start screen in this firmware?

[Kim Christensen]

v1.51m

EDIT: Though 2hry's menu item says, "C monitor" (it doesn't measure inductance) instead of "LCR monitor" like in yours and Feliciano's.

[indman]

Ok! In order not to be completely confused about the reasons for this behavior I suggest to calm down a bit, think and start testing again.
I will compile 2 firmware versions with the same configuration file settings, 1.50m and 1.51m. They will include all possible monitoring options - RCL monitor, L-monitor, C-monitor. And you check and compare the behavior of your clone in these modes and AUTO mode. Is that okay with you?

Test firmware 1.50mEn and 1.51mEn for FNIRSI LCR-TC1 clone. The configuration files are in the archive.

[2hry]

I can not confirm this behavior on my T7 tester with 1.51.
Which is now modified because i have destroyed my adc inputs PA1,2 and 3(the reference???how did i do that).
Now i´m testing on PA0 PA6 and PA7, to which i botched 2 wires.
Lifted the broken pins of the atmega, and removed the TP_CAP.
So I dont have the reference on PA3, and the TP_Cap on PA7 anymore.

To compile, I downloaded the sources from Transistortester-warehouse, and changed the cap.c which is in an extra folder. Then only updated the pins for my tester, and the resistor divider for the zener test. (the cap factors are unchanged)

I have tried different options in config.h, but it is working as expected in normal and LCR mode.

What i did change earlier, are the 680R and 470K resistors.

Indmans schematic looks complete to me, except(as Feliciano pointed out)
 C26 is not on the PCB, and C8 near pin 17. 

[Feliciano]

Tried indman's new builds, with the same 1000uF subject, configured for -1% of compensation for this range, and adjusted:

1.50m (ignoring the first measurement in each case):

• R monitor = nothing, as expected
• C monitor = between 961uF and 967uF
• L monitor = nothing, as expected
• RCL monitor = between 960uF 968uF
• Normal mode (continous) = between 996uF and 1003uF

Notice there are some uF of variance for consecutive measurements. The repetitiveness of measurements have been already addressed: We know this is not a medium-high precision instrument, so I don't complaint.

1.51m (ignoring the first measurement in each case):

• R monitor = nothing, as expected
• C monitor = between 978uF and 981uF
• L monitor = nothing, as expected
• RCL monitor = between 978uF 984uF
• Normal mode (continous) = between 1012uF and 1015uF

I think these results are acceptable, and maybe it can be fine-tuned with compensation for each of the 3 ranges. Still, there's some difference between normal mode and monitoring mode. Being the same algorithm, I don't see the reason.

What I'll do next is to backport my 1.51m config to 1.50m, because it works fine with older m-firmware (i.e. 1.46m and 1.48m) but screws 1.51m monitoring mode.