$20 LCR ESR Transistor checker project

[vk3em]

Yesterday I ordered another unit which just might contain the ATmega324. These things are cheap enough that I'll keep at it until I get the one I want!

Call me a sucker for punishment, but after recently failing with my purchase of the LCR-TC2 from this vendor (I wanted an ATmega324 but got the LGT8F328P), I've taken a gamble on the LCR-TC1 model from the same vendor. https://www.aliexpress.com/item/1005004717377243.html

What gives me hope?

LCR-T7 / LCR-TC1:color screen / M644 chip, two functions are the same! T7 is slightly faster! The TC1 screen is slightly larger and they are all powered by lithium batteries. In addition to measuring resistance, capacitance, inductance, diodes, MOS transistors, thyristors, it can also measure additional voltage regulators, infrared decoding (limited to for Hitachi format)
Self test with automatic calibration

In the LCR-TC2 description, it does not mention M644 (since it was delivered with LGT8F328P that makes sense) nor does it mention "Self test with automatic calibration" - this also makes sense as firmware for the LGT8F328P (in my case V3.1e) cannot fit the code for self-calibration. V3.1E firmware is also horrifically buggy, cannot reliability measure ESR, or Darlington transistors, etc. I will definitely be modifying my LCT-TC2 with LGT8F328P to the ATmega328P.

I can only presume (hope) M644 mentioned in the details of the LCR-TC1 description refers to ATMega644 and so far this is the only specific mention of M644 within an advertisement that I can find. Lets see when it arrives.

Luke

Nope - It's a fail, its not a M644. I guess you just cant trust AliExpress sellers (Note: I have a message response from the seller confirming prior to sale, the device contains an M644 chip!). Not sure if its a fake 328P. 

[.RC.]

I assume it is a fake as the chip has totally identical markings to the chip on my Fnirsi, right down to the DOM. There is no external crystal.  Also R1 and R4 (two of the important 470K and 680R resistors) are entering the chip at the same position as mine which is different to the photos of boards with real 328P chips that I have seen.

Here is a real 328p board.  https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg1016677/#msg1016677

[vk3em]

Thanks. The TC1 firmware identifies as "M-Tester" and the TC2 firmware identifies as "LCR-TC2 v3.1E".

"Short the three test sockets, press the multi-function button shortly, and the tester will automatically calibrate.
No other operations are required after disconnecting the short wiring according to the prompt during the calibration process."

Neither of the units seem to allow entry into a self-calibration mode, despite both providing the calibration shorting pins.

I'll do some side by side comparison to see how they perform, but it looks like I have no choice now but to build the GM-328 kit which came with a genuine Atmel MEGA 328P. I feel like I am walking in your footsteps ! In the future, I will try to convert the TC2 with its LGT8F328P to a MEGA328.

Its a pity because AliExpress SeeSensor has good ratings, and they obviously did sell genuine Atmel units, but not now, and not even if you ask them to confirm!

Luke

[.RC.]

I feel like I am walking in your footsteps

My footsteps seem to be like that monastery in the movie Where Eagles Dare.

You have a destination this monastery atop a cliff edged mountain.   Most sensible people take the nice safe cable car to the top.   I am often the fool you see scrambling up the cliff face, because I rushed in and never saw the cable car. 

[moghaddam]

I also have a T7 (pictured attached, fake obviously). It was working fine, but since a few days ago, when I try to test anything, it randomly detects it as resistor or mostly inductor. I can't remember what was the last thing that I tested. I checked all the diodes (in circuit) and they all looks ok. I don't have a hot-air gun, so I have not tried to desolder caps to check them one by one. I just checked for short, and seems none of them are shorted.

My question may have already been answered, but at least I didn't manage to find it in the last couple of days that I'm reading through this thread (10 years old thread, really impressive ). I was wondering maybe someone has already had this issue and could give me some hint to do further troubleshooting.

I'm not professional. Just a hobyist trying to learn electronics.

[madires]

A common fault is a toasted SRV05-4.

[Aldo22]

My question may have already been answered, but at least I didn't manage to find it in the last couple of days that I'm reading through this thread (10 years old thread, really impressive ). I was wondering maybe someone has already had this issue and could give me some hint to do further troubleshooting.

I would calibrate it first and then check again.
Have you done anything in the K-A-A range?
I have the same board and you should add a resistor anyway.
I have done that as well.
You can find information about the problem in the forum.

See also: https://www.eevblog.com/forum/testgear/...

And you most likely have an APT32F172K8T6 like I do, not an Atmega.

[hapless]

I flashed a tester that I've had for a while with the 1.49m code and noticed a problem with too high h_FE. It also doesn't stay consistent, changing from time to time. The following fixes it:

Code: [Select]

/* ************************************************************************
 *   workarounds for some testers
 * ************************************************************************ */


/*
 *  Disable hFE measurement with common collector circuit and Rl as
 *  base resistor.
 *  - problem:
 *    hFE values are way too high.
 *  - affected testers:
 *    Hiland M644 (under investigation, possibly poor PCB design)
 *  - uncomment to enable
 */

#define NO_HFE_C_RL
However, this is not some fancy M644. It's a GM328-3V from 2014. A very simple, straightforward design. It does have a converter from 3V to 5V. It has the same issue when powered from the ISP port, which bypasses the DC-DC converter completely. I removed the surge suppressor, too, thinking that it might be fried. Same problem. 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. Not sure where to look for further problems there. Could the problem lie with the way 1.49m measures common collector current or is it definitely something with the hardware? I can't seem to find any hardware problems on the probe side of the chip. Connecting ISP header adds some capacitance, but that's the only thing I can see that's even remotely suspect. Any ideas welcome at this point because I'd like this particular unit to be running the latest M firmware, not K.

[Yuriy_K]

I can't seem to find any hardware problems on the probe side of the chip.
...
 Any ideas welcome at this point because I'd like this particular unit to be running the latest M firmware, not K.

Compare the Show Values with the photo to see if there are significant differences.

[moghaddam]

Thanks for your suggestions guys.

@madires I just checked the SRV05-4 forward voltages. Seems they're all in range (0.6-0.8V).

@Aldo22 It doesn't get calibrated (as shown in the picture posted in my original question) and only detects an inductor between 2-3 when I short 1-2-3 together. I know I had tested some diodes between K-A and changed diodes while the tester was on, so that could easily be the case. I will definitely add the 2K2 resistor to the board.

I read the answer you linked as well as your other similar answer with even more details at https://www.eevblog.com/forum/testgear/%2420-lcr-esr-transistor-checker-project/msg4692413/#msg4692413. There it says:

Unmodified (but working) LCR- units with APT32F172K8T6 MCU and the poorly designed U7 circuit will display 5-8V “zener voltage” with the 1k resistor connected to K-A. This is because DC-DC converter U7 actually does function as a constant current source (until it gets damaged).

When I put the 1K resistor, it detects it as an 8V Zener. Also I tried measuring a 3V Zener and it detects it correctly as 3.2V Zener and it doesn't get hot at all. So is it safe to assume the U7 current limiting is still working?

[Aldo22]

@moghaddam:
I can't tell you more as I soldered the resistor in before I had a problem.
I had the information from here.

[madires]

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.

0 pF can happen when some values don't add up during the measurement. You could try ADC_LARGE_BUFFER_CAP to increase the delay for switching the ADC's reference voltage.

[hapless]

I can't seem to find any hardware problems on the probe side of the chip.
...
 Any ideas welcome at this point because I'd like this particular unit to be running the latest M firmware, not K.

Compare the Show Values with the photo to see if there are significant differences.

Please see the attached image. Looks reasonably close? Maybe I'm missing something there.

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.

0 pF can happen when some values don't add up during the measurement. You could try ADC_LARGE_BUFFER_CAP to increase the delay for switching the ADC's reference voltage.

Doesn't seem to change anything... I'll try to recompile again later, just in case. The actual cap measures around 1.1nF.

[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.