$20 LCR ESR Transistor checker project

[hapless]

I'm really scratching my head here. Yes, those should be the two outer holes. Can you measure voltage across the component marked P6KE6V8 while the short is in place?

i just noticed that the board has top & bottom traces. does that mean the solder tin should goes through bottom-up on each component's pin?

Only if your board is damaged or poorly made. Normally, the vias conduct from top to bottom even when no component is inserted.

[madcat]

I'm really scratching my head here. Yes, those should be the two outer holes. Can you measure voltage across the component marked P6KE6V8 while the short is in place?

if you meant this smd diode component (pic attached), it just marked "AK" on mine. (cheaper one?  )
with 9012 holes shorted, i got 4.96v measured on that diode.
while at 7550 pins, i got Vin = 8.03v , Vout = 4.96v.
input power source was at 8.50v.

just to make it clearer, the 2 pcs of 9014 transistor should be out-of-circuit also while doing this measurement, right?

[hapless]

Your socket is covering the silk-screened markings. It's the right part though. But now I'm completely lost. V_cc is correct, so you should at least be seeing the backlight come on. Wait, please tell me you are doing this with the LCD connected. Otherwise you can't tell if the tester is on or off, much less whether it goes through the normal routine or not!

just to make it clearer, the 2 pcs of 9014 transistor should be out-of-circuit also while doing this measurement, right?

Doesn't matter. But keep them out for now.

[madcat]

Your socket is covering the silk-screened markings. It's the right part though. But now I'm completely lost. V_cc is correct, so you should at least be seeing the backlight come on. Wait, please tell me you are doing this with the LCD connected. Otherwise you can't tell if the tester is on or off, much less whether it goes through the normal routine or not!

you've nailed on that one.
yes, i was not put the LCD connected, just watched for the red LED was not turned on. 

ok now with LCD connected i got Battery&VCC measurement display at start, then it displays:
* "Cell!" with some numbers in mV

for some seconds, it displays blinking "Short Probes!"

*update :
it actually gives some different displays when the input jack is disconnected-reconnected.
now it displays "No, unknown, or damaged part?" although i put 1Mohm resistor on pin 1-3 of the zif socket.

[hapless]

You can remove the short and put all transistors back in. What kind of flux are you using?

[madcat]

You can remove the short and put all transistors back in. What kind of flux are you using?

when i was about to resolder the transistors back, i noticed that i've carelessly lifted the top side trace of right pin (3rd pin) of 9014 next to 7550 (see pic below...  ).
however, it seem that it doesn't have top side traces connected to it, only its bottom side has. the bottom side is fine though.
but when the tester was turned on, it still displayed Battery&Vext measurement like before.. 

is it possible that the lifted trace caused the problem?


about the flux, i used a non-brand liquid flux in pen applicator (bought in local store) when assembled the tester. it made the solder tin melted fast, but it less shinny after it cool down.
when i desoldered and soldered back, i use lotfett brand (i don't know it is original or not.. it is in hard plastic container), it is in paste-form and the solder tin result is shinny.

[jleg]

about the flux, i used a non-brand liquid flux in pen applicator (bought in local store) when assembled the tester. it made the solder tin melted fast, but it less shinny after it cool down.
when i desoldered and soldered back, i use lotfett brand (i don't know it is original or not.. it is in hard plastic container), it is in paste-form and the solder tin result is shinny.

i once got quite frustrated, because it seemed each project i was working on had strange issues of all kinds. After some "deeper investigation" i discovered, that my used "non-brand flux pen" sequested something which had only a few ohms resistance, even if applied to a paper and fully dried.. 
After "fixing" this my success rate went up again! 

[timelessbeing]

It's difficult to tell from the photo... it just looks like brown spot, but it's possible that the transistor leg isn't connected to the top of the board at all. But only you know the answer ... test the continuity with you multimeter.

Also, the yellow capacitor in front of it looks like it has a dry joint. In the other previous photos you posted, there is too much solder on resistors etc. You should search around Youtube for some soldering tutorials. Maybe Dave has some too.

[imidis]

It does look like quite a few solder joints are not as they should be. Are you using solder with lead/flux core? It should look more cone shaped rather than balls and if lead based it should be shiny. You want to make sure to heat up the pad and the lead, but not too hot, there is not a lot of mass on the board, so if using leaded solder probably 270-290 Celsius should be sufficient.  I only used flux on the SMD components for mine.

[hapless]

Don't forget though that you're looking at the side opposite to where soldering was done. There's likely a good electrical connection despite the way it looks from the top.

is it possible that the lifted trace caused the problem?

No, you said it yourself, the trace is not connected on the top of the board.

about the flux, i used a non-brand liquid flux in pen applicator (bought in local store) when assembled the tester. it made the solder tin melted fast, but it less shinny after it cool down.
when i desoldered and soldered back, i use lotfett brand (i don't know it is original or not.. it is in hard plastic container), it is in paste-form and the solder tin result is shinny.

i once got quite frustrated, because it seemed each project i was working on had strange issues of all kinds. After some "deeper investigation" i discovered, that my used "non-brand flux pen" sequested something which had only a few ohms resistance, even if applied to a paper and fully dried.. 
After "fixing" this my success rate went up again! 

This. To me it seems like your no-name brand flux contains some acid which is somewhat conductive. You need to wash, clean and dry your board really-really well. You've tested the transistors, so the there are only two things I can think of now that could be causing the problems you're experiencing: conductive flux or bad ATMega. I think it's the flux. Clean your board inside and out, then clean it again. I hope this helps.

[upsss]

I have a couple firmware questions. 

1) My understanding is that the accuracy of the measurements depends on the accuracy of external 2.5V Reference voltage (assuming you have one), is that correct?

2) If you don't have an external voltage reference then the firmware is using the Vcc as a reference voltage.  Dose the software automatically checks the voltage on the reference voltage pin or you have to change the firmware and tell it that you don't have an external voltage reference?

[madires]

Yes, the firmware (k and m) uses the external 2.5V reference to determine the offset of Vcc (5V). Therefore the reference should be much more accurate than the 5V voltage regulator. But you don't need to have the external reference, you could also have an accurate LDO or measure the output voltage of the voltage regulator and adjust the value in the firmware. The presence of the external reference is checked by the firmware. If there's none the tester assumes that Vcc is 5V. The m-firmware has additionally a configuration switch for enabling the external reference (disabling it, saves a few bytes flash).

[madcat]

i once got quite frustrated, because it seemed each project i was working on had strange issues of all kinds. After some "deeper investigation" i discovered, that my used "non-brand flux pen" sequested something which had only a few ohms resistance, even if applied to a paper and fully dried.. 
After "fixing" this my success rate went up again! 

It's difficult to tell from the photo... it just looks like brown spot, but it's possible that the transistor leg isn't connected to the top of the board at all. But only you know the answer ... test the continuity with you multimeter.

Also, the yellow capacitor in front of it looks like it has a dry joint. In the other previous photos you posted, there is too much solder on resistors etc. You should search around Youtube for some soldering tutorials. Maybe Dave has some too.

This. To me it seems like your no-name brand flux contains some acid which is somewhat conductive. You need to wash, clean and dry your board really-really well. You've tested the transistors, so the there are only two things I can think of now that could be causing the problems you're experiencing: conductive flux or bad ATMega. I think it's the flux. Clean your board inside and out, then clean it again. I hope this helps.

hi, i'm sory i had quite busy time i wasn't able to sit in front of my computer these few days.
thank you very much for all your comments & suggestions, it really helps in my learning curve about soldering.
yes, i also think that the problem caused by my limited soldering experience and tools i used. lesson learned. 

btw, in order to wash the board, is it ok to just dip it in isoprophyl alcohol (with ATMega chip removed) and brush it?
or is it better to desolder all the components first, wash the board clean and re-solder the components back?

[1413]

btw, in order to wash the board, is it ok to just dip it in isoprophyl alcohol (with ATMega chip removed) and brush it?
or is it better to desolder all the components first, wash the board clean and re-solder the components back?

Just use isopropyl alcohol, tooth brush and tissue to remove any residues or flux. Don't need to desolder anything.

I only use extra flux to help remove excess solder from solder bridges or fix overheated solder joints since apply heat too long will burn the flux. Otherwise, the amount of flux inside the solder wire is enough. But of-course, I would clean up the remain flux after finish soldering.

[avrishuvorlaz]

To me, it looks like maybe we're trying too hard: perhaps no flipping is required at all. Here's an "unflipped" version. Makefile included.

Mr hapless, master of LCR firmwares, I used your "TransistorTester (as above, but no flipping).zip" on my device which was originally on the "Mtester" firmware, and it works a treat... but one thing I have noticed is this - the characters seem to be shifted too far to the right by 0.5-1 characters - do you know how I would resolve this? The typeface is nice and bold - maybe a little TOO bold, at the expense of the chars flowing off the right hand side of the LCD.

Here is the exact model I own, together with the graphics overflow (right hand side of LCD) shown - I bought from "comecome28" on eBay, this listing: http://www.ebay.co.uk/itm/112259073834









Thanks Sir. 

[madcat]

Just use isopropyl alcohol, tooth brush and tissue to remove any residues or flux. Don't need to desolder anything.

I only use extra flux to help remove excess solder from solder bridges or fix overheated solder joints since apply heat too long will burn the flux. Otherwise, the amount of flux inside the solder wire is enough. But of-course, I would clean up the remain flux after finish soldering.

hi, thank you for the tips.
i have brushed it with IPA, top&bottom side of it, and have some progress after that.   

the tester now is able to do :
  * selftest works (shows v1.12 at the end)
  * LEDs & diode test works
  * capacitor test is quite accurate with 5-10% tolerance
  * BJT NPN transistor test works
  * rotary encoder works a little awkward at menu selection (rotate left goes down, rotate right goes up - i don't know it is normal or not, but it works)

what's not working :
  * testing IRF9540N P-mosfet (new stock one) recognized as dual-diode with wrong pin numbers, and different result when the transistor put reversed. (see attached pics)
  * testing N-mosfet recognized as dual-diode too.
  * unable to test 100K & 1M ohm resistor, result as "no, unknown or damaged part"

what do you think guys?
based on what's working and not working, is my tester still has problem? or it has functioning as it is?


*UPDATE*
just noticed that the tester failed to detect base, emitter and collector of D965 BJT NPN transistor (see 3rd pic).
according to D965 datasheet, pin 2 is collector, while the tester gives result that pin 2 is emitter.   
maybe my tester is still not work normally?

[madires]

Mr hapless, master of LCR firmwares, I used your "TransistorTester (as above, but no flipping).zip" on my device which was originally on the "Mtester" firmware, and it works a treat... but one thing I have noticed is this - the characters seem to be shifted too far to the right by 0.5-1 characters - do you know how I would resolve this? The typeface is nice and bold - maybe a little TOO bold, at the expense of the chars flowing off the right hand side of the LCD.

It's the horizontal offset LCD_ST7565_H_OFFSET. In case it's set to 4, change it to 0, or vice versa. That is caused by the way the LCD is connected to the controller and if horizontal flip is enabled or not. The controller supports 132 pixels but the display has only 128.

[madires]

Meanwhile I've got a few cheap and crappy RC servos for testing the servo check function. Based on them the best range for the pulse length seems to be 0.5 - 2.5 ms (instead of 1 - 2 ms). Do you got similar experience? I've also received some PCF8574 based LCD backpacks which work fine. The new m-firmware version will have a simple I2C framework supporting the ATmega's TWI and bit-bang I2C. So we can add more I2C clients. While investigating LCD backpacks I saw also some MCP23008 based ones. A good opportunity if you like to sponsor the m-firmware Or do you got any other I2C wishes?

[hapless]

Mr hapless, master of LCR firmwares, [...]

Heh, that's very kind of you, but there are people around here who are much more deserving of the title...

[...] I used your "TransistorTester (as above, but no flipping).zip" on my device which was originally on the "Mtester" firmware, and it works a treat... but one thing I have noticed is this - the characters seem to be shifted too far to the right by 0.5-1 characters - do you know how I would resolve this? The typeface is nice and bold - maybe a little TOO bold, at the expense of the chars flowing off the right hand side of the LCD.

The fonts are monospaced, so it's the width of the characters that matters, otherwise bold ones can be the same width as the thin ones. It's more of a matter of taste. As madires pointed out, the problem is with the offset that was deliberately used so that the exact same issue would be fixed for devices that have their screens rotated 180 degrees. I'm attaching a build that should fix this for you, but it doesn't use the exact same Makefile, so please let me know if I accidentally broke something.

Note: I made some (very few) slight changes to the output of the code. They are not even worth mentioning, but don't be surprised if you see that "Version1.13" now has a space in it or that "4 * ->|-" shows as "4 x ->|-".

[...]
i have brushed it with IPA, top&bottom side of it, and have some progress after that.   
[...]
maybe my tester is still not work normally?

I'm very happy that it's finally starting to work, but you need to need to give it at least one more go with water (try to dry it as quickly as possible!) and then alcohol. Clean very thoroughly. You'll probably also want to clean between the pins of the MCU, too (just in case). Just make sure it's completely dry before powering up the board, and, of course, be gentle enough not to damage anything while you're at it.

[avrishuvorlaz]

Mr hapless, master of LCR firmwares, [...]

Heh, that's very kind of you, but there are people around here who are much more deserving of the title...

[...] I used your "TransistorTester (as above, but no flipping).zip" on my device which was originally on the "Mtester" firmware, and it works a treat... but one thing I have noticed is this - the characters seem to be shifted too far to the right by 0.5-1 characters - do you know how I would resolve this? The typeface is nice and bold - maybe a little TOO bold, at the expense of the chars flowing off the right hand side of the LCD.

The fonts are monospaced, so it's the width of the characters that matters, otherwise bold ones can be the same width as the thin ones. It's more of a matter of taste. As madires pointed out, the problem is with the offset that was deliberately used so that the exact same issue would be fixed for devices that have their screens rotated 180 degrees. I'm attaching a build that should fix this for you, but it doesn't use the exact same Makefile, so please let me know if I accidentally broke something.

Note: I made some (very few) slight changes to the output of the code. They are not even worth mentioning, but don't be surprised if you see that "Version1.13" now has a space in it or that "4 * ->|-" shows as "4 x ->|-".

[...]
i have brushed it with IPA, top&bottom side of it, and have some progress after that.   
[...]
maybe my tester is still not work normally?

I'm very happy that it's finally starting to work, but you need to need to give it at least one more go with water (try to dry it as quickly as possible!) and then alcohol. Clean very thoroughly. You'll probably also want to clean between the pins of the MCU, too (just in case). Just make sure it's completely dry before powering up the board, and, of course, be gentle enough not to damage anything while you're at it.

Ah, thank you, Sir, you are very kind. How does one know which way is the "normal" orientation of the LCD, and which way is 180 deg rotated? Mine has the ribbon coming out of the top edge, as most I have seen seem to, and the backlight LED is to the right of the display when the ribbon is uppermost.

I'll give that newer firmware you've built a whirl, thanks. Out of interest, how do I go about compiling my own? Additionally, could you send me the source of the flipped/working one which I referred to in my last post, since there seems to be one billion different variants, builds, modified versions etc... it's all a little confusing, hah!

Thanks yet again.

[mauroh]

Meanwhile I've got a few cheap and crappy RC servos for testing the servo check function. Based on them the best range for the pulse length seems to be 0.5 - 2.5 ms (instead of 1 - 2 ms). Do you got similar experience? I've also received some PCF8574 based LCD backpacks which work fine. The new m-firmware version will have a simple I2C framework supporting the ATmega's TWI and bit-bang I2C. So we can add more I2C clients. While investigating LCD backpacks I saw also some MCP23008 based ones. A good opportunity if you like to sponsor the m-firmware Or do you got any other I2C wishes?

Hi Markus, this is a great news 

Regarding the servo check function, AFAIK the center position should be for a pulse width of 1.5ms, the lowest and highest value varies for each servo.
The cheap servo checker available on ebay has 3 functions:
- center
  It provide a signal with 1.5ms pulse width every 20ms. This is very useful setting up the RC models
- manual
  Rotating the knob it provide the signal depending by the position of the knob from 1 to 2 ms
- Auto
  It sweep between the min and max pulse width continuously from 1 to 2 ms

Mauro

[avrishuvorlaz]

Please read - I wish to help with the development of this product.

I am experienced with Linux, Windows & macOS, I have no problem understanding concepts such as "$PATH", "ls", I am VERY much a command line person in regards to Unix OS' specifically.

Okay, I have Windows 7 and I have installed WINAVR, and I have also gone to:

https://www.mikrocontroller.net/svnbrowser/transistortester/Software/trunk/ and clicked "Download GNU tarball" - I have it downloaded and extracted with 7-zip etc...

#1 I know what a "Makefile" is, in essence, but...
#2 Once unarchived, which DIR do I go into, and which file do I edit for my customisations, please?
#3 From which folder do I run "make", once I have edited my "Makefile", and saved it, from the above?

If you'd give me a "starters guide" (I tried searching this thread, it's a NIGHTMARE to find what I need!) I would very much appreciate it, and can then start helping people. I am a VERY fast learner, I just need a "kick start" guide to what DIR, what commands etc - I know how to flash the firmware etc, it's just the configurations I need explained to me, and how to "make".

WINAVR is in my "PATH" by the way, so that's all setup as default.

Thanks so much!


<UPDATE>

I think I've worked it out:

Say I want to edit the options and compile the firmware for the "mega328_T3_T4_st7565" variant, I simply:

1/ Go to where that folder is, in my case "C:\Users\Myname\Desktop\transistortester-trunk.tar\transistortester-trunk\trunk\mega328_T3_T4_st7565" and edit the "Makefile" for the options I want.

2/ Open  a CMD window in that "C:\Users\Myname\Desktop\transistortester-trunk.tar\transistortester-trunk\trunk\mega328_T3_T4_st7565" DIR, and run "make" ... right?

3/ Flash the freshly built .eep and .hex into my T4 and test, rinse and repeat until it works as desired.



Ah, once I had worked that out, I went to: https://github.com/svn2github/transistortester/tree/master/Software/trunk

... and read:

This directory contains the program source for all TransistorTester versions.
To build the programming files for your ATmega microcontroller
please change to one of the following subdirectories:
mega8, default, mega328, mega168_strip_grid, mega328_strip_grid, mega328_dogm and mega328_strip_grid_dogm

The mega8 subdirectory contains the Makefile to build the programming data for a ATmega8 microcontroller.
The default subdirectory contains the Makefile to build the programming data for a ATmega168 controller.
The mega328 subdirectory contains the Makefile to build the programming data for a ATmega328 controller.
The subdirectories with the _strip_grid ending contains the Makefiles for the different connection
of the LCD used for the strip grid board and can not be used with the normal connection of the LCD.
You can find the programming data and the matching Makefile for the DOGM style LCD in the subdirectories
with dogm ending (mega328_dogm and mega328_strip_grid_dogm).

All subdirectories hold the Makefile the compiled data TransistorTester.hex and TransistorTester.eep!
The .hex data must be loaded to the flash memory and the .eep data must be loaded to the EEprom memory.
With the Linux operating system or with WinAVR the data can be loaded with the program avrdude to the
memory of the ATmega, controled with the Makefile. The connected ISP programmer must be supported by the program avrdude.
The data can also be loaded with any other program to the ATmega without control of the Makefile.

You can also create a own subdirectory and copy any of the Makefiles of the other directories to this
own subdirectory. Now you can set other options in this Makefile copy in your directory and try to build
your own TransistorTester programming data in this directory.

Please tell me, if you have problems with my software or if you have found errors.
You can send me a Email to kh_kuebbeler@web.de or answer to my www.mikrocontroller.net thread.

Good luck
Karl-Heinz Kübbeler

So it seems I was on the right track?


I did a test "make" from the folder named above, and also saw the "107%" error for the main .hex, which was mentioned elsewhere due to inefficiencies in a new(?) toolchain, etc, as seen here:



How do I fix that? Clearly I can't fit 107% of something into 100% of program space, hah!


I saw "AVR Studio" mentioned somewhere - I take it that is not a pre-requisite? Not a problem if it is, but I get a hunch it's not needed.

See, I am a fast learner!

Cheers for your assistance, take it easy, I'll come back in about 10 hours or so. Sleep time now... zzzzzz

[casinada]

Madcat,
i have a bag of n-mosfets i puchased from ebay that show as double diodes and that is bcause they are 
there are all sort of fake components out there so be careful.
Before start testing unknown components make sure you test a set of known good components. 

[timelessbeing]

I tried searching this thread, it's a NIGHTMARE to find what I need!

I should remind everybody, if you are responding to a post immediately before (or even a ¡few before) yours, there is no need to 'Quote' their entire post. This makes the forum more difficult to read. Especially, when a post three pages long and full of pictures, gets quoted over and over again. Please use 'Reply' instead. Also if you're responding to just one particular sentence, you can trim out everything else.

(I realize that one of the problems is that the reply button is only at the top and bottom of the page. On other forums I've seen it conveniently placed at the end of each post. I think I might mention it to the mods.)

[timelessbeing]

So it seems I was on the right track?

I did a test "make" from the folder named above, and also saw the "107%" error for the main .hex

I think you are on the right track.

Where did you get your toolchain? What is your compiler version?

The oversized hex files has been brought up a few times. It's always caused by one of two problems. Either the wrong format (Intel) is being specified to AVRDUDE. I don't think that's your case since you're using a makefile. Yes, the other cause is using the wrong version of compiler (AVR-GCC). The solution that people suggested was either using an older version, or using the one included with the Arduino IDE (free one, not AVR Studio). I have been using the latest build (6.2.0) without problem. Since you are familiar with Linux, try cloning the 'gcc-avr' repository.

Here's a link with details.