$20 LCR ESR Transistor checker project

[mentholflash]

Thank you

[u666sa]

If anyone looking for clone on real atmel 324

https://aliexpress.ru/item/1005002448100326.html

 

[uboot]

Anyone know of a source to buy a legit Atmel tester in the form of a T1, T2, T7... I like the convenience of the package but have never found one that's not fake, and I've opened quite a few!

It seems that the Joy-IT LCR T7 (https://joy-it.net/de/products/JT-LCR-T7) always has a legit Atmega. It can be bought - in Germany at least - from different shops like Reichelt, ELV, Pollin, and Conrad. Some of them ship to other countries.

I just bought one and it has an Atmega324PA and usual ingredients like STC15L104W, TL431, LM7805, Boost Converter, IR Detector, but a slightly different PCB layout than what I have found elsewhere about the Joy-IT LCR T7, e.g. https://arnowelzel.de/m-tester




But I could not get OSHW firmware to work with it yet 

Following the instructions in the Clones document of v1.50m, I have updated the STC15 uC with https://github.com/atar-axis/tc1-u4 and set up the Makefile, config.h, and config_644.h but after flashing the device does not boot. (Lipo battery was disconnected of course during all ISP operations)

Now, when I press the test button, the LCD will power up with backlight and blank black screen and as soon as I release the button it switches back off. Nothing else will happen.

If you look at the pictures, C3 right above the Atmega is missing, but it was like that from the beginning and the device did work before with stock firmware, but I didn't like it - it even did not calculate ESR...


Any ideas for a noob like me on where to start with trouble shooting?

[indman]

Any ideas for a noob like me on where to start with trouble shooting?

Yes, there are ideas. You have a clone model from FNIRSI, and these guys could have changed the connection between the display and the controller. You also need to trace which controller ports the U8 pins are connected to?
Therefore, first you need to draw this schematic and compare it with the classic one for this clone. Your further actions will depend on this. Good luck.

[Obelix2007]

... @uboot, your board is very similar to the TC1 and T7, but J7 is missing.

In the appendix is the circuit of TC1/T7. This way you can better determine the port occupancy.

Good luck

Greetings Horst

[vklimk]

Didn't read the forum for a long time and have found different GCC comparision in accordance to fw size.
I have downloaded some gcc versions, including official one from microchip and have created a small script. Here is result for my particular case. So, sometimes the oldest one is the best one...

Code: [Select]

Trying system's avr-gcc [avr-gcc (GCC) 5.4.0] ... 28360 bytes
Trying avr-gcc-10.1.0-x64-linux [avr-gcc (GCC) 10.1.0] ... 30742 bytes
Trying avr-gcc-11.1.0-x64-linux [avr-gcc (GCC) 11.1.0] ... 30612 bytes
Trying avr-gcc-12.1.0-x64-linux [avr-gcc (GCC) 12.1.0] ... 31036 bytes
Trying avr-gcc-13.2.0-fc [avr-gcc (Fedora 13.2.0-1.fc38) 13.2.0] ... 28754 bytes
Trying avr-gcc-7.3.0-arduino [avr-gcc (GCC) 7.3.0] ... 28458 bytes
Trying avr-gcc-7.3.0-x64-linux [avr-gcc (GCC) 7.3.0] ... 28460 bytes
Trying avr-gcc-8.1.0-x64-linux [avr-gcc (GCC) 8.1.0] ... 28550 bytes
Trying avr-gcc-8.2.0-x64-linux [avr-gcc (GCC) 8.2.0] ... 28550 bytes
Trying avr-gcc-8.3.0-x64-linux [avr-gcc (GCC) 8.3.0] ... 28562 bytes
Trying avr-gcc-9.1.0-x64-linux [avr-gcc (GCC) 9.1.0] ... 30588 bytes
Trying avr-gcc-9.2.0-x64-linux [avr-gcc (GCC) 9.2.0] ... 30580 bytes
Trying avr8-gnu-toolchain-linux_x86_64-microchip [avr-gcc (AVR_8_bit_GNU_Toolchain_3.7.0_1796) 7.3.0] ... 28458 bytes

[uboot]

@vklimk how about compiler optimizations and switches? I wonder if latest avr-gcc can be tweaked to get same low sizes as past versions just because there are different defaults being used.

I guess you already you use -Os everywhere, right? But there is more.

Here is a nice article that you might translate with Google: https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung

For instance, -fno-jump-tables will reduce my current v1.50m build from 32072 to 32016 bytes.

And with a combination of CFLAGS += -ffunction-sections and LDFLAGS += -Wl,--gc-sections I was able to reduce that even further down to 31892 bytes.

[vklimk]

For instance, -fno-jump-tables will reduce my current v1.50m build from 32072 to 32016 bytes.

And with a combination of CFLAGS += -ffunction-sections and LDFLAGS += -Wl,--gc-sections I was able to reduce that even further down to 31892 bytes.

In my case it changes to the following if I add all these 3 options:

Code: [Select]

Trying system's avr-gcc [avr-gcc (GCC) 5.4.0] ... 28330 bytes
Trying avr-gcc-10.1.0-x64-linux [avr-gcc (GCC) 10.1.0] ... 30706 bytes
Trying avr-gcc-11.1.0-x64-linux [avr-gcc (GCC) 11.1.0] ... 30574 bytes
Trying avr-gcc-12.1.0-x64-linux [avr-gcc (GCC) 12.1.0] ... 30984 bytes
Trying avr-gcc-13.2.0-fc [avr-gcc (Fedora 13.2.0-1.fc38) 13.2.0] ... 28720 bytes
Trying avr-gcc-7.3.0-arduino [avr-gcc (GCC) 7.3.0] ... 28428 bytes
Trying avr-gcc-7.3.0-x64-linux [avr-gcc (GCC) 7.3.0] ... 28430 bytes
Trying avr-gcc-8.1.0-x64-linux [avr-gcc (GCC) 8.1.0] ... 28522 bytes
Trying avr-gcc-8.2.0-x64-linux [avr-gcc (GCC) 8.2.0] ... 28522 bytes
Trying avr-gcc-8.3.0-x64-linux [avr-gcc (GCC) 8.3.0] ... 28530 bytes
Trying avr-gcc-9.1.0-x64-linux [avr-gcc (GCC) 9.1.0] ... 30494 bytes
Trying avr-gcc-9.2.0-x64-linux [avr-gcc (GCC) 9.2.0] ... 30486 bytes
Trying avr8-gnu-toolchain-linux_x86_64-microchip [avr-gcc (AVR_8_bit_GNU_Toolchain_3.7.0_1796) 7.3.0] ... 28428 bytesAnd I have the same result if I don't use CFLAGS += -ffunction-sections and LDFLAGS += -Wl,--gc-sections.
gcc 5.4.0 produces the smallest fw again. In my specific case.

My options are the following at the moment:

Code: [Select]

# compiler flags
CC = avr-gcc
CPP = avr-g++
CFLAGS = -mmcu=${MCU} -Wall -I. -Ibitmaps
CFLAGS += -DF_CPU=${FREQ}000000UL
CFLAGS += -DOSC_STARTUP=${OSC_STARTUP}
CFLAGS += -gdwarf-2 -std=gnu99 -Os -mcall-prologues
CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -flto -fno-jump-tables
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

# linker flags
LDFLAGS = -g -mmcu=${MCU} -Wl,--relax,-Map=${NAME}.map

PS. After reading that article you suggested I have added more options which allowed to save a little more space: -fno-inline-small-functions -fno-split-wide-types -fno-move-loop-invariants -fno-tree-loop-optimize -mstrict-X
And result is the following:

Code: [Select]

Trying system's avr-gcc [avr-gcc (GCC) 5.4.0] ... 28072 bytes
Trying avr-gcc-10.1.0-x64-linux [avr-gcc (GCC) 10.1.0] ... 30176 bytes
Trying avr-gcc-11.1.0-x64-linux [avr-gcc (GCC) 11.1.0] ... 30188 bytes
Trying avr-gcc-12.1.0-x64-linux [avr-gcc (GCC) 12.1.0] ... 30486 bytes
Trying avr-gcc-13.2.0-fc [avr-gcc (Fedora 13.2.0-1.fc38) 13.2.0] ... 28250 bytes
Trying avr-gcc-7.3.0-arduino [avr-gcc (GCC) 7.3.0] ... 28226 bytes
Trying avr-gcc-7.3.0-x64-linux [avr-gcc (GCC) 7.3.0] ... 28228 bytes
Trying avr-gcc-8.1.0-x64-linux [avr-gcc (GCC) 8.1.0] ... 28330 bytes
Trying avr-gcc-8.2.0-x64-linux [avr-gcc (GCC) 8.2.0] ... 28330 bytes
Trying avr-gcc-8.3.0-x64-linux [avr-gcc (GCC) 8.3.0] ... 28350 bytes
Trying avr-gcc-9.1.0-x64-linux [avr-gcc (GCC) 9.1.0] ... 30150 bytes
Trying avr-gcc-9.2.0-x64-linux [avr-gcc (GCC) 9.2.0] ... 30142 bytes
Trying avr8-gnu-toolchain-linux_x86_64-microchip [avr-gcc (AVR_8_bit_GNU_Toolchain_3.7.0_1796) 7.3.0] ... 28226 bytes
Options:

Code: [Select]

# compiler flags
CC = avr-gcc
CPP = avr-g++
CFLAGS = -mmcu=${MCU} -Wall -I. -Ibitmaps
CFLAGS += -DF_CPU=${FREQ}000000UL
CFLAGS += -DOSC_STARTUP=${OSC_STARTUP}
CFLAGS += -gdwarf-2 -std=gnu99 -Os -mcall-prologues -fno-inline-small-functions -fno-split-wide-types -fno-move-loop-invariants -fno-tree-loop-optimize -mstrict-X
CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -flto -fno-jump-tables
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

# linker flags
LDFLAGS = -g -mmcu=${MCU} -Wl,--relax,-Map=${NAME}.map
avr-gcc 5.4.0 is the winner again.
And again - it is my particular code configuration. It may happen that for other code configuration another avr-gcc version will win.

[uboot]

@Obelix2007: compared to the schematics you posted, I found the following differences:

PB5 -> MOSI+LCD_SDA instead of MOSI+LCD_DC
PB6 -> only MISO instead of MISO+LDC_SDA
PB2 -> Collector of some 1AM NPN Transistor (MMBT3904LT1?) marked Q2 instead of NC
PB3 -> LCD_DC instead of NC

Connections to Test socket and STC15 look similar.

I then changed LCD pin assignment in the config file accordingly and reprogrammed it, but still same behavior.

So I suspect there is some difference in the power-up circuitry and I wonder if I will even need different firmware for the STC15 :-/


Emitter of Q2/1AM is grounded, Base is going to the Test button and when the latter is pressed, it's reaching out to R8+R30 on the very bottom left of the PCB. R30 goes to the Collector of another 1AM transistor (marked Q3) nearby, Emitter again grounded and Base going to C11+C5 wich go in parallel to GND.

R8 goes to what looks like Gate of an A1SHB/HM2301B  P-Channel Mosfet marked Q1 whose Drain is going to Pin4 of B628/U6 and U77.

Well, and the Test button has no direct connection to the STC15 

[indman]

uboot,As I suspected earlier, the Chinese guys from FNIRSI tried very hard to prevent you from easily updating the firmware to OSHW. Tell them a big thank you.

[Calambres]

I recently bought a TC2 HaoQi from AliExpress and the PCB was silkscreened with "T7-PLUS V2.0". The tester is utter crap as the measurements are very inconsistent, erroneous and all over the place 

[madires]

Well, and the Test button has no direct connection to the STC15 

Have you tried the settings for 'Multifunction Tester T7 with ATmega328' listed in the Clones file? Your tester looks very similar to that variant.

[madires]

I recently bought a TC2 HaoQi from AliExpress and the PCB was silkscreened with "T7-PLUS V2.0". The tester is utter crap as the measurements are very inconsistent, erroneous and all over the place 

Could be one with an alternative MCU. A few pages back I posted some hints about detecting those (or see top of the Clones file in the source archive).

[Calambres]

The MCU is a no-brand-no markings variant. I'll take some photos and will post them here...

[LeWidget]

Still looking to get one of these testers. Are there any versions &/or sources that are good & accurate straight out of the box or do all need some sort of modding?

[maxmatteo]

i went with the Bside Esr02 pro, has a real atmel inside and works great...

[Calambres]

i went with the Bside Esr02 pro, has a real atmel inside and works great...

Where did you buy it?

[maxmatteo]

aliexpress

[Pygmalion]

Hello!  I am late to the party, so I hope you won't mind.

I want to have LCR ESR tester of my own and I just don't want to buy a fake one.  On the other hand, I have substantial experience with Arduino and even created my own projects with SMD ATmega328, with PCB designed in KiCAD and ordered at JCLPCB.

Would you recommend me making my own?
Which DIY project / ATmega328 sketch would you recommend?
Is the sketch for LCR ESR testers still being actively updated and is the latest code better than the one used in Chinese clones?

[madires]

Yes! The best Transistortester is the one you make yourself. Please see https://github.com/madires/Transistortester-Warehouse/tree/master/Hardware for a starting point. There are two OSHW firmwares (k and m). You will find the m-firmware in the same repo and the latest k-firmware at https://github.com/kubi48/TransistorTester-source. Most clones are based on the k-firmware. Both OSHW firmwares are way better in functionality, but have less fancy graphics.

[Pygmalion]

Explanation of difference between m and k firmware is supposed to be in your README file, which I cannot find...  Can you help me with this?

I am absolutely interested in making my own, because I want to have the latest firmware all the time.  Is building one yourself much more expensive that buying a good quality finished Chinese clone?

[madires]

The README file is part of the m-firmware's source archive. For the list of differences look for section "What's different?" (around line 157). Building your own tester is probably a bit more expensive (it's mainly the ATmega, display and PCB). But you'll get a genuine ATmega and all the hardware options you want to have.

[Pygmalion]

I just realised that I can also make a stripboard version . In this case, I already have most of the components on hand (DIP ATmega and 16x2 display included).  But I did not find a nice KiCAD design. I might be tempted to make my own if there is none available.

BTW, in my experience the most expensive part in my projects is shipping from JLCPCB ... everything else can be sourced locally or at AliExpress for a negligible shipping.

I also discovered that you guys use diylc, a great free alternative for Fritzing program, which is no longer free . I have always drawn my stripboard projects in LateX/TikZ .

Even after reading the FAQ, the content of github is still confusing. There are 14 files in the hardware folder and you can not tell what each file is about unless you open it (and sometimes you do not know even after you open it ).

I would assume that all hardware projects can use both firmwares, right? On the other hand, the FAQ mentions using a different, more powerful chip than the ATmega328. I only have ATmega328s at home (both DIP and SMD), but I would be willing to buy another chip if it would improve functionality. I am a bit confused on this point.

[indman]

On the other hand, the FAQ mentions using a different, more powerful chip than the ATmega382.

Not ATMega 382 but ATMega328
Read the user manual again carefully and you will find a list of supported controllers as well as answers to almost all future questions.

[Pygmalion]

Not ATMega 382 but ATMega328

Corrected.  By the way, "m" is lower case 

Read the user manual again carefully and you will find a list of supported controllers.

That is not the point. The point is that using another controller with more than 32kB of memory makes sense only if there is firmware that utilises that extra memory. If there isn't any, even just in plan, it does not make sense to use anything more advanced than the ATmega328.