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/00a2d497d1d8349cb4ce15f59deb7accb49fe412Then 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/6322ea82b5f0f55bf6382b8c65114878a33279acEDIT: 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=1320I 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?