$20 LCR ESR Transistor checker project

[madires]

I went through all 7 tests and used one of those 200nF X2 caps. I tested some caps I already tried out this morning and the ESR readings are much lower now.
One that was 0.36ohm this morning is now 0.05ohm.

Next I ran the seven tests again but this time I used a 10uF Nichicon electrolytic.
I think I'm maybe getting more realistic numbers now. A 224uf 100V cap that measured Vloss= 1.3%, ESR=0.7ohm this morning now measures Vloss= 1.4%, ESR=0.4ohm

Have you noticed that the difference is about 0.3 Ohms for both measurements? The self-adjustment has measured a resistance of 0.15 Ohms for the probe leads (2 in series = 0.3 Ohms) and the tester uses that offset to auto-zero any resistance measurement. The cap is used to determine the offset of the internal bandgap voltage reference and the offset of the analog comparator. It's purpose is to hold a voltage for a few ms. The type isn't important, as long as the cap is able to keep the voltage constant (low internal losses).

[madires]

I successfully flashed the .hex and .eep files using avrdude, but the tester doesn't working any more.  The LCD just displays solid blocks for the first row.  Did I use the right files for this tester?:

Yes, those are the correct files! The most common issue is a wrong setting for the ISP programmer. In a few cases additional bypass caps were needed (please see ttester.pdf in the documentation sub-folder).

Also, I tried to use the makefile through WinAVR but I kept getting an error.  Does the makefile work on the .hex/.eep files linked above or do I need to download some other files?

You need the complete source code in the "trunk" directory.

[ion]

I haven't done much programming of micros using the command line so I always end up using the same settings that worked in the past.  Is there anything wrong with this command?

Code: [Select]

avrdude -c arduino -C ../etc/avrdude.conf -p atmega328p -P com6 -b19200 -U eeprom:w:TransistorTester.eep -U flash:w:TransistorTester.hex

Both the flash and eeprom say verified after they're written.

[ion]

... In a few cases additional bypass caps were needed (please see ttester.pdf in the documentation sub-folder).

I added the bypass caps, similar to the picture in this post: https://www.eevblog.com/forum/testgear/14399/msg221946/#msg221946

Still no luck - when I press the button the LCD light up with solid blocks on the first row.  I does go off when I let go of the button now, but that has to do with the firmware or fuses as I noticed the change before adding the caps.

I managed to load the backup flash and eeprom data by specifying it as raw data, but I'm not surprised it didn't work as I downloaded it as hex.  I still can't understand why it won't upload it in the same format as I read it from the chip.

I tried compiling both the k- and m-firmware.  They don't give me any errors writing to the micro but it still won't work.

Anyone knows what else it could be?

[madires]

I haven't done much programming of micros using the command line so I always end up using the same settings that worked in the past.  Is there anything wrong with this command?

Code: [Select]

avrdude -c arduino -C ../etc/avrdude.conf -p atmega328p -P com6 -b19200 -U eeprom:w:TransistorTester.eep -U flash:w:TransistorTester.hex

Both the flash and eeprom say verified after they're written.

Seems to be fine.

[madires]

Still no luck - when I press the button the LCD light up with solid blocks on the first row.  I does go off when I let go of the button now, but that has to do with the firmware or fuses as I noticed the change before adding the caps.

Anyone knows what else it could be?

Another idea would be to change the BOD setting in the e-fuse. The default setting of the Makefile is 0xfc (4.3V). Please set the e-fuse to 0xfd (2.7V) and try again. Especially with some hardware options the supply voltage might not rise fast enough for the MCU and the MCU will detect that as a brown-out and resets (and keeps doing that as long as you press the push button).

[ion]

Another idea would be to change the BOD setting in the e-fuse. The default setting of the Makefile is 0xfc (4.3V). Please set the e-fuse to 0xfd (2.7V) and try again. Especially with some hardware options the supply voltage might not rise fast enough for the MCU and the MCU will detect that as a brown-out and resets (and keeps doing that as long as you press the push button).

Just tried that, still doesn't work.  0xfd gets changed to 0x5 which I believe is the same setting (for that matter 0xfc gets changed to 0x4).  The e-fuse setting it came with was 0x7 (BOD disabled?), and that doesn't work either.

The only difference I've noticed is that with BOD settings below 4.3V, the LCD and LED stay on after I let go of the button.  They do time out eventually (~70s).

Edit:  Just noticed the LED only turns on after I let go of the button and turns off again if I hold the button down.  Not sure if it's supposed to do this.

[madires]

The only difference I've noticed is that with BOD settings below 4.3V, the LCD and LED stay on after I let go of the button.  They do time out eventually (~70s).

At least some progress That means that the MCU is running and after a few test cycles the tester powers off as intended. The next step is to check the LCD module. Contrast? Which pin of the LCD is connected to which pin of the ATmega? If you got another LCD module, you could try that one.

Edit:  Just noticed the LED only turns on after I let go of the button and turns off again if I hold the button down.  Not sure if it's supposed to do this.

That's ok, it's designed that way.

[ion]

... Which pin of the LCD is connected to which pin of the ATmega?

I think I've spotted the problem - most of the pins don't match the schematic:

RS - PD7
E - PD5
D4 - PD4
D5 - PD3
D6 - PD2
D7 - PD1

The do seem to match the pinout for the stripboard version though!  I'll try to load that version in the morning (I've learned not to work on electronics when I'm tired!).  Loading the wrong version shouldn't have caused any damage right?

[nessatse]

Just completed my own version (https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg470219/#msg470219), and I must congratulate Karl-Heinz and Markus on this magnificent project.  An example of true engineering. 

I have however picked up a small problem with the 1.13m version.  It seems that resistors in the range between approximately 1.5k and 3k are incorrectly identified as double diodes.  I verified this using a 4k7 trimpot and stepping through its range.  It does not matter which pins I use, at about 1.5k it starts identifying as a double diode almost all the way to about 3k.  I loaded the 'k' version of the software and it works perfectly throughout the range.

I cannot discount the possibility that there is something wrong with my hardware, but I think the likelihood is low, since it works perfectly for every other component I have thrown at it so far.

I have started looking at the source to try and figure out where it is going wrong, but that may take a while.  Any suggestions?


Edit: Added image.  Two diodes with cathodes going to the same pin?

[madires]

The do seem to match the pinout for the stripboard version though!  I'll try to load that version in the morning (I've learned not to work on electronics when I'm tired!).  Loading the wrong version shouldn't have caused any damage right?

The ATmega should have survived the different pinout. The only issue would be the test button, if the ATmega's pin is set to high output and is short circuited by the BJT when the test button is pressed. But the ATmega is able to take some pain

[ion]

The do seem to match the pinout for the stripboard version though!  I'll try to load that version in the morning (I've learned not to work on electronics when I'm tired!).  Loading the wrong version shouldn't have caused any damage right?

The ATmega should have survived the different pinout. The only issue would be the test button, if the ATmega's pin is set to high output and is short circuited by the BJT when the test button is pressed. But the ATmega is able to take some pain

Well, it did survive.  Just loaded the stripboard version of the latest firmware and it's working great

Thanks for all the help.

[madires]

I have however picked up a small problem with the 1.13m version.  It seems that resistors in the range between approximately 1.5k and 3k are incorrectly identified as double diodes.  I verified this using a 4k7 trimpot and stepping through its range.  It does not matter which pins I use, at about 1.5k it starts identifying as a double diode almost all the way to about 3k.  I loaded the 'k' version of the software and it works perfectly throughout the range.

I can reproduce the problem and will look into it. Thanks for reporting!

I have started looking at the source to try and figure out where it is going wrong, but that may take a while.  Any suggestions?

It's the diode detection.

[hdlg_zhangyu]

Hi Madires,
Display problem solved.
I don't know what changes was brought to the most recent mega328_st7565 trunk version, i modified the makefile:
CD_ST7565_RESISTOR_RATIO = 5
CFLAGS += -DFONT_6X8
I don't know why CFLAGS += -DFONT_8X16 always gave me an: "avrdude: ERROR: address 0x8010 out of range at line 2049 of ./TransistorTester.hex" message

and the display is working properly now. However, there's a minor problem with the display, the left side character is only partially displayed, is there anyway to fix it?

Thanks for your help!

I tried all values and seems only LCD_ST7565_RESISTOR_RATIO = 7 gave me a faint display, with other values, there is no display at all.
Is there anything else i should look at?
Thanks.

While the meter still can be turned on/off after flashing the firmware, there is no display. I set the LCD_ST7565_RESISTOR_RATIO = 7,  and then i was able to see some faint display. I am wondering what parameters in the makefile should be set to make it working properly?

That value selects the resistor divider of the module's internal voltage regulator. For most ST7565 displays 4 or 7 work fine but you could also try other values from 0 up to 7.

[madires]

I have however picked up a small problem with the 1.13m version.  It seems that resistors in the range between approximately 1.5k and 3k are incorrectly identified as double diodes.  I verified this using a 4k7 trimpot and stepping through its range.  It does not matter which pins I use, at about 1.5k it starts identifying as a double diode almost all the way to about 3k.  I loaded the 'k' version of the software and it works perfectly throughout the range.

Please edit semi.c and change in function CheckDiode()

Code: [Select]

    U1_Zero /= 50;            /* 2% */
    U1_Rh += U1_Zero;         /* 102% */

into

Code: [Select]

    U1_Zero /= 10;            /* 10% */
    U1_Rh += U1_Zero;         /* 110% */

5% (/= 20) might be also sufficient.

[madires]

I don't know why CFLAGS += -DFONT_8X16 always gave me an: "avrdude: ERROR: address 0x8010 out of range at line 2049 of ./TransistorTester.hex" message

The ATmega328 has only 32k flash

and the display is working properly now. However, there's a minor problem with the display, the left side character is only partially displayed, is there anyway to fix it?

That's strange! Seems to be related to the font based positioning. Could you please delete all object files and recompile the firmware. Maybe something got stuck when you tried the 8x16 font.

[hdlg_zhangyu]

No luck recompiled the files   
 

I don't know why CFLAGS += -DFONT_8X16 always gave me an: "avrdude: ERROR: address 0x8010 out of range at line 2049 of ./TransistorTester.hex" message

The ATmega328 has only 32k flash

and the display is working properly now. However, there's a minor problem with the display, the left side character is only partially displayed, is there anyway to fix it?

That's strange! Seems to be related to the font based positioning. Could you please delete all object files and recompile the firmware. Maybe something got stuck when you tried the 8x16 font.

[hdlg_zhangyu]

modified the lcd-routines.c
set the cursor at each line start with (x,1), and the problem is fixed.
Will this change have any negative effects? e.g. alter the display at end of each line?

No luck recompiled the files   
 

I don't know why CFLAGS += -DFONT_8X16 always gave me an: "avrdude: ERROR: address 0x8010 out of range at line 2049 of ./TransistorTester.hex" message

The ATmega328 has only 32k flash

and the display is working properly now. However, there's a minor problem with the display, the left side character is only partially displayed, is there anyway to fix it?

That's strange! Seems to be related to the font based positioning. Could you please delete all object files and recompile the firmware. Maybe something got stuck when you tried the 8x16 font.

[madires]

modified the lcd-routines.c
set the cursor at each line start with (x,1), and the problem is fixed.
Will this change have any negative effects? e.g. alter the display at end of each line?

Great! I don't think it will cause any new problems.

[nessatse]

Quote from: nessatse on Yesterday at 11:08:30

I have however picked up a small problem with the 1.13m version.  It seems that resistors in the range between approximately 1.5k and 3k are incorrectly identified as double diodes.  I verified this using a 4k7 trimpot and stepping through its range.  It does not matter which pins I use, at about 1.5k it starts identifying as a double diode almost all the way to about 3k.  I loaded the 'k' version of the software and it works perfectly throughout the range.

Please edit semi.c and change in function CheckDiode()

Code: [Select]    U1_Zero /= 50;            /* 2% */
    U1_Rh += U1_Zero;         /* 102% */

into

Code: [Select]    U1_Zero /= 10;            /* 10% */
    U1_Rh += U1_Zero;         /* 110% */

5% (/= 20) might be also sufficient.

Thanks! It works with both 5% and 10%! 

[dentaku]

I just tried to measure two 10000uF 50V Nichicon caps with my MK-168 tester (firmware 1.10K) and they both keep measure no bigger than 5986uF

Is this the limit of these testers?

[madires]

I just tried to measure two 10000uF 50V Nichicon caps with my MK-168 tester (firmware 1.10K) and they both keep measure no bigger than 5986uF

Is this the limit of these testers?

The theoretical limit is 100mF and I've tested up to 22mF successfully with several testers.

[dentaku]

I just tried to measure two 10000uF 50V Nichicon caps with my MK-168 tester (firmware 1.10K) and they both keep measure no bigger than 5986uF

Is this the limit of these testers?

The theoretical limit is 100mF and I've tested up to 22mF successfully with several testers.

Yup. I think these two caps might be quite bad. They both measure way too low uF-wise and around 4ohm or more ESR.

I just tried the other capacitor test (C+ESR@TP1:3) you get when you hold down the button and I like it better for testing a bunch of caps because it just keeps testing endlessly. The big caps give me about the same numbers with that test too.

[dentaku]

I just tried to measure two 10000uF 50V Nichicon caps with my MK-168 tester (firmware 1.10K) and they both keep measure no bigger than 5986uF

Is this the limit of these testers?

The theoretical limit is 100mF and I've tested up to 22mF successfully with several testers.

I just did a test and you're right, it can easily do 10mF because I connected two 4700uF caps in parallel and it reads C=10.7mF and ESR=0.04ohm

This give me more confidence that those 10000uF caps are bad. Maybe I can resurrect the Onkyo receiver I removed them from

[radioFlash]

I have a question about the "Button" connection for the Zener expansion option. Should the gate of T4 be tied directly to PD7, or is there supposed to be a button switch between the two, or something else?

Attached is the schematic from the ttester.pdf manual.