$20 LCR ESR Transistor checker project

[Per Hansson]

I have a question about the rotary encoder on my Hiland 644.
It does not work so well with M-firmware, and I found something strange:
On channel B the voltage is 4.97v but on Channel A it is only 460mV.
I checked the pullup resistors R3 & R4 and they are 10K as they should.
And then the PB5 & PB7 resistors R6 & R8 are 1K as they should.
Is this normal behavior or what could be causing this?

In case of the Hiland M664 PB5 and 7 are shared between display and rotary encoder. Both I/O pins are set to output mode at startup, and when waiting for user feedback the pins are temporarily set to input mode to poll the rotary encoder every few ms. What you see can be normal at a specific time (pin setup).

I tested Indman's 8MHz K-firmware build for my Hiland now and the result is interesting:
The encoder works fine with this build, it also did with the "original Chinese" firmware (yes it's an oxymoron I know!)

When no writes occur to the display the voltage is pulled up to ca 4.1v for both channels.
This was 460mV for Channel A and 5v for Channel B with M-firmware.


When writes do occur they are at 5v with both firmwares.
I think the difference is caused by the pullup configuration.
But I am not sure what setting specifically would affect it.
I posted a small exert from Indman's Makefile below, the full is available on his site.
Maybe someone smarter than me can look at this and give me their opinion

Code: [Select]

# With the option LCD_SPI_OPEN_COL the data signals of the SPI interface are not switched to VCC.
# With option LCD_SPI_OPEN_COL the signals are switched to GND only, for high signals the pullup resistors
# of the ATmega are used. For the RESET signal a external pull-up resistor is required, if the
# option PULLUP_DISABLE is set. For the other signals the internal pullup resistors of the ATmega
# are temporary used, even if option PULLUP_DISABLE is set.
#CFLAGS += -DLCD_SPI_OPEN_COL

# If LCD_ST7565 option is used: Set the resitor ratio for the internal
# voltage regulator. Supported value range: 0..7.
# Good values are e.g. 4 or 7. If unsure just have a try.
LCD_ST7565_RESISTOR_RATIO = 4


# The PULLUP_DISABLE option disable the pull-up Resistors of IO-Ports.
# To use this option a external pull-up Resistor (10k to 30k)
# from Pin 13 to VCC must be installed!
CFLAGS += -DPULLUP_DISABLE

# The sleep mode of the ATmega168 or ATmega328 is normally used by the software to save current.
# You can inhibit this with the option INHIBIT_SLEEP_MODE .
#CFLAGS += -DINHIBIT_SLEEP_MODE

Here is my understanding of this:
LCD_SPI_OPEN_COL is not configured, so it means the SPI interface is switched to VCC
PULLUP_DISABLE is configured, the pin should be 26 on the Atmega644 I believe, this has a 27k pullup to VCC.
LCD_ST7565_RESISTOR_RATIO is set to 4, I guess this could also be affecting the drive level?
Corrections for my interpretation of this are more than welcome!

[madires]

I tested Indman's 8MHz K-firmware build for my Hiland now and the result is interesting:
The encoder works fine with this build, it also did with the "original Chinese" firmware (yes it's an oxymoron I know!)

My Hiland M644's rotary encoder works fine with the m-firmware. Configuration issue? If the encoder works intermittent try different values for ENCODER_PULSES and ENCODER_STEPS, in case it's a different encoder type. BTW, the Chinese firmware is a modified k-firmware.

Here is my understanding of this:
LCD_SPI_OPEN_COL is not configured, so it means the SPI interface is switched to VCC
PULLUP_DISABLE is configured, the pin should be 26 on the Atmega644 I believe, this has a 27k pullup to VCC.
LCD_ST7565_RESISTOR_RATIO is set to 4, I guess this could also be affecting the drive level?
Corrections for my interpretation of this are more than welcome!

PULLUP_DISABLE disables the internal I/O pull-up resistors (20-50k) globally. And LCD_ST7565_RESISTOR_RATIO is meant for the ST7565's internal voltage regulator (contrast etc).

[Per Hansson]

My Hiland M644's rotary encoder works fine with the m-firmware. Configuration issue? If the encoder works intermittent try different values for ENCODER_PULSES and ENCODER_STEPS, in case it's a different encoder type. BTW, the Chinese firmware is a modified k-firmware.

Yes I've already tried several different settings for the encoder but it does not really change much.
Here is a picture of moving the encoder only one of the 24 steps / detents it has:

PULLUP_DISABLE disables the internal I/O pull-up resistors (20-50k) globally. And LCD_ST7565_RESISTOR_RATIO is meant for the ST7565's internal voltage regulator (contrast etc).

Yes but how does this compare with the settings in your M-firmware?
I mean can we make similar settings there too or is it not configurable?
Because I think the 460mV signal level could be an issue since it is only on Channel A and that does not happen with K-firmware.

[madires]

Yes but how does this compare with the settings in your M-firmware?
I mean can we make similar settings there too or is it not configurable?

In the m-firmware the ATmega's internal I/O pull-up resistors are disabled anyway (not a configuration option). The ST7565's resistor ratio has no impact on the interfaces's logic levels. And the open collector style switching of SPI lines is not supported.

Because I think the 460mV signal level could be an issue since it is only on Channel A and that does not happen with K-firmware.

As I tried to explain already, that can be normal at a specific time period, e.g. before or after probing the rotary encoder when PB5 and 7 are in output mode and one is set high and the other one low. If the settings are fine then it's most likely a cheap rotary encoder (we've discussed this just a few posts back). The k-firmware is more tolerant of poorly switching encoders, while the m-firmware ignores glitches (nothing happens, intended design). A typical symptom is that the encoder works fine in one direction, but not in the other direction. Or the tester reacts only after turning the encoder several steps/detents. Looking at your scope images it seems that one contact is switching too briefly in comparison to the other one.

[Per Hansson]

Thanks Madires, my hope was that there would be some configuration mistake that causes it, but it seems from your explanation that I have the same in both k and m firmware.
I honestly think this encoder is not so bad, the one on my other meter that I replaced with a genuine Bourns was terrible.
But this one I think is fine, still debating if I should replace it or just live with it, if I do would you like me to send this one to you?
Because this one unlike the other one I think should be handled by the firmware.

[Per Hansson]

I encountered a problem with my Hiland 644 tester now, I have not started doing any hardware mods yet.
I was just making sure everything is ok before I start, and it is not!
The R0 values are all showing as 0.00Ω with Indman's K-firmware as you can see in the attached picture.
It was 0.27 0.26 0.27Ω with the original K-firmware.
If I instead use M-Firmware it reports 0.22Ω during the self adjustment for R0 and that sounds more reasonable!
Has anyone got any ideas?
I notice a compile value in the K-Firmware Makefile below, would it apply during calibration for R0 values also?
Could this be the reason?

Code: [Select]

# The ESR_ZERO value define the zero value of ESR measurement (units = 0.01 Ohm).
CFLAGS += -DESR_ZERO=20


[indman]

Per Hansson,before conducting experiments and drawing any practical conclusions about comparing the results, you need to remember and do just 1 important thing - YOU NEED TO INSTALL A HIGH-QUALITY(NO CHINA) STABILIZER + 5V in the TESTER!
99% of all complaints(problems) and incomprehensible measurement results on this tester are associated with unstable and poorly filtered CPU voltage! Remember ALL this and hang this reminder in front of you on the monitor.

Here is an answer from Karl-Heinz to a similar question that I also asked him about not too long ago:
"The R0 measurement is done with the function GetESR.S. For the ESR measurement of capacitors with low capacity the current pulses used for measurement are short.The newer 1.13k use a shorter puls-length than the 1.12k.
The pulse is shortened for measure capacitors above 20nF instead of above 90nF for
the older version.The timing of the ADC sampling must match to 1 clock cycle for correct mesurement results
of little capacitors because the voltage is rising fast.
But a short current pulse can also make problems, if the VCC voltage is unstable.
You can try to add additional capacitors to make the VCC voltage more stable to
prevent measurement errors for this reason (short current puls)."

[Per Hansson]

Thanks Indman, I found the post where this is mentioned:
https://www.mikrocontroller.net/topic/transistortester-avr?page=single#5644769

But a bit further down this is then stated:

> Der Fehler tritt auch bei größeren Kondensatoren auf - Werte < 0,8 Ohm
> werden als 0.00 Ohm angezeigt - erst darüber sind die Werte mit denen
> der "328er" vergleichbar.

Die Ursache war eine falsche Abfrage in der Funktion GetESR.S speziell für den ATmega644.

https://www.mikrocontroller.net/topic/transistortester-avr?page=single#5775968

So I tested to recompile the latest git version of K-firmware and then the R0 test is fine!
I will now make some tests to replace the silly 100nF capacitors for the 1117M3 regulator because as you say it is not really stable!

[madires]

I honestly think this encoder is not so bad, the one on my other meter that I replaced with a genuine Bourns was terrible.
But this one I think is fine, still debating if I should replace it or just live with it, if I do would you like me to send this one to you?
Because this one unlike the other one I think should be handled by the firmware.

I wouldn't call a rotary encoder working fine when one of the two switching contacts creates pulses half as long as the other. From the software point of view, a commonly used algorithm (simple, taking a shortcut) for reading rotary encoders would be able to read that specific encoder ok-ish, but it has problems with encoders creating lots of switch bouncing. One step/detent could be detected as two or more. Very annoying when you have a dynamic control taking the turning speed into account (as the m-firmware does for some functions). The m-firmware's algorithm takes a different approach which results in ignoring poor switching signals. So bad encoders become more apparent.

[Per Hansson]

I have now replaced the input and output capacitors on my Hiland 644 tester, I started with only C4 (the output capacitor).
This completely fixed the stability problems, before the ESR or Ohm value would "hunt" up and down if I left the tester running.
Now it is stable! It would even randomly corrupt the calibration data and say the meter is uncalibrated, that is was fixed too...
I also changed C10 (the input capacitor) for good measure but noticed no difference.
(That said it could help when the battery gets weaker as the battery internal resistance goes up).

Here is a recap of events:
Meter would show 0Ω for all R0 tests with the Hiland K-Firmware Rev804En(8x12t)8Mhz.zip from Indman's repository:
This was fixed by compiling the latest version, no hardware changes necessary! (See my previous post for explanation).
This also changed the "REF_C" test value from 23 down to 18, all other values had only minimal changes.

Meter would not show a stable reading, and sometimes would hang including corrupting calibration data:
This was fixed by replacing the 100nF output filter capacitor C4 with a 4.7µF ceramic capacitor taken from a PC motherboard.
The capacitor ESR reads 1.1Ω @ 1kHz, 0.4Ω @ 10kHz and 0.33Ω @ 100kHz using my Agilent U1733C.
The pads are ca 2.3mm wide so a 0805 capacitor does fit tightly, but a 0603 would be a better fit.
If also replacing the input capacitor C10 keep in mind it needs to handle the higher battery voltage!

I wouldn't call a rotary encoder working fine when one of the two switching contacts creates pulses half as long as the other.

Well, if you look at the scope shots from the genuine Bourns encoder I installed on my other meter a few weeks ago it is very similar in that regard:
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg4259041/#msg4259041

[Per Hansson]

I made some continued tests: the Hiland 644 tester now matches the "original Chinese" firmware.
But it is still no match for my old venerable GM328R meter!
So I changed C3 to also be a 4.7µF ceramic, this did actually improve the meter further, measurement stability increased.
However the meter still shows invalid ESR values (0.00Ω) for some caps that my old Atmega328 based meter handles fine.
So I thought this is probably due to the integrated calibration cap C8 which also is a regular 100nF ceramic, an obvious issue...
I replaced it with a nice Wima 470nF film capacitor, however that made surprisingly little difference for the calibration!

So I thought maybe it is because of the 8MHz crystal, my other meter has a 20MHz crystal and this affect the SamplingADC function.
So I swapped it for a 16MHz crystal however then the issue with the R0 values being 0.00Ω came back
I have spent allot of time looking at the GetESR.S file in K-Firmware because I think the issue is there.
If you look at the value "FAKTOR_ESR" it is defined to 30250 if the processor type is Atmega644.
Otherwise it will be defined as 550000
Then we get to a if statement if the CPU speed is 16MHz
However here all definitions are commented out!
I'm no expert on C code but doesn't this mean the previous value should still be valid then?
There is a further confusion at the beginning of the file: #if (PROCESSOR_TYP == 640) || (PROCESSOR_TYP == 1280)
Well, 640 doesn't equal 644 so I guess that statement will be false, but then again the statement would not change due to the processor speed...
Can someone that has a bit better coding skills than me take a look at this?
https://github.com/kubi48/TransistorTester-source/blob/master/trunk/GetESR.S

P.S: Are the changelogs for the old SVN repository still available somewhere?


EDIT: I tried a couple edits of GetESR.S but could not get it right.
Then I found this post linked below by Yuriy_K and his attached HEX file in "Hiland_M644.zip" from post #810901 works great!
I'm unable to compile that version though when using his version of GetESR.S with the latest git release so too much has changed I guess
https://vrtp.ru/index.php?showtopic=25020&st=1170#

[indman]

Per Hansson,use m-firmware, it doesn't have problems with GetESR because R0 is determined by another method 

[Per Hansson]

Use m-firmware, it doesn't have problems with GetESR because R0 is determined by another method 

Yes Indman that is what I intend to do, because I want this meter to have all the nice extras of M-firmware.
However I also want to help other people out that want to run K-firmware on it.
It seems to me that this change I mentioned below only applies when the clockspeed is 8MHz, not 16MHz:

> Der Fehler tritt auch bei größeren Kondensatoren auf - Werte < 0,8 Ohm
> werden als 0.00 Ohm angezeigt - erst darüber sind die Werte mit denen
> der "328er" vergleichbar.

Die Ursache war eine falsche Abfrage in der Funktion GetESR.S speziell für den ATmega644.

https://www.mikrocontroller.net/topic/transistortester-avr?page=single#5775968

So I tested to recompile the latest git version of K-firmware and then the R0 test is fine!
I will now make some tests to replace the silly 100nF capacitors for the 1117M3 regulator because as you say it is not really stable!

[Yuriy_K]

However I also want to help other people out that want to run K-firmware on it.
It seems to me that this change I mentioned below only applies when the clockspeed is 8MHz, not 16MHz:

To compare measurements of different capacitances on
ATMega328 - top row,
ATmega644 - middle row,
Hiland M644 - bottom row.
All Ttesters with 16MHz crystal.

[indman]

So that now there are no questions why the ESR measurement for non-electrolytic capacitors differs by 10-100 times on m-firmware compared to k-firmware, I will explain. ESR measurement for this type of capacitors and for m-firmware is equivalent to measuring with a sinusoidal signal at a frequency of 1kHz LCR-bridge, for k-firmware this frequency is approximately equal to 10-20kHz. Also a very important factor that greatly affects these measurements is the quality and batch of the processor used. The Chinese processors that I have had experience with have a huge variation in parameters.

[Felipe Lacerda]

So that now there are no questions why the ESR measurement for non-electrolytic capacitors differs by 10-100 times on m-firmware compared to k-firmware, I will explain. ESR measurement for this type of capacitors and for m-firmware is equivalent to measuring with a sinusoidal signal at a frequency of 1kHz LCR-bridge, for k-firmware this frequency is approximately equal to 10-20kHz. Also a very important factor that greatly affects these measurements is the quality and batch of the processor used. The Chinese processors that I have had experience with have a huge variation in parameters.

Does this justify these measurements with 0805 X5R/X7R?

New parts, I tried to use the shortest lead possible.
All with the same 0.33k ESR.   
10uf displays 11.14uf, on keysight multimeter it displays 9.1uf.

Did I get junk parts? Or is the meter crazy? 

[Per Hansson]

Does this justify these measurements with 0805 X5R/X7R?

No.
What indman explains is that the two different open source firmware have a different way of testing small capacitors:
Only K-firmware have "SamplingADC" and this gives more "expected" results (compared to capacitor datasheets) vs M-firmware.
For example I tested a 4.7µF ceramic capacitor SMD now on my Hiland 644 and it gives these results:
4588nF 0.05Ω 0.3% vloss
Compared with my Agilent U1733C that I posted above in my post #7759:
ESR reads 1.1Ω @ 1kHz, 0.4Ω @ 10kHz and 0.33Ω @ 100kHz using my Agilent U1733C, it reads capacitance as 4.535µF @ 100Hz
So I would say something is wrong with your meter, have you calibrated it by shorting the three test points?
If so please show the results of "show data" in the meters menu.

[Yuriy_K]

For those who want to transfer their Hiland to a 16 MHz crystal. I can’t transfer the source codes, there are too many changes, but I collected the required large font for my changes. Here is the firmware and examples of capacitance measurements from the previous message and others.

P.S. Fixed JFET display.

[Per Hansson]

So I thought maybe it is because of the 8MHz crystal, my other meter has a 20MHz crystal and this affect the SamplingADC function.
So I swapped it for a 16MHz crystal however then the issue with the R0 values being 0.00Ω came back
I have spent allot of time looking at the GetESR.S file in K-Firmware because I think the issue is there.
If you look at the value "FAKTOR_ESR" it is defined to 30250 if the processor type is Atmega644.
Otherwise it will be defined as 550000

I found a repository that had all the old changes from the SVN repository listed.
This change that fixed the problems with the "R0" test values being 0.00Ω at 8MHz is here in SVN 809:
https://github.com/M-Reimer/transistortester/commit/00a2d497d1d8349cb4ce15f59deb7accb49fe412

Then we get to a if statement if the CPU speed is 16MHz
However here all definitions are commented out!
I'm no expert on C code but doesn't this mean the previous value should still be valid then?

As for this I tested it, yes the section with "#if F_CPU == 16000000UL" under the "FAKTOR_ESR" section is redundant, deleting it does not affect the code.
It looks like Karl-Heinz was testing other values for "FAKTOR_ESR" at 16MHz but never commited to them.

There is a further confusion at the beginning of the file: #if (PROCESSOR_TYP == 640) || (PROCESSOR_TYP == 1280)
Well, 640 doesn't equal 644 so I guess that statement will be false, but then again the statement would not change due to the processor speed...
Can someone that has a bit better coding skills than me take a look at this?
https://github.com/kubi48/TransistorTester-source/blob/master/trunk/GetESR.S

P.S: Are the changelogs for the old SVN repository still available somewhere?

The commit that shows this fix is in SVN 808.
It seems it should really be 640 and 1280 and not 644 and 1280 like it was in the previous versions.
Because these two processors are from the same range I guess so this is fine...
https://github.com/M-Reimer/transistortester/commit/6322ea82b5f0f55bf6382b8c65114878a33279ac

EDIT: I tried a couple edits of GetESR.S but could not get it right.
Then I found this post linked below by Yuriy_K and his attached HEX file in "Hiland_M644.zip" from post #810901 works great!
I'm unable to compile that version though when using his version of GetESR.S with the latest git release so too much has changed I guess
https://vrtp.ru/index.php?showtopic=25020&st=1170#

I found a further version by Yuriy_K in his post #865595 file "Forum.zip" that works fine: https://vrtp.ru/index.php?showtopic=25020&st=1320

I have tried to get the same good values as with Yuriy_K's firmware by compiling the latest from GIT and trying different values for "FAKTOR_ESR".
However I am not able to do it: whatever I change "FAKTOR_ESR" to has little effect, and the result is always that some small film caps show 0.00 ESR.
I also realized the "R0" calibration values are not stable in the one I compile, but it is in Yuriy_K's firmware they are ALWAYS 0.30Ω to 0.31Ω!
A further confusion is that Yuriy_K uses FAKTOR_ESR of ca 550000 which is the standard value for all Atmegas, while Karl-Heinz uses 30250 for the Atmega644, very big difference!

Before I realized this I actually added back the 100nF caps at C3 C4 & C10 ontop of my new 4.6µF capacitors, but it had no effect.
I also realized that the boost converter draws around 45mA (consumption rises from ca 35mA to 80mA) when it starts.
What is bad about this is that the boost converter sits on the regulated 5v line, and when you press the button to start the test it briefly activates.
This probably is a very big reason for the problems with the cheap Chinese regulators, this is simply not a good design at all!
If you look in the original 644 design included in Karl-Heinz documentation the boost converter has its own DC>DC regulator fed from the battery.
So it does not affect the stabilized 5v for the processor at all, this is especially bad in the Hiland design where the penny pinchers used 100nF caps when they really should be 10µF!!!
That said I removed R9 to disable the boost converter: this did not seem to have any discernible effect, my own compiled firmware still gives unstable calibration values.
While Yuriy_K's firmware has given consistent results with all these changes implemented!
Please Yuriy_K's: can you (for my own sanity) post what GIT version you used to compile your firmware that I linked before?
Either "Hiland_16_en.zip" from: October 27 2020 or "Hiland_M644.zip" from: March 10 2019?

P.S: Maybe a nice design addition for M-Firmware would be to be able to dedicate one processor pin for starting the boost converter so it only starts when you are in the Zener menu and press the button?
All that would be required is to lift R9 and attach it to one of the Atmega644 free outputs, this would also save allot of battery power since it is a rarely used function that draws allot of current?

[indman]

Did I get junk parts? Or is the meter crazy? 

Per Hansson and Felipe Lacerda,the reason for the false readings is hidden elsewhere
1. The T7 clone shown in the photo is based on the Chinese analogue ATMega328 -LGT8F328P
2. Factory firmware for these and similar clones, T1-T7 is not at all a copy of the author's firmware k-firmware and m-firmware. Many functions and options in the Chinese firmware are removed in order to get a beautiful picture on the screen instead.
And in this particular measurement example, we see that the ESR measurement function was copied by Chinese friends for the LGT8F328P processor unsuccessfully.
3. Quality SMD ceramics have low ESR values, as evidenced by the graph below, as well as a few measurements I made on my DTU-1701 clone.

[Yuriy_K]

Please Yuriy_K's: can you (for my own sanity) post what GIT version you used to compile your firmware that I linked before?

Try the firmware from my previous post. Since then, both Karl-Heinz and I have made many changes to the source code and not only to GetESR. Not all changes in the source texts were indicated by Karl-Heinz, I had to search on my own and make them to my source codes, which differ significantly from the author's ones.

P.S. In my homemade Ttesters, I use a simple switch to turn off the boost converter.

[madires]

P.S: Maybe a nice design addition for M-Firmware would be to be able to dedicate one processor pin for starting the boost converter so it only starts when you are in the Zener menu and press the button?
All that would be required is to lift R9 and attach it to one of the Atmega644 free outputs, this would also save allot of battery power since it is a rarely used function that draws allot of current?

I agree, it would better to switch on the boost converter only when checking Zener diodes. I'll put it on the to-do list. The current design (either switched by the test button or running all the time) stems from the lack of free pins of the ATmega328.

[Feliciano]

Now that indman refreshed the LGT8F328P existence for some T7s (maybe other clones too), I wonder, has anyone ported the OSHW to this "arguably improved" 32KB derivative via SWD? And if so, were some benefits obtained against the traditional ATmega328p?

[indman]

And if so, were some benefits obtained against the traditional ATmega328p?

I think that for now we cannot talk about any advantages of the Chinese version compared to the classic ATMEL.
On the contrary, I think that if we completaly and thoroughly test all the modes of operation of the new tester, we will find many more unpleasant surprises. The same can be said about the new DSO-TC2 hybrid device, in which the Chinese analogue of STM is already installed and the k-firmware code is partially copied to the new platform.

[madires]

Now that indman refreshed the LGT8F328P existence for some T7s (maybe other clones too), I wonder, has anyone ported the OSHW to this "arguably improved" 32KB derivative via SWD? And if so, were some benefits obtained against the traditional ATmega328p?

I haven't worked with that ATmega clone yet. A fourth timer and a 12 bit ADC could be a benefit, but I have no idea how the ADC performs. We also would need to spend some effort on checking critical things which require perfect timing and figure out differences. The flash size limit of 32k is a drawback, and I don't think it would make much sense to invest time in this for the foreseeable future.