$20 LCR ESR Transistor checker project

[madires]

I want to thank Markus for the superb job he`s done with the firmware, and specially thank him for supporting all the hardware that others have developed around his initial project. He's done such a great work, I don't even care about losing 7x1 to Germany!

Actually, there are two Markus'. Markus F. is the original author but abandoned the project. I'm Markus R. and writing the m-firmware. And there's also Karl-Heinz who does the k-firmware and leads the project. It's a lot of fun and I'm happy (I bet Karl-Heinz too) that people like what we've achieved so far.

[timelessbeing]

Everything is in config.h

I was looking for the pin options under the "Hardware options" section where you enable the R.E. and set pulses. Now I see it under the "port and pin assignments" section. Thank you.

I'm having a problem with some random pixels now. They don't appear with the 'K' FW.

[madires]

I'm having a problem with some random pixels now. They don't appear with the 'K' FW.

Looks like to be the 4 pixel offset. Please enable "#define LCD_OFFSET_X" in the display section and try again.

[timelessbeing]

The offset is turned on.

[biohazrd]

Is anyone aware if this is a compatible version? I'd like to pick one up and check the resistor tolerance (although I'm not the best SMD solderer)

[mauroh]

You actually need to comment that line to remove the offset as madires already point it to me.
In my previous post (https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg858999/#msg858999)
You can find the following list of all changes you need to make on the config.h to have the m-firmware working correctly with M12684 DYI Kit


Config.h Changes to work with M12684 DIY KIT (Banggood)

Section:
/*
 *  M12864 DIY Transistor Tester
 *  - ST7585 display
 *  - rotary encoder at PD1/3
 */
Uncomment entire secion and comment other LCD sections

Change to
//#define LCD_OFFSET_X
#define LCD_CONTRAST     5 


Section:
/* **********************************
 *   Hardware options
 * ********************************** */
Uncomment
#define HW_ENCODER
#define HW_REF25

This should be already
#define UREF_25           2495 //Tipical output of TL431AA (you shuld measure it?)


Section:
/* **********************************
 *   port and pin assignments
 * ********************************** */
Change to
#define ENCODER_A        PD1       /* rotary encoder A signal */

Mauro

[mauroh]

In this days I played a bit with the UART output on my M12864 DIY Kit with k-firmware.
The idea is to log on a PC all the measurement and visualize the results on a big Processing display (see attachment).
To simplify the Processing sketch, I added a "new_line" = ("\r\n") at the end of each line of text sent to the UART.
In this way the text on the serial output is much more readable also on a serial terminal and helps me a lot to identify the position of the text and visualize it correctly.
This is the list of all changes I made so far.
Hope this is helpful for someone.

main.c
…………..
    #ifdef WITH_UART
       //uart_putc(' ');      // start of next value                      //MAURO Removed
       uart_newline();                                            //MAURO Added
    #endif
…………..
    #ifdef WITH_UART
       //uart_putc(0x03);   // ETX, start of new measurement  //Mauro Removed
       uart_newline();                                       //MAURO Added
    #endif

**********************
lcd-routines.c
Replaced every uart_putc(' '); with uart_newline();    //MAURO Added

In the "switch(temp1) {" inside the lcd-routines.c the following line were missing causing a corruption in the UART output.
I think this is the biggest bug I can find in this amazing firmware 

    case LCD_CHAR_INDUCTOR1:
    case LCD_CHAR_INDUCTOR2:
       uart_putc('L');
       break;

At the moment I don't know where I need to add the uart_newline();  to wrap the text of the Selection menu 
Now it looks like this:

Selection:
 Switch off     >Transistor      Frequency       Transistor     >Frequency       f-Generator     Frequency      >f-Generator     10-bit PWM      f-Generator    >10-bit PWM      C+ESR@TP1:3     10-bit PWM     >C+ESR@TP1:3     1-RR-LL-3       C+ESR@TP1:3    >1-RR-LL-3       1-||-3           1-RR-LL-3      >1-||-3           C(uF)-correction 1-||-3          >C(uF)-correction Selftest        C(uF)-correction>Selftest        Contrast        C(uF)-correction>Selftest        Contrast        C(uF)-correction>Selftest        Contrast        C(uF)-correction>Selftest        Contrast

And I would like to have it like this:

Selection:
Switch off     
>Transistor     
Frequency       

Transistor     
>Frequency       
f-Generator     

Help Help 

In the mean time I made the last modification to the case 

Mauro

[all_repair]

LCR-TC now in color, and shall probably sell for 50usd on ebay.  Not an owner yet, I can't show more.

That modified firmware has nice graphics. Unfortunately the author doesn't provide the source code and ignores that the firmware is open source. But we have color support too. And I think I'm able to add touch screen support for an ATmega 664/1284 version.

Soon it shall be LCR-TTC or LCR-TCT :-)  I am glad, I did not get every version that came out. 

My first tester is from a French company, MW Instruments, now defunct.  The unit is able to do opto-coupler testing.  And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on.  The various parameters of the coupler are displayed after testing, including the CTR.  Is this a possibility for the your software? 

The layout for the adapter board is attached.  The adapter board is connected by the 3 testing leads to MW tester, and in specific order.

[timelessbeing]

@Mauroh
Thank you very much for that. Disabling the offset fixed the problem.

Uncomment
#define HW_REF25

Since this kit came with 3% regulator, and only 1% reference, this option probably won't make a significant difference.

[timelessbeing]

I discovered some strange things ....

I was checking my fuses:

Code: [Select]

avrdude -c arduino -p m328p -P /dev/tty.usbserial -b 19200 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h

avrdude: Device signature = 0x1e950f
avrdude: reading lfuse memory:
0xf7
avrdude: reading hfuse memory:
0xd9
avrdude: reading efuse memory:
0x4
avrdude: reading lock memory:
0x3f

avrdude: safemode: Fuses OK (H:04, E:D9, L:F7)

That last line worries me because it contradicts the read fuse values. Is that a bug in AVRDUDE?

Writing the lock byte fails:

Code: [Select]

avrdude -P /dev/tty.usbserial -c arduino -p m328p  -b 19200 -B 20 -U lock:w:0xff:m

avrdude: reading input file "0xff"
avrdude: writing lock (1 bytes):

Writing |                                                    | 0% 0.00s ***failed; 
Writing | ################################################## | 100% 0.16s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xff:
avrdude: load data lock data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x3f != 0xff
avrdude: verification error; content mismatch
And setting the efuse fails too:

Code: [Select]

avrdude -P /dev/tty.usbserial -c arduino -p m328p -b 19200 -B 20 -U efuse:w:0xFC:m
avrdude: reading input file "0xfc"
avrdude: writing efuse (1 bytes):

Writing |                                                    | 0% 0.00s ***failed; 
Writing | ################################################## | 100% 0.16s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xfc:
avrdude: load data efuse data from input file 0xfc:
avrdude: input file 0xfc contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x04 != 0xfc
avrdude: verification error; content mismatch

I tried different bit clocks and it doesn't make a difference. Am I missing something?

[tom666]

Writing the lock byte fails and setting the efuse fails too.

It's a problem of undefined bits. For example, the value FC for efuse set this bits to '1' and value 04 set this undefined bits to '0'. Depending on the target device these fuse bits will be read either as '0' or '1'. Therefore, it may cause errors in verification. This same applies to the lock bits, because the upper two bits in the byte are unused.

Note:
I have not noticed the other problems - I recommend updating the program AVRDUDE.

[mauroh]

Since this kit came with 3% regulator, and only 1% reference, this option probably won't make a significant difference.

The voltage reference is a TL431A that should be 2% and the critical resistors at the inputs are 0.1% not 1% as all the others on the board.
It will not change the world but it is better 

The unit is able to do opto-coupler testing.  And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on.  The various parameters of the coupler are displayed after testing, including the CTR.  Is this a possibility for the your software? 

See attached the picture with my version of the opto-coupler adapter 
Yes, it is really ugly but worked with all the opto-coupler I tested so far (4 and 6 pins), not tried with optotriacs.

Mauro

[AlxDroidDev]

Writing the lock byte fails and setting the efuse fails too.

It's a problem of undefined bits. For example, the value FC for efuse set this bits to '1' and value 04 set this undefined bits to '0'. Depending on the target device these fuse bits will be read either as '0' or '1'. Therefore, it may cause errors in verification. This same applies to the lock bits, because the upper two bits in the byte are unused.

Note:
I have not noticed the other problems - I recommend updating the program AVRDUDE.

Actually, I had the same problem, but only when using the latest version of avrdude.exe and avrdude.conf, both downloaded from the site above.

When using the version of avrdude (.exe and .conf ) that comes with Arduino 1.6.7, I have absolutely no problems, including setting efuse.

[madires]

My first tester is from a French company, MW Instruments, now defunct.  The unit is able to do opto-coupler testing.  And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on.  The various parameters of the coupler are displayed after testing, including the CTR.  Is this a possibility for the your software? 

Could be. I have to check if it's feasable.

[timelessbeing]

Writing the lock byte fails and setting the efuse fails too.

It's a problem of undefined bits....

I think it might have to do with the device. When I was flashing a QFP m328p, it didn't care if the upper bits were 0 or 1. This problem started when I tried flashing a DIP package.
It seems logical to me that high bits should be left as '1' since, in Atmel's own words, bits "can be left unprogrammed (“1”) or can be programmed (“0”) to obtain the additional features". Even online fuse calculators (here, here) display the undefined bits as '1'. Oh well.

I recommend updating the program AVRDUDE.

I had the same problem, but only when using the latest version of avrdude.exe ... When using the version of avrdude (.exe and .conf ) that comes with Arduino 1.6.7, I have absolutely no problems...

I am using AVRDUDE 6.0.1, because that's what came with CrossPack (toolchain for Mac OS). The AVRDUDE that is packaged with my Arduino IDE (1.6.1) is also 6.0.1.  The latest version is 6.3.

I'll do some more testing with the undefined bits, and try to find some different AVRDUDE binaries (but I'm not keen on downgrading).

The voltage reference is a TL431A that should be 2% and the critical resistors at the inputs are 0.1% not 1% as all the others on the board. It will not change the world but it is better 

My kit came with a "Wing Shing" brand 431 reference. (datasheet). Grade A = 1% (allegedly, page 3). Its precision is in the same order of magnitude as the regulator. As has been discussed in this topic (and like the config.h comment says), there's no significant improvement from enabling #define HW_REF25, unless the reference is 10x more precise. I plan to order some MCP1702's, so the 431 will be useless anyway.

[timelessbeing]

Code: [Select]

avrdude -c arduino -p m328p -P /dev/tty.usbserial -b 19200 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h

avrdude: Device signature = 0x1e950f
avrdude: reading lfuse memory:
0xf7
avrdude: reading hfuse memory:
0xd9
avrdude: reading efuse memory:
0x4
avrdude: reading lock memory:
0x3f

avrdude: safemode: Fuses OK (H:04, E:D9, L:F7)

That last line worries me because it contradicts the read fuse values. Is that a bug in AVRDUDE?

Confirmed. Bug #45115. Fixed in avrdude 6.1

[mauroh]

My kit came with a "Wing Shing" brand 431 reference. Grade A = 1%

My typo on the 431, yes it is 1%

there's no significant improvement from enabling #define HW_REF25, unless the reference is 10x more precise.
I plan to order some MCP1702's, so the 431 will be useless anyway.

Agree

Mauro

[madires]

My first tester is from a French company, MW Instruments, now defunct.  The unit is able to do opto-coupler testing.  And for the unit to know the "opto-coupler" testing mode, an adapter board need to be attached before powering on.  The various parameters of the coupler are displayed after testing, including the CTR.  Is this a possibility for the your software? 

Could be. I have to check if it's feasable.

After reading a few datasheets of opto couplers I think the CTR could be measured with some caveats. The main problem is current. Considering the LED's voltage drop the tester could drive it with about 5mA using Rl (680 Ohms). But the collector curent will become a problem, since the tester can't provide more than 7mA in a safe way. Though, we could overload the MCU's pin briefly. So an external test adapter with an additional current limiting resistor for the LED (aiming for 1mA) could solve that issue. Or a second resistor for the collector, i.e. the MCU provides full current limited by its internal resistance and the additional resistor limits the maximum current to some acceptable value. Or maybe both to support also couplers with a darlington output stage. But the optimal LED current seems to be around 5-10mA. Either we'd have an optimal LED driver current and a CTR range of maybe up to 500% or a not so ideal drive current and a CTR range of up to 5000%. Any suggestions?

[iamdarkyoshi]

I have a similar one but it uses a graphical LCD. It was a really nice unit. But now it does not work. Maybe a repair thread in the future

[mauroh]

After reading a few datasheets of opto couplers I think the CTR could be measured with some caveats.

This is what I got testing few optocouplers with the actual firmware.

Motorola 4N33   CTR 500% Darlingron
BJT-NPN
hFE=10
Ie=5.2mA
Ube=1.03V     
Pin 1=B 2=E 3=C


Lite-On 817B   CTR 130-260%
BJT-NPN
hFE=1
Ie=3.9mA
Ube=1.09V
Pin 1=B 2=E 3=C


QTC 4N35   CTR 100%
BJT-NPN
hFE=0
Ic=0uA
Ube=807mV
Pin 1=B 2=E 3=C

Not bad for a PASS/FAIL test and the measured "hFE" gives a reasonable indication of the order of magnitude of the CTR.
Mauro

[all_repair]

After reading a few datasheets of opto couplers I think the CTR could be measured with some caveats. The main problem is current. Considering the LED's voltage drop the tester could drive it with about 5mA using Rl (680 Ohms). But the collector curent will become a problem, since the tester can't provide more than 7mA in a safe way. Though, we could overload the MCU's pin briefly. So an external test adapter with an additional current limiting resistor for the LED (aiming for 1mA) could solve that issue. Or a second resistor for the collector, i.e. the MCU provides full current limited by its internal resistance and the additional resistor limits the maximum current to some acceptable value. Or maybe both to support also couplers with a darlington output stage. But the optimal LED current seems to be around 5-10mA. Either we'd have an optimal LED driver current and a CTR range of maybe up to 500% or a not so ideal drive current and a CTR range of up to 5000%. Any suggestions?

Maybe can tap out the VCC, and push some complexity to the adapter board?  So far, I am an armchair user for these testers, and got not much knowledge on the working.  Please be kind with me :-)

Two pages from the MW tester, one is the base circuit, and one of the opto-coupler test adapter.  I hope many more type of opto-coupler can be tested, as more and more are using those with built-in drivers.

[madires]

Not bad for a PASS/FAIL test and the measured "hFE" gives a reasonable indication of the order of magnitude of the CTR.

We can do better than that

[madires]

Two pages from the MW tester, one is the base circuit, and one of the opto-coupler test adapter.  I hope many more type of opto-coupler can be tested, as more and more are using those with built-in drivers.

Thanks for the PDFs! At the moment I think that the approach with 5mA I_f and a brief pin overload for I_c is the best option. Maybe I find a solution to support also high CTRs.

[speedy29]

@speedy29

Attached zip file contains the original firmware for Fish8840. It is of course possible to use the k-version software from the SVN repository (directory mega328_fish8840).

Fuse settings fot M328P:
lfuse:0xf7 hfuse:0xd9 efuse:0x04 (0xfc)

Fully functional.

 Thank you again

[mauroh]

Karl-Heinz made a new build of the k firmware (656) that support 2 decimal places for the hFE!!!
I tested some optocouplers with great and consistent results.

Thank you Karl-Heinz 

Toshiba P181 GB Datasheet CTR 100-600   (3 different devices)
BJT-NPN    hFE=2.71   Ie=4.4mA  Ube=1.07V
BJT-NPN    hFE=1.96   Ie=4.1mA  Ube=1.08V
BJT-NPN    hFE=2.12   Ie=4.2mA  Ube=1.08V

Sharp PC817A  Datasheet CTR 80-160  (2 different devices)
BJT-NPN    hFE=.64     Ie=3.4mA  Ube=1.11V
BJT-NPN    hFE=.84     Ie=3.6mA  Ube=1.10V

Liteon 816A Datasheet CTR 80-160   (2 different devices)
BJT-NPN    hFE=1.01   Ie=3.7mA  Ube=1.11V
BJT-NPN    hFE=.84     Ie=3.6mA  Ube=1.10V

Motorola 4N33 Datasheet CTR > 500    (2 different devices)   
BJT-NPN    hFE=6.00   Ie=4.9mA  Ube=1.05V
BJT-NPN    hFE=10.4   Ie=5.2mA  Ube=1.04V

QTC 4N35 Datasheet CTR 100         
BJT-NPN    hFE=.83     Ie=3.6mA  Ube=1.09V

Kento JC817 Datasheet CTR 50-600      
BJT-NPN    hFE=1.51   Ie=4.0mA  Ube=1.09V

Liteon 817B Datasheet CTR 50-600   (3 different devices)
BJT-NPN    hFE=1.23   Ie=3.8mA  Ube=1.10V
BJT-NPN    hFE=1.38   Ie=3.9mA  Ube=1.10V
BJT-NPN    hFE=1.28   Ie=3.9mA  Ube=1.09V

Sharp PC123E Datasheet CTR 50-600  (4 different devices)
BJT-NPN    hFE=.95    Ie=3.7mA  Ube=1.10V
BJT-NPN    hFE=.75    Ie=3.5mA  Ube=1.10V
BJT-NPN    hFE=.95    Ie=3.7mA  Ube=1.10V
BJT-NPN    hFE=.82    Ie=3.6mA  Ube=1.10V

MOC3041 OptoTriac               
BJT-NPN    hFE=326   Ic=2.8mA  Ube=821mV