$20 LCR ESR Transistor checker project

[genix]

I'm separated Ri for each probe plus measured resistance in both directions with average, also binned and re-soldered R1-R6 (it was 1%+ originally) for <0.05% spread.
For current MCU sample:
Ri- 12.2 12.8 12.8 (87 91 91 mV) - very consistent
Ri+ 16.6 16.0 16.0 (119 114 114 mV) - very consistent
R0: ~0.18 - +/- 0.03, 2-3 tends to be lower

else if (U_c < 800) /* extra pull-down */

this should be changed to < 400

[indman]

this should be changed to < 400

Yes, this is understandable. And in K-Firmware the same threshold of 800?

[madires]

The threshold for the k-firmware is currently 1000mV (EntladePins.c).

[indman]

I found that it crashes in DischargeProbes() because this newer MCUs (all 3 of mine) has lower internal resistance so current "optimistic" 800mV pull-to-ground threshold is simply too high and causes overcurrent protection / shutdown, it is also more likely to reproduce with hi-value low-esr capacitors, this threshold must be lowered to 400mV or less - then it works fine without any changes in BOD fuses etc.

I still don't quite understand one thing. If this is a overcurrent protection trip, then the same protection trip should occur when we measure the capacitor parameters through the menu. After all, the discharge procedure is similar. And this effect is not there. Why?

[genix]

I still don't quite understand one thing. If this is a overcurrent protection trip, then the same protection trip should occur when we measure the capacitor parameters through the menu. After all, the discharge procedure is similar. And this effect is not there. Why?

I didn't make screenshots from my DSO but in dedicated menu there is zero voltage + [discharge + test with predictable polarity + discharge] + long wait to get rid of any transition effects, then repeat.
In auto-mode there is multiple rapid charge-discharge cycles with opposite polarity then [discharge + test with predictable polarity + discharge].
If MCU crashes and reboots - then it may crash again even on first DischargeProbes() before doing anything - trying to discharge cap from its previous "life".
For me it happens with solid-polymer caps, I couldn't remember any issues with regular liquid electrolytes so I guees that low-ESR + chemistry (high dielectric absorption?) matters somehow

[phreich]

Hello,

I did a stupid and accidentally connected lead1 and lead3 to a 12v battery and the tester is now dead.

I looked over all the components and didn't see any visibly "fried", but obviously something was damaged.

When something like this happens to these, is there a specific component that usually is damaged that can be replaced?

I have the following version,

Here's the back:

[indman]

When something like this happens to these, is there a specific component that usually is damaged that can be replaced?

Remove parts Q5 and P6KE6V8 from the board and try to turn the tester back on. If it doesn't work, you are out of luck and the ATmega328 microcontroller is burned out.

[Cosmic_Starlight]

Hello, so ive been running 1.54m @16Mhz on my AY-AT without a problem everything works as expected i just came looking mostly for some clarification of some specific parameters on the config files

so on makefile i changed settings accordingly to its user manual, however reading on here about compiler optimizations i enabled 3 of them on the make file namely

MakeFile

Code: [Select]

OPTIMIZE_VECTORS = yes
CFLAGS += -flto
LDFLAGS += -Wl,-relax

and from what i remember madires saying, is that you should be wary playing with other optimizations not defined in the makefile because they could alter test resutls,
but would these 3 settings together change the results at all ?

also on config.h i changed some setting as suggested to optimize on the user manual and i could get it to read the wall adapter pretty accurately and lowered the shutdown voltage enough to be able to power it from a smartphone charger should i ever need to (highest quality psu i can get right now)

anyway on this config file i had doubts about these

Config.h

Code: [Select]

#define UREF_25
#define HW_REF25
#define UREF_VCC

so i was taking measurements with the DMM as suggested and i noticed that the VCC voltage on the HT7550 is much more stable than the VREF of the TL431A
(i know and have seen scope captures that it dips during measurementss and my dmm cant read that)

because even the device being idle on the main menu the vref voltage is fluctuating while the vcc voltage is pretty much rock solid (no more than a 0.001 variance) while vref was varying 0.02+-
so idk if i did more harm that good by disabling vref on fw without a scope measurements

even then with vref disabled measuring caps is very very stable, measuring a 1uf polyester cap doesnt vary more than 0.001 and same for esr 0.01 at worst (i think with vref enabled it was almost if not the same results)

also two other questions

the manual mentions a contrast setting being available for SOME lcd modules being available to change with the rotary encoder,
i assume this isnt available for the ST7735 the AY-AT uses ?

and also last question is there a slightly thicker font available ? i mean closer to whatever font K firm used, maybe quite not so thick but it seems like the default one is like 1 pixel width at best

also thank you all for your continued development of this firmware am very happy with it

[madires]

and from what i remember madires saying, is that you should be wary playing with other optimizations not defined in the makefile because they could alter test resutls,
but would these 3 settings together change the results at all ?

So far I haven't noticed or heard about any problems with those. The problem with some optimizations is that they optimize specific code critical for a measurement, e.g. changing the timing.

even then with vref disabled measuring caps is very very stable, measuring a 1uf polyester cap doesnt vary more than 0.001 and same for esr 0.01 at worst (i think with vref enabled it was almost if not the same results)

The external 2.5V reference makes only sense when it is at least 10 times more precise than the LDO. With a stable LDO you can measure its output voltage and update UREF_VCC.

the manual mentions a contrast setting being available for SOME lcd modules being available to change with the rotary encoder,
i assume this isnt available for the ST7735 the AY-AT uses ?

Yep. Colour displays usually don't support a direct contrast setting. But you could play with the charge pump voltages (power control registers).

and also last question is there a slightly thicker font available ? i mean closer to whatever font K firm used, maybe quite not so thick but it seems like the default one is like 1 pixel width at best

Have you tried FONT_10X16_HF and FONT_10X16_ISO8859_2_HF?

[Destrio5]

Hi,

I've updated my LCR-T4 tester and I'm having trouble calibrating it. When I put a capacitor greater than 100nF in sockets 1 and 3, the measurement remains at 0nF. What can I do ?

[indman]

What can I do ?

It is best if you can show us a video of this effect. Then you will be helped to find the problem faster.

[Destrio5]

I'll make a video as soon as I can.

I've put in version 1.13k, I'd like to test version 1.54m but it doesn't offer .hex and .eep files.

[Feliciano]

For m-firmware you have to edit the configuration files and make the binaries. In the clones file you will find guidance on how to do it for the most popular clones.

[Destrio5]

Ok thanks.

The video quality is horrible :
https://youtu.be/jlUb3FS5G9I

I think I damaged the tester with an incorrectly discharged capacitor. It detected capacitors as transistors. That's why I changed the firmware.

[indman]

I think I damaged the tester with an incorrectly discharged capacitor. It detected capacitors as transistors. That's why I changed the firmware.

You're right, the controller is probably damaged. It's obvious from your video right from the first frames. The tester doesn't see any shorted test pins. Changing the firmware will not fix this problem.

[tigrou]

Hello, I have ordered a T4 a few days ago (for about 10 bucks) and couldn't be more happier.

However a few days later (it's always like that), I just found out there is an improved version of it : T10H. If I had know this before, I probably would have pick it up.

EDIT : found this review (not in English )



Has anybody experience with that one ? I'm wondering in which ways it improves the T4. It can probably detect a few more components in a better way.
What I'm more interested is to know if precision is any better ? There is a IR receiver (I really don't care).
Sometimes it's powered by two AA batteries, sometimes by a lithium one (USB charged)

[indman]

I'm wondering in which ways it improves the T4. It can probably detect a few more components in a better way.

No, he can't. If you have a T4 tester made on ATMega328, it will be better than T10H for sure

What I'm more interested is to know if precision is any better ?

No, it's not better, because it's made on a Chinese LGT8P328.

[tigrou]

Thank you. This is in keeping with the old adage: “more expensive/bigger doesn't necessarily mean better”.

T4 costs around 10 EUR.
The T10 is 20 EUR (sometimes I've seen 35 or more  ). At that price, you should probably buy a good LCR meter (not as versatile as the Tx universal tester series, but at least more accurate).

[madires]

A tester with a DIP ATmega is still the best bet to get a genuine ATmega. If there are images of the PCB you might be able to spot the alternative MCUs (aka fakes). The Clones file of the m-firmware lists a few hints to identify them.

[madires]

This time we have a few improvements and support for INA226.

v1.55m:
- Added support for INA226 power monitor (HW_INA226, suggested by prashk20@EEVblog).
- Adjusted threshold in DischargeProbes() to support newer ATmega types with lower RiL and RiH values of newer ATmega types (thanks to genix@EEVblog).
- Fixed UI flow in BH1750 function, i.e. check for BH1750 after 'Start'.
- Updated Russian texts #1 and #2 (thanks to indman@EEVblog).
- Added support for buzzer in logic probe (suggested by Bohu).
- Added option to enter main menu after power-on by pressing test button twice at power-on (UI_MAINMENU_POWERON_BUTTON, suggested by indman@EEVblog).
- Updated Polish texts #2 (thanks to Jacon@EEVblog).

Please download at:
- https://github.com/madires/Transistortester-Warehouse/tree/master
- https://github.com/kubi48/TransistorTester-source

Bohu's updated PDFs are also already in the repo.

[hapless]

I believe that there's not much reason to keep the Russian translation file that I submitted long ago. The idea was to have a version with old-style terminology (like that in older Russian electronics books and magazines) for those who are used to it, but it makes little sense anymore. Most such people have either passed away or gotten used to the modern terminology anyway. Now it's just another file to keep updating. Unless someone objects, I think it should be removed.

[indman]

Most such people have either passed away or gotten used to the modern terminology anyway. Now it's just another file to keep updating.

Do not be offended, but I think you are wrong. Your version of the Russian translation is still being used and I know such people. Therefore, I think that it is not necessary to remove it, especially since it is not a problem to update it.

[tigrou]

Hello, I have the T4 version as shown on this picture :



I saw there is some firmware update that can be done (using Github repository posted above).
Other than accuracy and bug fixes (which is already good to have) does it bring some other features ?
Is there a way to find out which firmware version I have ? (eg: using some hidden command)
What type of hardware (EEPROM programmer) do I need to perform the upgrade ?

I was looking about how the device work (had some theory about that), looked into the C code (OMG this is so complex) and then just found that (can't be more happy) :
https://github.com/kubi48/TransistorTester-documentation/blob/main/pdftex/english/ttester.pdf

[madires]

Your T4 runs a modified k-firmware (fancy UI, less features, based on an old k version). Both OSHW firmwares (k & m) provide more measurements, improved detection, additional checks/features and a not so fancy UI (trade-off because of the limited flash size). For flashing the ATmega you'll need an ISP programmer, e.g. USBasp or an Arduino with the ISP sketch, plus avrdude.

[snapper]

@ Tigrou  "What type of hardware (EEPROM programmer) do I need to perform the upgrade ?"

a USBASP programmer with a suitable adapter and solder a pin header to the back of the tester !