$20 LCR ESR Transistor checker project

[XantheFIN]

Thanks. Makes sense as I didn't check that yet. Will go resistance measurement with arduino.

Edit. About the tester:

I downloaded and put software/firmware from here: https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk/mega328_T4_v2_st7565

i trying to calibrate as it keeps nagging about it. It goes in self test mode but i don't get isolate probe message. My point to get that extra menu too but it does not get there as well.

Edit2: It was about my backlight led dying, added another led instead of bridge and works now.

[indman]

Dumidan
for Windows optimal https://drive.google.com/file/d/1DL5--2RUFIncdO8PmW87Bz9DzwPw5ms0/view?usp=sharing

I have updated the instructions for easy and quick installation of WinAVR and compilation of the firmware for my tester. The manual now contains an updated link to the GItHub with the k-firmware and m-firmware distributions. Thanks to de_light for help in editing the description in English! Good luck with your use! 
https://drive.google.com/file/d/1-IJA8uTcsCA_6SYHEuMydjfS2vNgmwdH/view?usp=sharing

[madires]

It seems that mikrocontroller.net is migrating from SVN to git. So the new main repository is https://github.com/Mikrocontroller-net/transistortester which makes downloading much simpler.

[Shannon]

Jumping into this thread
You may be interested in this project, the performance of the LCR meter is awesome

https://www.eevblog.com/forum/testgear/design-a-new-precision-lcr-tweezers/msg3473886/#msg3473886

[madires]

Unfortunately not an OSHW project. Kickstarter planned, price around US$ 100.

[Fuzzy Star]

It seems that mikrocontroller.net is migrating from SVN to git. So the new main repository is https://github.com/Mikrocontroller-net/transistortester which makes downloading much simpler.

I have a self made tester with m328 and ST7108 display (k-firmware). So, I checked the new repository link and saw that there are some updated files in 'transistortester/Software/trunk/' folder. I decided to download the trunk and compile a new firmware. I know there are ready compiled files but I prefer a different font and options. So, I prepared my makefile and executed the make.exe. I got this error:

Code: [Select]

The system cannot find the path specified.
rm -rf ../Obj/mega328_st7108
process_begin: CreateProcess(NULL, rm -rf ../Obj/mega328_st7108, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [../finish.mk:112: deleteobj] Error 2
The 'Obj' folder have 3 different folder for ST7565 display and a 'TransistorTester' folder. So, I created the 'mega328_st7108' folder under 'Obj'. And same error again. I searched this thread and found your answer about modifying finish.mk file:
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3450818/#msg3450818
So, I added "-" before those commands. Then those errors ignored. But got this error:

Code: [Select]

../lcd_hw_4_bit.S:8:0: fatal error: opening dependency file ../Obj/mega328_st7108/dep/lcd_hw_4_bit.o.d: No such file or directory

compilation terminated.
make: *** [../finish.mk:14: ../Obj/mega328_st7108/lcd_hw_4_bit.o] Error 1
Then I copied all the files under 'Obj/TransistorTester/dep' to the 'Obj/mega328_st7108/dep'. And finally it's compiled:

Code: [Select]

Program:   30304 bytes (92.5% Full)
(.text + .data + .bootloader)

Data:        190 bytes (9.3% Full)
(.data + .bss + .noinit)

EEPROM:      841 bytes (82.1% Full)
(.eeprom)
Did I get the correct firmware?

ps: I find the k-firmware modifications confusing, there is no version number change or something like that, right? Is there a way to determine the current state of the firmware?

Thanks for reading.

[madires]

When the firmware compiles without errors it should be fine. The version in the 'trunk' directory is the current k-firmware under development, similar to a beta version. With git the changes are referenced by the commit IDs. The finished versions are in 'tags'.

[b0hoon]

Hi,

I don't know if it's right thread, but anyway to the point... I bought lately GM328A tester from aliexpress, for something like ten bucks with shipping. It came of course with the old version 1.12k of firmware, so i wanted to upgrade it with 1.42m. It had a strange lcd module, with additional unknown chip between buffer and controller, white silicone around the controller, module was mounted on pins on the left side (not on screws). On picture "LCD modules.jpg", on left side is my lcd module from the DIY GM328 red kit.

It turned out that after flashing atmega, this lcd just doesn't work, no matter what, but both lcd modules, this one and one from GM328 "red kit" worked on version 1.13k. I spent almost a week to get this thing working, and here is what i've finally done:

1) no image, garbage on the screen -  generally this module behaves like ST7735, but needs CS switching between sending bytes  in LCD_Data2 (High, Low), like it is in k-versions, after adding it both modules work on 1.42m.

2) this lcd module works in BGR mode, but doesn't react on command 0x36 (and most of the other control commands), so colors have to be inverted by the software, i've added inverted BGR colors to colors.h and defined LCD_BGR_SOFTWARE.

I attach changed files with fixes for the next version.

Thank you for developing this soft!

[indman]

Hi,
 It had a strange lcd module, with additional unknown chip between buffer and controller, white silicone around the controller, module was mounted on pins on the left side (not on screws). On picture "LCD modules.jpg", on left side is my lcd module from the DIY GM328 red kit.

This unknown chip is most likely a 74HC4053.

[madires]

4050 (hex high-to-low level shifter). But it's followed by another IC, which could be also a level shifter. Quite strange! The display controller isn't an ST7735 because the MADCTL command to change the color order should even work when EXTC is disabled (only system commands). And the need to /CS each byte is another strong indication. So far I haven't seen any graphics display controller which requires that. It would be great if we could figure out the controller, because I'd rather write a driver for that controller than bodging the ST7735 driver to work with the unknown controller.

[b0hoon]

By the unknown chip i meant U3.

Markings:
- on the edge: C177-237-B-P0-J-E-1 1001081122c
- underneath: CMC2P0437 V100125-B27

Google gave me nothing, unless i suck in google searching, worth to check by someone else.

During the tests i wrote a primitive lcd tester, based on the PWM menu, basically it was writing a cmd to the lcd and then one data byte. I've tested cmds from 0x00 to 0x80, with 0xff and then with 0x00 and was watching if something is going on with the display.

- 0x00 to 0x27 - no visual reaction
- 0x28 - display off - correct
- 0x29 - display on - correct
- 0x2a CMD_COL_ADDR_SET, 0x2b CMD_ROW_ADDR_SET, 0x2c CMD_MEM_WRITE - assume it worked, because it was used to display for me values, which i set
- the rest - no visual reaction.

What else can i do... Maybe i am wrong about the controller. I have a backup of the original firmware 1.12k of the tester, if there is a simple way to check what controller was compiled, without using IDA or something and analyzing the code...

[madires]

The best option would be to program the original firmware and use a logic analyzer to capture the LCD's initialization commands after power-on.

[Fuzzy Star]

When the firmware compiles without errors it should be fine. The version in the 'trunk' directory is the current k-firmware under development, similar to a beta version. With git the changes are referenced by the commit IDs. The finished versions are in 'tags'.

I worked on it again and realized that it doesn't need any file under 'Obj/mega328_st7108/dep' folder. Creating the empty 'dep' folder under 'Obj/mega328_st7108/' was enough. When I compiled again it created identical files.

Thank you for all madires! I'm planing to build another tester (with m644&ST7735) to program it with m-firmware. I'll post about it when I try.

[b0hoon]

The best option would be to program the original firmware and use a logic analyzer to capture the LCD's initialization commands after power-on.

I've chosen to disassemble file. It wasn't so hard after all. LCD initialization is for ST7735, so i can confirm that i picked the correct driver. That's all i can do for now. And thank you again.

[madires]

Thanks! However, I think we missed something. The original firmware sets MADCTL:

Code: [Select]

ldi     r24, 0x36       ; MEM ADDRESS CONTROL
rcall   lcd_command
ldi     r22, 0x6C
ldi     r24, 1
rcall   lcd_write_data  ; 6C = flipx + rotate + bgr, modded by someone, originally is 3C or 1C

Since the LCD module is actually 128x160 the output needs to be rotated for 160x128. After you've added the additional /CS cycle to LCD_Data2(), have you noticed the orientation of the display output? If it was correct, then MADCTL should work. Otherwise it would be the default orientation (upright, like an old mobile phone). Have you tried to enable LCD_BGR for the ST7735 driver to reverse the color order?

[Chaoticoz]

Hey, this is my first post on the eevblog forums

I am sorry for asking, there is so much information and it is really overwhelming for me, surely this has been answered somewhere..

I have this transistor tester

I flashed the precompiled 1.13k firmware from https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk/mega328_st7565_kit

Now i saw that there is another firmware version 1.42m, which seems more recent? The problem is i am lost trying to compile it for my tester as i really don't know where to start.

So my questions are:

-Is the 1.42m version better than the 1.13k?
-Do precompiled binaries of it exist? If not, how do i get started to compiling them?

Thank you guys!

[madires]

-Is the 1.42m version better than the 1.13k?

Not better, but it comes with several additional functions. It's explained in the README file.

-Do precompiled binaries of it exist? If not, how do i get started to compiling them?

I don't provide precompiled firmwares because I don't know which features someone likes to have. It's up to you to choose what you need. A few posts ago indman posted a link to a starter package for WinAVR which might be a good starting point.

PS: You could try the settings for the GM328 and also enable the rotary encoder (presumably PD3 and 1).

[b0hoon]

Since the LCD module is actually 128x160 the output needs to be rotated for 160x128. After you've added the additional /CS cycle to LCD_Data2(), have you noticed the orientation of the display output? If it was correct, then MADCTL should work. Otherwise it would be the default orientation (upright, like an old mobile phone). Have you tried to enable LCD_BGR for the ST7735 driver to reverse the color order?

Let me show you, what i'm talking about.

1.12k OF

MEMADDRCTRL = 0x6C (flipx + hw_rotation + hw_bgr)

- both lcds work correct
- GM328A module - works correct, cause it behaves like 160x128 natively, both the lcd and the software works in bgr mode, so colors are ok too
- GM328 module - works correct, cause it reacts on hw flags (flipx, rotation and bgr), both the lcd and the software works in bgr mode, so colors are ok

1.13k compiled by me

- LCD_SCREEN_ROTATE defined, so command is MEMADDRCTRL = 0x3C (hw_rotation + hw_bgr),

- GM328A module - works correct, cause it doesn't react on hw_rotation flag, colors are ok
- GM328 module - x-flipped, cause there is no hw_flipx flag, colors are ok

1.42m

- added CS bitbanging between bytes
- defined as 128x160
- without any lcd flags like rotate, flip
- lcd_bgr defined, but not my soft bgr

- GM328A module - the display area is clipped to 128px, cause there is no rotation flag, but orientation is ok, colors are bad, cause it works in bgr mode, soft is in rgb
- GM328 module - lack of hw flags except bgr, so bad orientation, colors are bad, because it reacts on hw_bgr flag

and now without lcd_bgr flag

- GM328A module - display area and orientation is like before, colors are bad, cause it works in bgr anyway.
- GM328 module - bad orientation, colors are ok

As i said before, GM328A module doesn't react at all on command 0x36.

[madires]

I see! Thanks! So the display from the GM328A is 160x128 which is different from an ST7735's 128x160. Another detail I've spotted are the flags for MADCTL. 1.13k sets 0x3C (in m-firmware terms:  FLAG_HREFRESH_REV, FLAG_COLOR_BGR, FLAG_VREFRESH_REV and FLAG_XY_REV) while 1.42m doesn't set  FLAG_HREFRESH_REV and FLAG_VREFRESH_REV. I have the sneaky suspicion that the unknown IC on the GM328A's LCD module might be an MCU translating ST7735 commands for some other LCD controller. Using two level shifters in series doesn't make any sense. Maybe the other LCD controller plus MCU are cheaper than an ST7735?

[Obelix2007]

... 1.12k OF

Hallo bOhoon,

just for fun, i flashed your "Original Firmwarefiles" to my "GeekTeches GM328A" with a LCD 128X160p SPI Color TFT Module and ST7735 Controller:

It runs.

Start the calibration procedere works fine and end with hint for FW 1.12. The tester works fine also with the different components in the normal range.

But the start of the function-menu shows four entrys more then the "Orginal k1.12 version":



   1.) The function >DS18B20 (1-Wire Digital Thermometer Sensor) works fine
   2.) The function >IR_Decoder fails
   3.) The function >IR_Encoder fails
   4.) The function >DHT11 fails

This additional functions are a part of m1.38 or higher, is it now a new SW-mix from the Chinese clones?

Regards
Horst

[b0hoon]

I have the sneaky feeling that the unknown IC on the GM328A's LCD module might be an MCU translating ST7735 commands for some other LCD controller.

Exactly! U3 isn't another level shifter, probably it is some kind of translator.

Maybe the other LCD controller plus MCU are cheaper than an ST7735?

Well, maybe... But it's one of the most ridiculous things i ever seen

This additional functions are a part of m1.38 or higher, is it now a new SW-mix from the Chinese clones?

I don't really know, what to say about it. I have no idea.

[Chaoticoz]

Thanks for your answer! Sadly i just killed it somehow by running it of my hacked together power supply. Set to 9V and checked with my DMM before connecting, it worked for a minute, now it's dead. Doesn't respond at all anymore

[b0hoon]

One more thing.

Now as i wondering about this cheapish thing on my desk, question just from pure curiosity, why LCD_BGR flag is even implemented? Is this used in some cases at all? If the software works in RGB, woudn't be better to have LCD_RGB flag and implement it by the software, in some similar way i did it?

Edit:

Nah... My logic is broken now, woudn't be better to still have flag LCD_BGR, but implemented by the software?

[madires]

just for fun, i flashed your "Original Firmwarefiles" to my "GeekTeches GM328A" with a LCD 128X160p SPI Color TFT Module and ST7735 Controller:

It runs.

The trick of the clone's firmware is to use the MADCTL command to set the right orientation and BGR color order while using BGR color codes. Since ST7735 displays are usually wired for RGB (there's also a pin to set the color order), reversing the color order by command and using BGR color codes negates the color reversal. So a genuine ST7735 display will output everything correctly. The special display ignores the MADCTL command is, but its defaults are 160x128 and BGR color order. Therefore sending BGR color codes results in a correct output.

   1.) The function >DS18B20 (1-Wire Digital Thermometer Sensor) works fine
   2.) The function >IR_Decoder fails
   3.) The function >IR_Encoder fails
   4.) The function >DHT11 fails

This additional functions are a part of m1.38 or higher, is it now a new SW-mix from the Chinese clones?

IIRC, some modded firmware was the first to support DHT11. A little bit later I added DHT11/22 to the m-firmware after a few users asked about supporting that sensor family. I'm not sure about the DS18B20, but the IR functions were introduced by the m-firmware.

[madires]

Now as i wondering about this cheapish thing on my desk, question just from pure curiosity, why LCD_BGR flag is even implemented? Is this used in some cases at all? If the software works in RGB, woudn't be better to have LCD_RGB flag and implement it by the software, in some similar way i did it?

Edit:

Nah... My logic is broken now, woudn't be better to still have flag LCD_BGR, but implemented by the software?

Most displays are wired for RGB, but a few are BGR. So far I came across only ILI9481, ILI9486 and ILI9488 based displays wired for BGR. Since they all support reversing the color order via command it's simpler to make use of that instead of maintaining also a list of BGR color codes.

Edit: Also ILI9163.