$20 LCR ESR Transistor checker project

[madires]

No, the self-test simply runs each test five times. I'm interested in the values of T1, T2, T3, T5 and T6.

[rogerdammit]

No, the self-test simply runs each test five times. I'm interested in the values of T1, T2, T3, T5 and T6.

Ah, got it. Here are the values I get:


T1: 1093 mV
T2: 13 18 23
T3: -44 -88 -49
T4: (none shown)
T5: 0 0 0
T6: 4995 4995 4996

[Feliciano]

I think 50uF is too much for nothing connected. Please double check the cap.c you're using for the make is dated around dec 2023.

You could also check with older m-firmware, or k-firmware, to confirm/discard whether there's a hardware issue (the easier to fix: white solder residues).

[Feliciano]

In the meantime I found something curious: it looks the second number and pin of the 1.51m results text are shiftted 1bit upward. Is this intentional, or something that requires checking?

[indman]

Ah, got it. Here are the values I get:
T2: 13 18 23
T3: -44 -88 -49

These results are poor, especially in the T3 test. The results in tests T2-T3 should be close to 0 and not differ from each other by more than 5 units. Check the values ​​of the measuring resistors 680 Ohm and 470 kOhm.
You can compare the results of your tests with similar tests of other participants on page 369.
You also need to remove all the conductors that you connected for the ICSP interface and repeat selftest!

[madires]

In the meantime I found something curious: it looks the second number and pin of the 1.51m results text are shiftted 1bit upward. Is this intentional, or something that requires checking?

No, could be some display glitch.

[Yuriy_K]

In the meantime I found something curious: it looks the second number and pin of the 1.51m results text are shiftted 1bit upward. Is this intentional, or something that requires checking?

No, could be some display glitch.

This is the principle of constructing a color pixel matrix. Blue is on top, Green is in the middle, Red is at the bottom. The Blue image is raised 1/3 of a pixel relative to the Green, and the Red is 2/3 lower than the Blue. It's almost a line down... Look at the photo.

[Feliciano]

That would explain it, but in my case, the shift looks like exactly 1 pixel, and only happens on that particular screen.

Anyways I will flash another color set to check.

[indman]

Feliciano Is this 1 pixel shift visible when you use your 8x16_alt_hf font?
Will there be the same effect if you use a different font?

[Feliciano]

Seems Yuriy_k observation about the RGB construction is the answer, but in my display is more noticeable than others (specially with a relatively small font). You can notice "the ladder" on the color line when using a terminals sequence R-G-B with the original 8x16_hf font. (And in fact that also explains the ghosting on the purple of my previous images with my custom font).

Thanks, guys.

[Kim Christensen]

Yea, my TC1 screen definitely exhibits this same color shift as Feliciano's. I guess we can't really complain since the tester was less than $25 when I bought it.

On another note, I did change my firmware so that it upscales capacitance, resistance and zener readings. No more 9700nF capacitors and 6800mV zeners for me. 

[hapless]

This height issue should go away if you rotate your display 90 degrees in firmware... I wonder if this means that the little screens were manufactured to be used as vertical ones.

[Feliciano]

I think so. Since my Trinitron days, I always have thought on RGB as an horizontal array. A case like we're discussing would have a little horizontal misalignment, less noticeable than a vertical one. Anyways, it is what it is, and I also think for the price tag of this new TC1, we can't complain much. But know we know it's there, I guess others will start to notice it too everywhere

[indman]

But know we know it's there, I guess others will start to notice it too everywhere

You only notice this shift when the colors characters are close to each other.
Don't have too many different colors on one screen or place them far apart from each other and you won't have this problem.
In general, I am against the display of more than 2-3 color shades at the same time. This strains the eyes and leads to rapid fatigue if prolonged visual work is required.

[Feliciano]

Yeah, and the color fidelity of these display (at least the FNIRSI) is not so high either.

Besides your recommendation, I would add the color sequence and palette also plays a part. In this case, RGB is not as noticeable as RBG or GRB, and additionally the violet (if we want to match what printed on the case) tends to look blurry because in reality it's R+B.

This strains the eyes and leads to rapid fatigue if prolonged visual work is required.

Which makes me wonder: hasn't somebody considered a 20 or 24-pixel-high font? (I'd prefer that over 26, considering the memory requirements).

[indman]

Which makes me wonder: hasn't somebody considered a 20 or 24-pixel-high font? (I'd prefer that over 26, considering the memory requirements).

We already have 16x26 font, nothing prevents you from trying it. But in this case you will have to forget about the compact placement of all the information about the parts. You will have to choose what to show on the display 160x128 and what to hide.

[Feliciano]

I was thinking on something around 10x20 to not sacrify much on a 160x128 screen, but maybe to opt-out to several of the features for that woudn't be appealing to many of the 32KB-units users.

[madires]

A 10x20 font (horizontally aligned) for the ST7735 would be 8 bytes * 110 chars = 880 bytes larger than the default 10x16 font.

[indman]

madires, and if there is any magic method or trick to use several fonts of different heights in the firmware at the same time?

[madires]

No. It would require an additional abstraction layer and increase the firmware size dramatically. RAM could also become an issue.

[Gengis]

Hello to everyone  , I'm searching for some help with my tester...

I have what I think is a "standard" GM328 AY-AT chinese clone kit (writngs on the pcb: K103603BS 2578AY-AT) with 160x128 color display, it came with 1.12 k firmware and appears to work correctly. I want to modify the hardware to improve the accuracy as explained here: https://github.com/blurpy/transistor-tester (this is why I searched exactly this model) but before to order the parts I wanted to be sure I can upgrade the firmware and there started my problem:

I downloaded the current 1.51 m firmware and configured the makefile, config.h and config_328.h according to the included Clones file. Compilation gives no errors and I write the firmware to a spare ATMEGA328P microcontroller.

With the new firmware the tester turns on and the screen gets cleared correctly but it stops there, the display remains black, nothing appears on it (the backlight is of course on).
I can say the display is cleared correctly because if I change the display size or rotation in config_328.h I can make it to initialize partially while the remainder of the screen shows random color pixels.

When I press the rotary controller, the led responds by turning momentairly off, but I tried to connect my multimeter to the test leads and playing around (also if without seeing) with the rotary encoder, and do not see any voltage activity, so I think it's not just a problem of display/color settings, it seems to me the tester is stuck at some point of the initialization and does not respond.

I also tried to write the "mega328_color_kit.hex" prebuilt firmware available here: https://github.com/kubi48/TransistorTester-source/tree/master/trunk/mega328_color_kit but it displays a blanc (white) screen and nothing more. I tried also the "OrigChina.hex" in the same folder but also that displays the blanc screen.

Also searching for "black screen/display" in this thread did not produce useful answers and this looks strange to me because my model seems pretty common and documented. Anyone has suggestions?

[madires]

For 1.51m please also download cap.c-1.51m.tgz (replacement for buggy cap.c). Have you also programmed the EEPROM with the .eep file?

[Feliciano]

I would check again the pinouts of the MCU against the LCD and then to the config file. Some clone makers make modifications to the clone they base their design on.

[Gengis]

For 1.51m please also download cap.c-1.51m.tgz (replacement for buggy cap.c). Have you also programmed the EEPROM with the .eep file?

I will try the replacement file, and no, I have not used the .eep file at all, I did not read anything about it until now . I searched in the pdf manual and see I have to load also that file...

I would check again the pinouts of the MCU against the LCD and then to the config file. Some clone makers make modifications to the clone they base their design on.

I also was worried about the presence of some difference in my particular clone, but the fact that I am able to selectivey initialize parts of the display seems to me a sign that the communication between MCU and LCD is working well...

Thank you very much, I'll do the homework and come back with the results 

[Feliciano]

Has somebody succeded on remaping some ports of a damaged MCU?

Background: An unprotected m328p damaged by a charged capacitor became very slow, then detects a 4V Cell, then enters SeltTest but doesn't finish. I measure low resistance from PC0 to GND, all the ports shows a few mV, except for PB0 which shows around 140mV (with PC0 disconnected).

For this particular clone PC3 is free, so maybe I could rewire PC0 to it. But if PB0 is damaged too, I think there's no hope. Anyways I kindly ask about your experience on the matter before discarding this one.