$20 LCR ESR Transistor checker project

[Yuriy_K]

The actual cap measures around 1.1nF.

Perform the marked items in order without turning off the tester. See if AComp = 0 changes, this value should not be =0.

[hapless]

I get the same numbers after that. Looking at the code, I think I what I see is that AComp = NV.CompOffset = Offset (please correct me if I'm wrong), but I don't really understand why 0 is bad. Offset looks like it can be positive, zero, or negative. So I'm still stuck.

[Yuriy_K]

So I'm still stuck.

Increase the capacitance on AREF to 10nF and repeat steps 1, 2, 3 of the previous message. From my experience AComp = 0 - incorrect tester calibration.
What does not suit you in 1.13k if it works correctly on your hardware? RLC measurements are an order of magnitude more accurate and my changes allow me to expand some measurements for Mega328.

I hope you read these calibration features - excerpt from autocalibration:

"The analog comparator voltage offset is automatically corrected when measuring capacitance (in normal test mode without auto-adjustment) if the capacitor is in the range of 100nF to 3.3μF. The offset for the built-in reference is defined in the same way. Before making auto -adjustment for the first time, measure the calibration capacitor with a capacitance value between 100nF and 3.3μF at least 3 times so that the tester can correct the offsets mentioned above.Usually, the first measurement will result in a lower capacitance value, the second one will result in a higher capacitance and the third one will be the most accurate. Both offset values will be displayed at the end of the procedure."

[indman]

The tester is rock-solid stable with 1.13k firmware, but with 1.49m sometimes it shows 0pF between probes during self-test while other times is the usual 47-51pF.

I also get 0pF on my MEGA4GSL with ATMega644 during the adjustment process, but this does not cause me any concern, since a subsequent similar procedure returns normal values ​​ 40-45pF. It is important that these values ​​are fixed in the profile that you save. I do not observe any problems with measurements due to this effect on firmware 1.49m, so you can safely work with the device.
Regarding Acomp=0 :
Usually, on devices with ATMega644, a high-quality calibration capacitance above 100nF (usually ceramics) is connected by default to one of the ATMega ports. Then the
#define HW_ADJUST_CAP
setting should be enabled in the config.h file, and the port to which calibration capacitance connected in file config_644.h :
#define TP_CAP           PA7       /* test pin for self-adjustment cap */
#define ADJUST_RH     PC5       /* Rh (470k) for fixed cap */
If there is no such hardware capacitor, then
Yuriy_K wrote above, it is necessary to measure the external calibration capacitance on the test contacts 3 times in a row to get the correct AComp value, which will be valid for the subsequent adjustment procedure.

[Substance]

A couple of months ago, I got interested in experimenting with a component tester. I bought an LCR-T4, but what I received was a clone which had a fake Atmel MCU, so I could not use the open-source software to modify and improve the tester. So, I started to create a tester from an Arduino Pro Mini compatible board with a genuine ATmega328P, together with the salvaged LCR-T4 LCD and new components.

First, I built the component tester that is compatible with LCR-T4 hardware. I tried the available v1.13k firmware binaries to see it run for the first time. Then I moved on to the v1.48m software distribution and created a makefile project for Microchip Studio for AVR and SAM devices.

Just to see what difference it would make (not a lot) I use hardware SPI for the LCD, and I had to dive into the v1.48m code to make all necessary changes to GPIO and ADC ports. I have made many (cosmetic) changes to the display output. I use a (small) subset of the available test functions to make it all fit into memory. To locate and to fix all the mistakes that I made in the process, I used serial output for code debugging and tracing.

Thanks to the available hardware and software documentation, and thanks to the numerous questions and answers from the users on this forum, I was able to get pretty good results. It may need further experimenting and tweaking. Next, I will look at the v1.49m code and merge it into my tester software.

@madires, @indman, Karl-Heinz Kübbeler (and many others): you do a very nice job making this project popular and accessible to many electronics enthusiasts!

I posted a few pictures at “Show us your $20 Transistor Tester enclosures and mods”.

[madires]

Bohu has updated the Czech, German and English PDF documentation for 1.49m: https://github.com/madires/Transistortester-Warehouse/tree/master/Documentation

[oitar]

2. Done, similar results to the original port. In fact that's what I did earlier, using the "Battery Votage" testing pin. They all have a problem with voltages below 1V(at the pin).

When the voltage at the ADC pin is below the voltage of the internal band-gap reference the tester switches to the band-gap reference for better resolution and accuracy (both OSHW firmwares do this). Most likely there's a problem around the AREF pin. We use a small cap at the AREF pin to buffer the reference voltage (switched between Vcc and internal band-gap).

Quick recap: T7 Plus, v1.1 with a mega324pa(allegedly original), with erroneous measurement of all ADC inputs below 1V, affecting zener and resistance measurement. As suggested by @madires and @indman, tried removing O/V protection, different firmwares(k and m), changing(or removing the AREF cap) with similar results.

Eventually I found a workaround- reading more about the internal bandgap reference on atmega chips, I found someone mentioning that switching from VCC reference to bandgap is a lot slower than the other way around. So I just changed the priority( inside ADC.c) from VCC to bandgap(changes shown in orange, original statement in green:


    /* auto-switch voltage reference for low readings */
    if (Counter == 4)                   /* 5 samples */
    {
      if ((uint16_t)Value >= 1024) //if ((uint16_t)Value < 1024)       /* < 1V (5V / 5 samples) */
      {
        if (Ref == ADC_REF_BANDGAP)//if (Ref != ADC_REF_BANDGAP)     /* bandgap ref not selected */
        {
          if (Cfg.AutoScale == 1)       /* autoscaling enabled */
          {
            Channel &= ~ADC_REF_MASK;     /* clear reference bits */
            Channel |= ADC_REF_VCC;//Channel |= ADC_REF_BANDGAP;   /* select bandgap reference */

            goto sample;                /* re-run sampling */
          }
        }
      }
    }

Now everything works fine. Thanks for all suggestions!

[indman]

Eventually I found a workaround- reading more about the internal bandgap reference on atmega chips, I found someone mentioning that switching from VCC reference to bandgap is a lot slower than the other way around.
Now everything works fine.

Well, if your decision does not affect the results of other measurements. In any case, your controller turned out to be non-standard. This is not surprising, given the rise in price of the original ATMEL chips.

[madires]

Eventually I found a workaround- reading more about the internal bandgap reference on atmega chips, I found someone mentioning that switching from VCC reference to bandgap is a lot slower than the other way around. So I just changed the priority( inside ADC.c) from VCC to bandgap(changes shown in orange, original statement in green:

That's one reason why there's an intentional delay when switching the reference voltage and also a dummy conversion. The ADC_LARGE_BUFFER_CAP option is meant for Arduinos with a 100nF cap at AREF and basically increases the delay by a factor of 100. But for investigating the strange behaviour of your tester's MCU you could increase the delay in the unmodified source until the measurements are fine. It would be interesting to know how large the delay needs to be, in case someone else runs into the same problem.

ReadU() in ADC.c:

Code: [Select]

    /* wait some time for voltage stabilization */
    #ifndef ADC_LARGE_BUFFER_CAP
      /* buffer cap: 1nF or none at all */
      wait100us();                   /* 100µs */
    #else
      /* buffer cap: 100nF */
      wait10ms();                    /* 10ms */
    #endif

For the waitX() functions available please see wait.S.

PS: Without setting the default ADC reference to the internal band-gap reference your changes disable voltage measurements with the band-gap reference.

[oitar]

That's one reason why there's an intentional delay when switching the reference voltage and also a dummy conversion. The ADC_LARGE_BUFFER_CAP option is meant for Arduinos with a 100nF cap at AREF and basically increases the delay by a factor of 100. But for investigating the strange behaviour of your tester's MCU you could increase the delay in the unmodified source until the measurements are fine. It would be interesting to know how large the delay needs to be, in case someone else runs into the same problem.

ReadU() in ADC.c:

Code: [Select]

    /* wait some time for voltage stabilization */
    #ifndef ADC_LARGE_BUFFER_CAP
      /* buffer cap: 1nF or none at all */
      wait100us();                   /* 100µs */
    #else
      /* buffer cap: 100nF */
      wait10ms();                    /* 10ms */
    #endif


Well, that's the thing: I doesn't seem to change anything! I am using a 1nF cap(even removed it previously, suggested by @indman), so I'm working within this section:

Code: [Select]

    /* wait some time for voltage stabilization */
    #ifndef ADC_LARGE_BUFFER_CAP
      /* buffer cap: 1nF or none at all */
      wait100us();                   /* 100µs */


With default value of 100us, one measurement takes about 2sec, with wait1ms() it takes about 4sec, with wait10ms()- about 6sec, with wait 100ms()- 23sec, and with wait200ms() one measurement took 1min and 3 seconds to complete. For the sake of sanity I stopped it there. The reading is exactly the same.
It looks like the internal reference never gets down to it's intended value.

PS: Without setting the default ADC reference to the internal band-gap reference your changes disable voltage measurements with the band-gap reference.

But isn't the alteration I showed previously doing exactly that: starting the ADC sample with the internal band-gap by default, and only if it reads 1024- switch to the VCC reference? I did a zener test within the whole range: 1 to 24.5 V, and the readings are smack-on. Same with various resistors. I am quite convinced the precision hasn't suffered at all. Semis check fine, only checked few caps, but they look ok too.

[madires]

Well, that's the thing: I doesn't seem to change anything! I am using a 1nF cap(even removed it previously, suggested by @indman), so I'm working within this section:

Maybe it's not a delay (voltage stabilization) issue at all.

With default value of 100us, one measurement takes about 2sec, with wait1ms() it takes about 4sec, with wait10ms()- about 6sec, with wait 100ms()- 23sec, and with wait200ms() one measurement took 1min and 3 seconds to complete. For the sake of sanity I stopped it there. The reading is exactly the same.
It looks like the internal reference never gets down to it's intended value.

That's interesting! The delay should happen only once when switching from Vcc to band-gap. Increasing the delay would increase the time of the voltage measurement by the same delay. In the Zener check the voltage is measured several times. Hence the maximum delay should be: number of calls of ReadU() * delay. Have you tested that with the original code or your modfied ReadU()?

PS: Without setting the default ADC reference to the internal band-gap reference your changes disable voltage measurements with the band-gap reference.

But isn't the alteration I showed previously doing exactly that: starting the ADC sample with the internal band-gap by default, and only if it reads 1024- switch to the VCC reference? I did a zener test within the whole range: 1 to 24.5 V, and the readings are smack-on. Same with various resistors. I am quite convinced the precision hasn't suffered at all. Semis check fine, only checked few caps, but they look ok too.

To make your changes work you need also to change the default voltage reference, which is done here:

Code: [Select]

  /* prepare bitfield for register: start with AVcc as voltage reference */
  Channel &= ADC_CHAN_MASK;        /* filter reg bits for MUX channel */
  Channel |= ADC_REF_VCC;          /* add bits for voltage reference: AVcc */

So you start with Vcc and set Vcc again when Value >= 1024 (your mod), i.e. the band-gap reference isn't used at all. And since the measurements are fine with just the Vcc reference the actual problem is related to the band-gap reference. Let's try something else. Take the original ReadU() and change

Code: [Select]

      if ((uint16_t)Value < 1024)       /* < 1V (5V / 5 samples) */
to

Code: [Select]

      if ((uint16_t)Value < 900)
The idea is to check if the voltage of the band-gap reference might by a bit too low.

[Swainster]

Just adding another data point on the LCR-TC2 to this thread

Old version vs new version, both bought from "Z industry store" on Aliex about 18 months apart.

Old version:

• Generic case (with modification)
• f/w v2.3E
• PCB T7-PLUS v1.1
• Atmel marked 44 pin MCU
• Hard key cap under membrane - easy to press
• Calibration mode
• Reliably identifies inductors 10uH and above
• More parameters listed for some components e.g. jfets
• Hard power off via U3? (i.e. for when the s/w crashes)

New version:

• Customised case based on original generic case
• f/w v3.1E
• PCB T7-PLUS v2.0
• Unmarked 32 pin MCU
• No key cap under membrane - difficult to press
• No calibration mode
• Does not reliably identify inductors with high DC resistance e.g. small axial inductors
• Fewer parameters listed for some components e.g. jfets, but higher resolution on some measurement e.g. inductance
• Hardware reset key

Overall, the new version is not as nice as the old version, but it mostly gets the job done. The transistor parameters seem to vary a lot between the 2 units, or some are missing altogether, however it seems to reliably identify the transistor type and pin out, so I think that it is still a useful addition to the electronics toolbox. That said, if you want to tinker with the workings, this is not the tool for you.

[oitar]

That's interesting! The delay should happen only once when switching from Vcc to band-gap. Increasing the delay would increase the time of the voltage measurement by the same delay. In the Zener check the voltage is measured several times. Hence the maximum delay should be: number of calls of ReadU() * delay. Have you tested that with the original code or your modfied ReadU()?

With the original code. If I use the modified one, the reading is correct regardless of time.
When original code is used with various wait functions, it is definitely taking that long as mentioned.

To make your changes work you need also to change the default voltage reference, which is done here:

Code: [Select]

  /* prepare bitfield for register: start with AVcc as voltage reference */
  Channel &= ADC_CHAN_MASK;        /* filter reg bits for MUX channel */
  Channel |= ADC_REF_VCC;          /* add bits for voltage reference: AVcc */


You got me here
As soon as I change the code you specify to: Channel |= ADC_REF_BANDGAP;, the wrong reading comes back- even with my modification still in place!

So you start with Vcc and set Vcc again when Value >= 1024 (your mod), i.e. the band-gap reference isn't used at all. And since the measurements are fine with just the Vcc reference the actual problem is related to the band-gap reference.

I'm afraid I cannot argue with that. For voltages between 3 and 24 V, the error is around 1.5%. Under 3 V it gets a lot worse: -3% at 2.0V, -5% at 1.5V, -9% at 1.0 V, and -18% at 0.5 V

Let's try something else. Take the original ReadU() and change

Code: [Select]

      if ((uint16_t)Value < 1024)       /* < 1V (5V / 5 samples) */
to

Code: [Select]

      if ((uint16_t)Value < 900)
The idea is to check if the voltage of the band-gap reference might by a bit too low.

Result:
Votage Input, V:     Reads as, V:
       10.5               10.66
       10.0               10.13
        9.5                 9.622
        9.0                 9.090
        8.5                 8.586
        8.0                 2.165
        7.5                 2.025
        7.0                 1.885
        6.5                 1.754
        6.0                 1.614
        5.5                 1.474
                  .........

[indman]

oitar,your board has a QFN44 form factor controller. Have you checked the reliability of the soldering of its contacts with a multimeter? The thought that there is a bad contact or not enough connection with GND does not leave me.There have been cases when soldering all the contacts of the processor fixed the problems.

[oitar]

oitar,your board has a QFN44 form factor controller. Have you checked the reliability of the soldering of its contacts with a multimeter? The thought that there is a bad contact or not enough connection with GND does not leave me.There have been cases when soldering all the contacts of the processor fixed the problems.

Visually all solder points look ok. All GND pins of the chip read properly. I will try and re-solder all pins later.

Just for interest's sake, if the internal bandgap reference cannot be used(for whatever reason), can I swap it with the 2.5V external? This would give a better precision for voltages below ~2.5V. After a few attempts to modify the ADC.c code, I keep getting "timeout" errors.

[Sudya]

Comparison of LCR-TC2 testers.
The firmware for the converted (LGT8F328) to ATMega328P is added to the folder with the sources.
" alt="" class="bbc_img" />
" alt="" class="bbc_img" />

[madires]

Result:
Votage Input, V:     Reads as, V:
        8.5                 8.586
        8.0                 2.165

Seems to follow the lower threshold for switching to the band-gap reference. There are some measurements which use the band-gap reference directly. Do you also get strange values for ESR and inductance?

[madires]

Just for interest's sake, if the internal bandgap reference cannot be used(for whatever reason), can I swap it with the 2.5V external? This would give a better precision for voltages below ~2.5V. After a few attempts to modify the ADC.c code, I keep getting "timeout" errors.

As soon as you use an external voltage reference at AREF you can't use the internal ones anymore, i.e. neither Vcc nor band-gap.

[oitar]

Seems to follow the lower threshold for switching to the band-gap reference. There are some measurements which use the band-gap reference directly. Do you also get strange values for ESR and inductance?

Definitely when measuring resistance. Don't have proper samples(with known parameters) regarding ESR or inductance.

[oitar]

As soon as you use an external voltage reference at AREF you can't use the internal ones anymore, i.e. neither Vcc nor band-gap.

I was hoping it's possible to just make the program use the voltage from the external source, but consider it the bandgap voltage, without re-wiring.
Sorry this is just my ignorance talking, I'm still learning the internals of an AVR.

[elecdonia]

Just adding another data point on the LCR-TC2 to this thread. Old version vs new version, both bought from "Z industry store" on Aliex about 18 months apart.
   Old version:
      Generic case (with modification)
      f/w v2.3E
      PCB T7-PLUS v1
      Atmel marked 44 pin MCU

MCU very likely to be Atmel ATmega324.  Why do I think this is so?
   1) No Chinese MCU comes in 44-pin package (yet)
   2) 6-pin header near top edge of PC board is standard Atmel ISP programming interface. Chinese MCU don't use ISP. It is unique to Atmel

Some modification of existing -K or -M firmware may be necessary, but it certainly is feasible to replace the Chinese firmware because this MCU is actually mega324. Also possible to upgrade MCU to mega644 or mega1284.

New version:
Customized case based on original generic case
f/w v3.1E
PCB T7-PLUS v2.0
Unmarked 32 pin MCU

MCU likely to be LGT8F328P
Several people on this forum report successfully replacing LGT8F328P with Atmel ATmega328P. Hardware mod is simple because only a few pins have different functions. However existing -K or -M firmware needs modification for mega328P to work with this PC board. When time permits I plan to try this myself.   

[Yuriy_K]

Using symbols_32x39_hf.h. For the correct display of contact numbers, you need to correct the line:
PIN_LEFT | PIN_BOTTOM, PIN_RIGHT | PIN_TOP, PIN_RIGHT | PIN_BOTTOM, /* UJT n-type */

[Calambres]

I've just received a T7-H multi-function tester (V1.1 E) and it seems there is no way to perform the auto calibration, neither with the supplied 3 pin header nor by shorting the also supplied three DuPont cables with mini grabbers.

Is this the normal behaviour of this version? The calibration instructions supplied in the AliExpress page are for the T7... Is it different in this T7-H model?

[madires]

Very likely a tester with an alternative MCU.

Some hints on identifying the MCU:
- MCU in DIP is usually an genuine ATmega.
- APT32F172K8T6 has different power pins:
  - 32-LQFP/QFN: 18=Vss, 19=Vdd (ATmega328 32-TQFP: 5=Gnd, 4=Vcc)
- APT32F172K8T6 uses SWD port for ISP:
  - 5 pins: Vdd, Vcc, F_SDAT, F_SCLK, F_RST
- Testers with APT32F172K8T6 often lack a quartz crystal.
- LGT8F328 has slightly different pins:
  - QFP32L: 21=PE2/SWD (ATmega328 32-TQFP: 21=Gnd)
- LGT8F328 uses SWD port for ISP:
  - 5 pins: Gnd, Vcc, SWD, SWC, Reset
- Clone variants with an genuine ATmega are usually about EUR/US$ 5 more
  expensive than the variant with a different MCU.

[Calambres]

MCU is unlabeled, 8 pins per side so no Atmel   

This one has a XTAL, albeit a very small one (X2) just by the pads for the bigger non existent X1.



Some more photos below, includig two showing the process of not performing the calibration as indicated in the instructions.


Comparing the readings with both a DER EE-5000 and a Peak Atlas DCA55, the values are all over the place