Author Topic: $20 LCR ESR Transistor checker project (Read 3451857 times)

Dwaine · « **Reply #2225 on:** July 17, 2016, 06:30:10 am »

Quote from: hansibull on June 20, 2016, 10:24:38 am

I got my TC1 component tester with color LCD in the mail today, and I'll have to say I'm impressed! It got a step-up circuit for measuring zener diodes with a higher breakdown voltage of 4.7v. The battery is a rechargeable 3.7v Litium ion battery, that can be charged with a micro USB cable. Here are some pictures of it! (Open the pics in a new tab for even higher resolution)

Nice. I ordered one off eBay. Can you update it with the existing github code? Or you stuck with the existing firmware loaded on the device.

Willem52 · « **Reply #2226 on:** July 17, 2016, 08:02:34 am »

@eeadata :
I had the same issue, but got a programmed and working IC replacement for free.

eeadata · « **Reply #2227 on:** July 17, 2016, 08:14:20 am »

any one have programming hex files for this tester ? Maybe i can be it programmed here .

stj · « **Reply #2228 on:** July 17, 2016, 09:46:30 am »

you mean the colour-tft one? they are posted a few pages back.

https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg969074/#msg969074

Per Hansson · « **Reply #2229 on:** July 17, 2016, 10:45:40 am »

For those of you following along regarding my previous post.
In my Mcumall GQ-4X programmer I have the buffer tab for the code (the HEX file) and the data tab for the eeprom (the EEP file)
I noticed the problem now, the data tab goes up to 3FF which is 1024 bytes.
So anything after that gets clipped...
Now you might want to blame the programmer and rightly so but I'm not sure what is being done here.
Looking at the specs for the Atmega328P it has a 32KB flash area, an EEPROM of 1024 bytes and a SRAM of 2KB.
Looking at the EEP files all the ones that did not work are in the range of 2.5KB, so obviously they where clipped by the programmer.
But then again it means the SRAM and EEPROM area is being combined so I'm not sure how that is supposed to work...
Any idea how avrdude handles it? Because I see it's just specifying the file and to send it to EEPROM: "-U eeprom:w:TransistorTester.eep".
But since that's 1024 bytes in the specification does it just fill over into the SRAM or what?
And isn't the SRAM itself volatile memory? Or did Atmega simply use flash for it to save on costs?

madires · « **Reply #2230 on:** July 17, 2016, 11:17:35 am »

The HEX and EEP files are the firmware in Intel encoded format, not any direct binary image.

Per Hansson · « **Reply #2231 on:** July 17, 2016, 12:06:30 pm »

Aww thanks!
When I open the firmware file for the flash my programmer asks if it should be in Intel encoded format which I answer yes to.
Next for the eeprom "data" window I simply used drag and drop.
It does not ask then about the format so I assumed it uses the same as for the flash.
Well turns out that is not what happens at all!
The files I've tested are named TransistorTester.hex for the flash and TransistorTester.eep for the EEPROM.
Well turns out if I rename the TransistorTester.eep to "Something.hex" it also does not ask about encoding format.
But it does then convert it to Intel encoded format!

And now while testing it some more to get some screenshots it always converts even the eep file to Intel hex without asking!
Murpy's law!!!

vinceroger · « **Reply #2232 on:** July 17, 2016, 12:16:46 pm »

Quote from: Per Hansson on July 17, 2016, 12:06:30 pm

Aww thanks!
When I open the firmware file for the flash my programmer asks if it should be in Intel encoded format which I answer yes to.
Next for the eeprom "data" window I simply used drag and drop.
It does not ask then about the format so I assumed it uses the same as for the flash.
Well turns out that is not what happens at all!
The files I've tested are named TransistorTester.hex for the flash and TransistorTester.eep for the EEPROM.
Well turns out if I rename the TransistorTester.eep to "Something.hex" it also does not ask about encoding format.
But it does then convert it to Intel encoded format!

And now while testing it some more to get some screenshots it always converts even the eep file to Intel hex without asking!
Murpy's law!!!

I was having issues with my programer so i messaged a user on here who had the exact programer as mine this was his relpy
This is the picture with the correct settings for the programmer.
https://www.dropbox.com/s/zqacxby4ayngy2c/Fuses%20on%20TL866A.jpg?dl=0

The only thing you need to do is to load the TransistorTester.hex in the "Code Memory" and the TransistorTester.eep in the "Data Memory"
Pay attention and use always "INTEL HEX" as File Format when you load the files. By default the TransistorTester.eep will be recognized as Binary and you have to change it during loading.

stj · « **Reply #2233 on:** July 18, 2016, 07:01:23 am »

@madires

your 20MHz build for M328p is broken.

stj · « **Reply #2234 on:** July 18, 2016, 07:14:34 am »

latest trendy build for GM328A/r units.

one day i may consider the trendy useable, but not while it interprets the button as up/down making it a bastard to actually use the menu's with an encoder!

K version has similar problems - but i patched most of that.

madires · « **Reply #2235 on:** July 18, 2016, 09:00:56 am »

Quote from: stj on July 18, 2016, 07:01:23 am

@madires

your 20MHz build for M328p is broken.

Thanks for the feedback! I haven't tested it myself yet. Could you please a little bit more specific?

stj · « **Reply #2236 on:** July 18, 2016, 09:04:35 am »

not really, stupid "programmers notepad" IDE wouldnt let me copy/paste from the feedback window.

in simple terms, it wouldnt build because of something missing.
take the zip i just posted, it has the changed configs in it. ( in the interests of "open-source"

)
use those and change it to 20MHz - that will give you what i was running.

madires · « **Reply #2237 on:** July 18, 2016, 09:16:36 am »

Quote from: stj on July 18, 2016, 07:14:34 am

latest trendy build for GM328A/r units.

one day i may consider the trendy useable, but not while it interprets the button as up/down making it a bastard to actually use the menu's with an encoder!

In case you haven't noticed it, in the m-firmware the menu is controlled differently for a push button and a rotary encoder:

Pushbutton only:
- short key press for next item
- long key press for running item

Rotary encoder:
- left/right for previous/next item
- key press for running item

If you enabled the rotary encoder you can't up/down the menu items with the button, unless you got a very poor rotary encoder creating right/left pulses when pressing the push button.

stj · « **Reply #2238 on:** July 18, 2016, 09:20:21 am »

encoder works fine,
what i mean is - example.
i go to the contrast setting, use the encoder to get the value,
then press the button and the value changes instead of exiting or something.

what i did on the K firmware was add some "else" statements into the code for the encoder so if an encoder is enabled, some of the button functions are not used.

madires · « **Reply #2239 on:** July 18, 2016, 09:57:11 am »

Quote from: stj on July 18, 2016, 09:20:21 am

what i mean is - example.
i go to the contrast setting, use the encoder to get the value,
then press the button and the value changes instead of exiting or something.

I see. The common way to exit any tool/feature is to press the push button twice. It's the same for the rotary encoder to keep the UI consistent. I understand that some people would prefer a simple key press for exiting. Actually, you're the first one complaining about that. Implementing a single-push-exit would require to write two versions of most tools/features, because the UI and actions (loop logic) are interwoven. And it's already hard enough to support all the different hardware options. I'll put it on the to-do list, but way down in the nice-to-have section.

madires · « **Reply #2240 on:** July 18, 2016, 10:59:06 am »

Quote from: stj on July 18, 2016, 09:04:35 am

in simple terms, it wouldnt build because of something missing.
take the zip i just posted, it has the changed configs in it. ( in the interests of "open-source" )
use those and change it to 20MHz - that will give you what i was running.

So far it worked as intended

For 20MHz you need to adjust the ADC clock in config.h to 156250Hz:

Quote

//#define ADC_FREQ 125000
#define ADC_FREQ 156250

That's required because of the limited ADC clock prescaler, it supports only 2, 4, 8, 16, 32, 64 and 128. As I noted before, I haven't tested the 20MHz MCU clock rate yet, but I'd appreciate if someone does (less work for me

.

BTW, the current version under development supports JFETs with (very) low I_DSS, e.g. PN4117A, and also handles Germanium BJTs with high leakage current now. Those were detected as JFET when the leakage current was >700µA. Are there any p-channel JFETs with very low I_DSS? I've got only n-channel types.

hapless · « **Reply #2241 on:** July 19, 2016, 06:53:03 pm »

Do Germanium diodes still need to be cooled down?

Also, is there any noticeable advantage in going up to 20MHz from 16?

madires · « **Reply #2242 on:** July 19, 2016, 07:48:16 pm »

Yes, cooling helps with problematic Germanium diodes. I haven't looked into this yet since I got only one of those for testing. The typical A118 and AA143 are detected correctly without cooling. The 20 MHz MCU clock could improve some measurements slightly in theory and it allows higher frequencies for the squarewave generator. It's still untested (but on my to-do list). Currently I don't see any particular reason for 20MHz. So don't get too excited

dimitrov2000 · « **Reply #2243 on:** July 20, 2016, 05:21:06 pm »

Hi guys,
A little help here, please.
Just received my unit from China and it seems to work quite well for now.
There is only one thing that's driving me mad:
Where the heck I have to connect signal and ground to measure frequency?
When I activate the option from the menu the display says: 0 Hz, waiting for input signal.
Tried all the available 3 pins - no luck. Reading the original authors manual, says the frequency
is measured at pin 6 of the chip, followed by long, long explanation for the accuracy of the measurement...
No word about input socket or pins. I see at the oldest versions there are pins: "F-In" or something similar.
Here there is nothing. I doubt that I have to solder directly on pin 6, right?
Help please...

madires · « **Reply #2244 on:** July 20, 2016, 06:19:08 pm »

Please read section "2.2.4 Frequency Measurement" in Karl-Heinz' documentation. There's a nice circuit you'll need for the frequency counter. The manufacturer of your clone enabled the frequency counter in the firmware without adding the necessary circuitry.

dimitrov2000 · « **Reply #2245 on:** July 21, 2016, 06:12:14 am »

Thank you. I'll read it.

madires · « **Reply #2246 on:** July 22, 2016, 07:17:48 pm »

Quote from: madires on July 19, 2016, 07:48:16 pm

Yes, cooling helps with problematic Germanium diodes. I haven't looked into this yet since I got only one of those for testing. The typical A118 and AA143 are detected correctly without cooling.

After trying several ideas I've found a way to support Germanium diodes with very low Vf, when measured with Rh (470k). I think, it will also help with Germanium diodes with a high leakage current, but I don't got any of those for testing.

bmht · « **Reply #2247 on:** July 22, 2016, 08:56:53 pm »

Hello guys
This is my fist post here

My unit arrived from China and after assembly when I try to turn it on the LCD just flickers or stays lit if I keep the rotary button pressed but nothin else on the screen.
I have measured the voltage between pins 7 and 22 and I got 5 volts.

I'm hoping that you guys if you know could lead me to a solution?
I do not know exacly wich is the firmware I would have to download for this specific model or how to do it
I got an USBASP and I would really appreciate if you guys could point me to a solution.
Sorry if my english is bad since it's not my mother language.
I post some images

Here is the flicker

Thanks
Belen

madires · « **Reply #2248 on:** July 22, 2016, 09:03:15 pm »

Does the display stay powered on for a few seconds after pressing the rotary encoder?

bmht · « **Reply #2249 on:** July 22, 2016, 10:14:58 pm »

Quote from: madires on July 22, 2016, 09:03:15 pm

Does the display stay powered on for a few seconds after pressing the rotary encoder?

Dear madires
If I keep pressing the button it stays lit
other wise it turn of

a small press (like to turn it on) with turn on the display as soon as I remove the finguer from the button of the rotary encoder it turns off

I hope I made myself clear enough

Thanks
Belen


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: $20 LCR ESR Transistor checker project (Read 3451857 times)

Share me