$20 LCR ESR Transistor checker project

[moimem]

moimem,404 - Attachment Not Found

reattached here

[indman]

moimem,I tried to compile with your file, but the size of the firmware did not change at all - 99.8%.

[horo]

These are the results for my AY-AT setup with different options, available at GitHub:
https://github.com/Ho-Ro/ComponentTester/tree/77066735c597e81ee78742bb1c902b6356520e12

Interesting that version 13 is back on small size, almost similar to version 8.

Code: [Select]

avr-gcc v. 13.2.0
Program:   33246 bytes (101.5% Full)
Program:   32524 bytes (99.3% Full) -flto
Program:   32090 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 12.1.0
Program:   36834 bytes (112.4% Full)
Program:   35592 bytes (108.6% Full) -flto
Program:   35162 bytes (107.3% Full) -flto; -Wl,--relax

avr-gcc v. 8.3.0
Program:   33262 bytes (101.5% Full)
Program:   32562 bytes (99.4% Full) -flto
Program:   32044 bytes (97.8% Full) -flto; -Wl,--relax

avr-gcc v. 7.3.0
Program:   33332 bytes (101.7% Full)
Program:   32588 bytes (99.5% Full) -flto
Program:   32094 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 5.4.0
Program:   (> 100% Full)
Program:   (> 100% Full) -flto
Program:   32034 bytes (97.8% Full) -flto; -Wl,--relax


[indman]

Thanks horo!
With your archive, I got a compilation with the same firmware size as yours on avr-gcc 8.3.0.
Perhaps I'll stop at this point with experiments.

[moimem]

These are the results for my AY-AT setup with different options, available at GitHub:
https://github.com/Ho-Ro/ComponentTester/tree/77066735c597e81ee78742bb1c902b6356520e12

Interesting that version 13 is back on small size, almost similar to version 8.

Code: [Select]

avr-gcc v. 13.2.0
Program:   33246 bytes (101.5% Full)
Program:   32524 bytes (99.3% Full) -flto
Program:   32090 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 12.1.0
Program:   36834 bytes (112.4% Full)
Program:   35592 bytes (108.6% Full) -flto
Program:   35162 bytes (107.3% Full) -flto; -Wl,--relax

avr-gcc v. 8.3.0
Program:   33262 bytes (101.5% Full)
Program:   32562 bytes (99.4% Full) -flto
Program:   32044 bytes (97.8% Full) -flto; -Wl,--relax

avr-gcc v. 7.3.0
Program:   33332 bytes (101.7% Full)
Program:   32588 bytes (99.5% Full) -flto
Program:   32094 bytes (97.9% Full) -flto; -Wl,--relax

avr-gcc v. 5.4.0
Program:   (> 100% Full)
Program:   (> 100% Full) -flto
Program:   32034 bytes (97.8% Full) -flto; -Wl,--relax


most intersting fact in my opnion is that the best result so far is obtained with avr-gcc-5.4.0 and -flto -wl, --relax flags
confirmed after testing your code in windows and linux

Code: [Select]

Program:   32034 bytes (97.8% Full)
(.text + .data + .bootloader)

Data:        260 bytes (12.7% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

[hapless]

But the question is, does this happen because something important is optimized out and newer versions are smart enough to keep it?

[indman]

most intersting fact in my opnion is that the best result so far is obtained with avr-gcc-5.4.0 and -flto -wl, --relax flags

Code: [Select]

Program:   32034 bytes (97.8% Full)
(.text + .data + .bootloader)

Data:        260 bytes (12.7% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

The funny thing is that when I returned to my old version of the compiler based on avr-gcc 6.3.1, the code turned out to be the most compact. I just added the -wl, --relax flag to -flto on the advice of horo 

[Maniaxx]

The 13.2.0 even outperforms the 8.5.0 now so i will go for that. I'd always prefer newer compilers over older ones if near on-par in size.

Code: [Select]

Custom config (--relax, -flto, avr-gcc 13.2.0):
AVR Memory Usage
----------------
Device: atmega328

Program:   31448 bytes (96.0% Full)
(.text + .data + .bootloader)

Data:        270 bytes (13.2% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

Code: [Select]

Custom config (--relax, -flto, avr-gcc 8.5.0):
AVR Memory Usage
----------------
Device: atmega328

Program:   31522 bytes (96.2% Full)
(.text + .data + .bootloader)

Data:        252 bytes (12.3% Full)
(.data + .bss + .noinit)

EEPROM:       22 bytes (2.1% Full)
(.eeprom)

[moimem]

The 13.2.0 even outperforms the 8.5.0 now so i will go for that. I'd always prefer newer compilers over older ones if near on-par in size.

I installed the 13.2.0 (had to build an archlinux VM) and tried some experiments and its getting a little bit more complicated since its not always a matter of compiler version but it  also depends of the code itself; adding or removing some features of the firmware make mixed final results, but with few bytes difference i prefere the 13.2 too.

Code: [Select]

config-maniaxx (--relax, -flto) avr-gcc 6.3.1
Program:   31526 bytes (96.2% Full)

config-maniaxx (--relax, -flto) avr-gcc 13.2.0
rogram:   31448 bytes (96.0% Full)

config-horo (--relax, -flto) avr-gcc 6.3.1
Program:   31998 bytes (97.7% Full)

config-horo (--relax, -flto) avr-gcc 13.2.0
Program:   32090 bytes (97.9% Full)

[JohnC]

Help please to fix my old FISH8840 

Hi everyone, and thanks very much for all your work on these clone testers!

I would like to repair my original FISH8840 "Big Screen", to repay it for many years of faithful service. It's had the "power fix", upgraded LDO, matched resistors, etc but now the screen is stuffed.

It's been in storage for years, however I think that the front polarizer peeled off - anyway, now it has a very strange circular distortion (see attached pics). I tried overlaying a few polarizing sheets but they didn't improve it, so I thought maybe it used a circular polarizer or something?

The screen is 63 x 51mm, with an 18-conductor ribbon. I've attached a photo of the rear of the PCB, and you can see the 6 pin header going down to the main PCB. The SID, SCLK, RS and REST pins go to the LCD, the VCC goes through an LDO, and there's a heap of bypass caps on the other ribbon connections.

I read that it used a ST7565 controller (??), however I have not un-glued the panel to check and there is no markings on the ribbon cable. I tried searching but can't seem to find a matching replacement, nor even a screen with similar ribbon connection.

Do you have any idea what might be wrong with it, and is it repairable? If not, how could I find a replacement screen, even it it's a smaller footprint?

Obviously it'd be easier just to replace the whole gadget, but I thought I'd give you guys a shout out before I retired it permanently. Do you have any ideas or assistance for me?

Cheers, John 

[madires]

Most likely fubar. You could search AliExpress for ST7565 and look for one with a matching flat-flex. Another way is to get an ST7565 display meant for Arduino (5V) and wire it up. Or go for the OSHW firmwares (k or m) and use any supported display.

[hapless]

Looks like it may be fixable with what this guy is doing:



After that, you just replace the polarizer with a good one and you should be good to go.

However, doing all that, even if you have the patience, can result in a shattered display and personal injury, so I can't really recommend the procedure. It would be best to just replace it like madires said.

[rfdes]

Curious -
I have my unit apart for some upgrades and was wondering if there is any real motivation to move from 8MHz to 16MHz?  My unit is a simple unit using only the 16x2 display and don't know if there is any real benefit to increasing the frequency.

Does anyone have a valid reason to upgrade to 16MHz?
thanks
Jim

[JohnC]

Most likely fubar. You could search AliExpress for ST7565 and look for one with a matching flat-flex. Another way is to get an ST7565 display meant for Arduino (5V) and wire it up. Or go for the OSHW firmwares (k or m) and use any supported display.

Yeah, however it's probably not worth much $$ spent on it. If I cannot repair the screen, I'll just buy another AY-AT which has a more flexible PCB layout for the add-ons I wanted to install.

Looks like it may be fixable with what this guy is doing...

youtube.com > v=laYbjwxz_Ag

[snip]

Thanks heaps! That is EXACTLY the info that I hoped for! 

The replacement polarizer sheets are cheap on AliExpress. That video showed a reflective B&W LCD, yet mine is backlit (blue). Do you know if all the polarizers are the same basic thing?

[indman]

Does anyone have a valid reason to upgrade to 16MHz?

This question is asked very often by people who do not read the global author’s manual from Karl-Heinz at all, or who simply skim through it without delving into the technical nuances and thoughts that the author, with his enormous work and effort, wanted to convey to you.
If you open the manual dated November 15, 2021 on page 50, you will find this:
"WITH SamplingADC With this option set, the tester make use of the sampling method of ADC
in special cases. By shifting the sampling time of the ADC with increments of 1, 4 or 16
processor clock intervals for repeatable signals fast changes of voltages can be monitored. The
load time of little capacitors below 100pF can be monitored with a resulting resolution of
0.01pF with a 16MHz processor clock."
The increased clock frequency also makes it possible to test various resonators (ceramic and quartz) in k-firmware, and in m-firmware it also allows you to expand the frequency ranges in the generator and frequency meter functions.
You can set the quartz to a frequency of 20MHz, but not all AVR controllers (especially Chinese ones) work stably at this clock frequency.

[rfdes]

This question is asked very often by people who do not read the global author’s manual from Karl-Heinz at all,

I'm guilty of this.  I'll go back and read his write-up.  I appreciate the response.  I purchased this board years ago when the clones just started hitting the market.  I now see that this project has turned into a massive thread and  need to spend more time sifting through all of the information.
Take care -

[Maniaxx]

@madires:
Can you add a 'hold' function (button press) for 'continuous mode' so we have time to write down values? On problematic PCBs (covered in collophonium) the continuous mode is better/faster. Generally, i prefer auto-hold mode though.

@all:
What 'test equipment' do you guys use with the tester? I currently use 3x 40cm cables with clamps and some additional solid wires for manually picking/clamping in-circuit. I'm wondering if i should create an interface for my banana-plug DMM equipment, especially the full-size tip pickers might come in handy at times.

[indman]

I currently use 3x 40cm cables with clamps and some additional solid wires for manually picking/clamping in-circuit.

I already told you earlier that it is undesirable to use such long conductors with this device!
Despite the apparent simplicity of the circuit design, this tester is a very sensitive device that responds to any change in inductance and capacitance at its test contacts. Even if you save the parameters of your long conductors in profile, you cannot hope that if you change their position in your hands, these values ​​​​will not change much. And these values will vary greatly, I assure you. This will lead to distorted measurement results. External testing probes should not be longer than 10-15cm and have very good contact as well as minimal inductance and internal resistance. As an example, I can give this photo from the Karl-Heinz manual. Did I make it clear for you?

[Maniaxx]

I cannot confirm that. I do in-curcuit testing (under worst conditions, touching contacts etc) and it works without problems. Even capacitors are not fluctuating in relevant ranges or differ significantly compared to in-socket testing. Tbh, i couldn't even notice any difference at all and results are astonishingly good but i haven't checked all circumstances. The only things that didn't work (expectingly) so far were DB3 DIACS (with 30V breakover).

It works for me and I'm curious what works for you.

[indman]

Maniaxx, you can make conductors of at least 1 meter in length, no one will forbid you to do this. Use it for your health if it suits you.
But the physical principles of operation of the device and its features have not been canceled. My advice mostly applies to k-firmware users with the SamplingADC option enabled
and for other people who want to learn more.

[Maniaxx]

It depends on your use case. Its neglectable e.g. for high capacitance or most semi-conductor function testing. I've had good experiences in uF and even nF ranges. pF is probably unreliable indeed. Be aware what you're doing and you should be good to go.

[indman]

I've had good experiences in uF and even nF ranges.

Do you have the same experience in measuring small amounts of microHenry range inductance with such long probes?
I do not use this tester for in-circuit measurements for several reasons and have written about this before. I still think that it is intended for testing only demounted parts and does not have sufficient protection for the test ports in order to examine in-circuit without fear! The protection in the form of the SRV05 assembly and the 6V8 suppressor looks very unreliable and in 99% of cases does not protect the controller’s measuring ports in any way. For in-circuit measurements, I have more specialized devices and instruments with good protection.

[Maniaxx]

Do you have the same experience in measuring small amounts of microHenry range inductance with such long probes?

I've measured two stator coils (180W motor). The results were 20R, 40.62mH for both. I'm not sure if these are sane values at all but the fact that these values were nearly identical for both was sufficient for me to believe they were not blown up. The cables were surely repositioned/curled/pushed/stretched/etc between testings.

does not have sufficient protection for the test ports in order to examine in-circuit without fear!

You measure unpowered of course (especially on AC circuits). And yes, i agree, in-circuit testing is unreliable in many ways. But for NPN/PNPs, Triacs and even many resistors and caps (that reflect target values) its simply a huge time saver. If in doubt you can still pry them out. I like this way of working. You have to be aware of course that the circuit might be playing tricks on you indeed.

I'm not an expert. I just expose my personal experiences and will thankfully stand corrected if i'm doing something wrong. So far the cables were not a show-stopper here though.

[madires]

@madires:
Can you add a 'hold' function (button press) for 'continuous mode' so we have time to write down values? On problematic PCBs (covered in collophonium) the continuous mode is better/faster. Generally, i prefer auto-hold mode though.

In continuous mode a short button press will skip any delay. Two short button presses trigger the main menu, and a long button press will power off the tester. So we would need something else. Any suggestion?

[hotnuma]

Hi there,

I try to build the 1.50m source code under Linux on an Arduino Uno, I've installed gcc-avr avr-libc and avrdude.
Building the code works fine but when I try to "make upload" I have the following error :

Code: [Select]

avrdude warning: verification mismatch
        device 0x32 != input 0x00 at addr 0x0000 (error)
avrdude error: verification mismatch
The command was :

Code: [Select]

avrdude -c arduino -P /dev/ttyACM0 -p m328p -D -b 115200 -U flash:w:./ComponentTester.hex:a -U eeprom:w:./ComponentTester.eep:a
It seems that uploading the hex file works but uploading the eep file fails.

Also I'm not sure which pins I should use with a SSD1306 I2C :

Code: [Select]

#define I2C_SDA          PD0            /* port pin used for SDA */
#define I2C_SCL          PD1            /* port pin used for SCL */

If I understand correctly, PD0, PD1 are used for the UART interface on an Arduino Uno.

Any help would be greatly appreciated. Thanks in advance.

*** Edit : Apparently it's not possible to upload an eep file to an Arduino Uno without an external programmer :

https://forum.arduino.cc/t/avrdude-pretents-to-be-able-to-upload-into-eeprom-but-it-cant/461846

I'll have to try with an Arduino Pro Mini then