$20 LCR ESR Transistor checker project

[alex_D]

I bought a brand new ATMega644P, when I program it for the first time with a 20Mhz external crystal what fuse settings do I need to use?

This is what I used for ATMega328p

avrdude -c usbasp -p m328p -B 12.0 -e -U flash:w:"ComponentTester.hex":i -U eeprom:w:"ComponentTester.eep":i -U lfuse:w:0xF7:m -U hfuse:w:0xD9:m -U efuse:w:0x04:m

[madires]

Those fuse bit settings work for the ATmega644 too. But please change the efuse to 0xfc and ignore avrdude's warning about it (known issue, mistake in avrdude's config file).

[.RC.]

Edit: Found the issue.   Needed to install Winavr as windows was missing some bits. But it still did not make an eeprom file of a cfg file.


I have built my AYAT model with precision resistors, 0.1% voltage regulator and a 16mhz crystal, and need firmware. Well all I need is to change the clock from 8Mhz to 16MHz

Is there any way to use the makefile to output a .hex and .eep with windows 10 or is it linux only?

I downloaded the full 1.42m files just to see if I could output the hex files, and when I use the make command using the mingw program all I get is a heap of error messages. Which from prior experience seems par for the course when trying to do this with Windows.

C:\transtester>make
The system cannot find the path specified.
avr-gcc -mmcu=atmega328 -Wall -I. -Ibitmaps -DF_CPU=16000000UL -DOSC_STARTUP=16384 -gdwarf-2 -std=gnu99 -Os -mcall-prologues -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT main.o -MF dep/main.o.d -c main.c
process_begin: CreateProcess(NULL, avr-gcc -mmcu=atmega328 -Wall -I. -Ibitmaps -DF_CPU=16000000UL -DOSC_STARTUP=16384 -gdwarf-2 -std=gnu99 -Os -mcall-prologues -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT main.o -MF dep/main.o.d -c main.c, ...) failed.
make (e=2): The system cannot find the file specified.
Makefile:209: recipe for target 'main.o' failed
make: *** [main.o] Error 2

[.RC.]

Obligatory photo's.  My soldering is a bit ordinary.  I am still relearning that skill.

[oitar]

Hi all,
I'm encountering a peculiar problem that was there with the original firmware, and also showing with the 1.48m. T7-plus v1.1 board, mega324pa with the 27V voltage source(no transformer).
If I measure higher voltage zeners, it displays correct. For lower values- below 10V, it displays way lower- i.e. 3-4 times lower(but the voltage drop over the zener while measuring is correct).
I cannot perform calibration(having issues with the single button- only working to start, but no redo), but I think this has nothing to do with [RC] calibration?
Where can I manually touch the calculation?
The zener resistors were checked(100k and 12k), the voltage references are ok too.

These -afaik, are just to define the "working range", out of which the part is declared "not a zener"
#define ZENER_VOLTAGE_MIN     1000      /* min. voltage in mV */
#define ZENER_VOLTAGE_MAX     24000     /* max. voltage in mV */

And fiddling with these(which are correct):
#define ZENER_DIVIDER_CUSTOM
#define ZENER_R1         100000
#define ZENER_R2         12000
Only makes things worse. Is there an off-set I am not aware of?

[gipetto]

Maybe this is a silly idea but if anyone wanted to fix the situation with the clone mcu then one way would be to clone the clone testers, but with a second footprint for a dip or smt mcu. it wouldn't be much more expensive for manufacturers to build, and if someone wanted to upgrade, they could cut the traces to the logic green and drop in their mcu and crystal.
If they open sourced the design, then there would be a standard sellers would follow for more sales, same way as how the ay-at is the best seller now.

[madires]

I cannot perform calibration(having issues with the single button- only working to start, but no redo), but I think this has nothing to do with [RC] calibration?

Press the button twice to enter the menu. This and the self-adjustment process is explained in the README file.   

[.RC.]

Is there a dummies guide on how to compile the firmware, now I see 1.49m  just got released a few minutes ago. I am not sure what the flashlight is all about.

[madires]

Is there any way to use the makefile to output a .hex and .eep with windows 10 or is it linux only?

Please see https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/2475/

[madires]

Get your ISP programmer ready!

v1.49m:
- Alternative pinouts for IR receiver module (SW_IR_RX_PINOUT_G_V_D, SW_IR_RX_PINOUT_D_G_V, SW_IR_RX_PINOUT_D_V_G, suggested by boleslaw_43@mikrocontroller.net).
- Fixed capacitor detection issue in ESR tool. Happened after a semiconductor was found before by normal probing (reported by indman@EEVblog).
- Fixed bug in configuration management for touchscreens.
- Added check for frequency counter options to config_support.h.
- Moved code for counter tools from tools_signal.c to new tools_counter.c.
- Added checks for SPI_PIN and SPI_MISO to config_support.h in case bit-bang SPI with read support is enabled. Also extended SPI section in all
  config_<MCU>.h for easier handling.
- SW_R_TRIMMER shows now also the ratio of the second resistor (suggested by wandows@EEVblog).
- Display OneWire device symbol in DS18B20, DS18S20 and DHTXX tool (UI_ONEWIRE, suggested by indman@EEVblog).
- Added symbol for OneWire devices to all symbol sets (thanks to indman@EEVblog).
- Support for temperature sensor DS18S20 (SW_DS18S20, DS18S20_HIGHRES, suggested by indman@EEVblog).
- Added checks for Darlington BJTs to CheckProbes() & CheckDepletionModeFET() to prevent false detection as JFET in case EMI issues cause a high leakage current (reported by wandows@EEVblog).
- Fixed bug in check for Germanium PNP BJTs in CheckDepletionModeFET().
- Added configuration switch for sequential COM pin layout to OLED drivers for SH1106 and SSD1306 (LCD_COM_SEQ), and a switch for reversed COM mapping to the SSD1306 driver (LCD_COM_REMAP, suggested by boneDragon@EEVblog).
- Added support for a passive buzzer (BUZZER_ACTIVE or BUZZER_PASSIVE, suggested by boneDragon@EEVblog).
- Texts in Brazilian Portuguese (thanks to wandows@EEVblog).
- Added general purpose switched output, e.g. for an LED flashlight (HW_FLASHLIGHT, suggested by boneDragon@EEVblog).

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

[madires]

now I see 1.49m  just got released a few minutes ago. I am not sure what the flashlight is all about.

It's a simple switched output controlled via the menu, e.g. for switching an LED (hence the name). Even smartphones have a flashlight app.

[.RC.]

Is there any way to use the makefile to output a .hex and .eep with windows 10 or is it linux only?

Please see https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/2475/

Thanks.  Some of the links are dead but I managed to find the avr GNU8 toolchain from the microchip website.

I was still getting an error message as the eeprom was not getting made.   But the solution is here

I will have to research ans configure the firmware for my device.  My first attempt has given me a white screen and that is all. But at least I can compile and upload it now.

[pepe10000]

Thanks madires.

Attached update of the Spanish language file for those interested.

All the best.

[Jacon]

Hi Marcus,

Attached please find updated Polish translation.

BTW - my ordinary '328 configuration reached 32764 bytes (sic!) this time...

Great work as always 

[.RC.]

No idea how to use it, but it is there.   

But my tester does this and I am not sure why.  I assume a hardware build error.  Sometimes with nothing installed it will say there is a resistor, always between pins two and three.

[indman]

But my tester does this and I am not sure why.  I assume a hardware build error.  Sometimes with nothing installed it will say there is a resistor, always between pins two and three.

This is not surprising, because in your photos I see a lot of unwashed flux. This device has a high sensitivity, so any dirt, flux between the test contacts is perceived as resistance.

[.RC.]

Thanks, I did think I had cleaned the board enough.  It would explain the erratic nature of the issue.   Given it a good clean now and all is good.

Now that I have worked out this compiling and programming I am blown away at the number of options in the config.h file. There seems to be a lot of fine tuning option where you can measure your device and put in correction figures, along with way too many things to enable everything on a little AT328P

It leaves the FNIRSI clone tester for dead and is only AU$10 more expensive.  I just need to find a good case to print out.

And who needs a torch option.

[alex_D]

Has anyone got the passive buzzer to work?  tried enabling the passive buzzer options and connected to the port in config_MCU.h, but get no sound when probing, using the piezo type like in the photo below.   

[madires]

I tested a few passive buzzers and boneDragon tested too. Do you have a scope to check the output signal? Do you know the voltage specs of your buzzer?

[alex_D]

I tested a few passive buzzers and boneDragon tested too. Do you have a scope to check the output signal? Do you know the voltage specs of your buzzer?

Doh, found my mistake, didn't uncomment #define HW_BUZZER as well, works fine now. 

[indman]

I have updated the Russian translation of the pdf documentation for version 1.49m as well as the language file.

[Yuriy_K]

Madires, thank you very much for the new version. Everything works great, but there is a small remark. When measuring electrolytic capacitors, there is a "dead zone" up to about 0.03 ohm. Maybe it's on my Mega644, please check everyone who installed the new 1.49m version...
The picture shows the measurements of two different capacitors at different frequencies.

[madires]

You're welcome! There are no changes in the actual ESR measurement functions for quite a while.

[Fuzzy Star]

Get your ISP programmer ready!

v1.49m

Since v1.47m we have symbols_32x39_hf in the bitmaps folder but don't have "#define SYMBOLS_32X39_HF" lines in config-<MCU> files. An oversight?

[indman]

Since v1.47m we have symbols_32x39_hf in the bitmaps folder but don't have "#define SYMBOLS_32X39_HF" lines in config-<MCU> files. An oversight?

No, this is not an oversight. This symbols set is relevant for displays with a higher resolution of 320x240 and higher.