Forum: Projekte & Code Transistortester AVR

name schrieb:
> bei meinem Hiland M644 scheint ein anderer Drehgeber verbaut? Ich mußte
> die Zuordnung der Pins A,B in der 1.41m vertauschen.

Passt schon. ;) Aus dem CHANGES.de für 1.40m:

Die Erkennung der Drehrichtung in ReadEncoder() war umgedreht. Auf 
korrekte Richtung geändert und Einstellungen in config_<MCU>.h und 
Clones aktualisiert.

Der Selbsttest misst primär die Testpins, um mögliche Fehler oder 
Probleme aufzuzeigen. Er bewertet nicht die Werte nach gut oder 
schlecht. Daher ist er immer erfolgreich, außer er wird am Anfang 
abgebrochen. Nun zum Selbstabgleich. Könntest Du bitte die Werte, die am 
Ende vom Selbstabgleich angezeigt werden, posten?

Der Widerstandsoffset R0 für die Testpinpaare ist recht hoch. 
Kontaktprobleme? Hast Du vor dem Selbstabgleich einen Folienkondensator 
(100nF-2µF) dreimal gemessen?

Liegt beim Selbstabgleich ein Wert deutlich neben den anderen? Bei jedem 
Parameter wird fünfmal gemessen und angezeigt.

name schrieb:
> A1 Vref AComp
>  0mV 0mV / 5 mal

Ah, Du hast den festen Abgleichkondensator aktiviert. Dann brauchst Du 
vorher keinen Folienkondensator dreimal messen. Allerdings läuft beim 
festen Abgleichkondensator etwas schief. Dass die Offsets Null sind, 
wäre sehr ungewöhnlich. Vielleicht passen die Einstellungen zum 
Abgleichkondensator in config_644.h nicht. Ansonsten könntest Du auch 
HW_ADJUST_CAP deaktivieren.

... manchmal ist es hilfreich, den Wert des Abgleichkondensators auf > 
100 nF, z.B. 220 nF (Folie) zu ersetzen. Bei meinen beiden TC1/T7 und 
auch dem Hiland 644 lagen die verbauten  100 nF alle deutlich unter dem 
Sollwert.

Gruß Horst

name schrieb:
> #define ADJUST_RH        PC5       /* Rh (470k) for fixed cap */
>
> wo auf der Platine sollte denn dieser Abgleichkondensator sein? Oder
> wonach könnte ich suchen?

... Rh -> R23 ADJUST_CAP -> C8

Ändere
#define ADJUST_RH        PC5       /* Rh (470k) for fixed cap */
auf
#define ADJUST_RH        PC6       /* Rh (470k) for fixed cap */

Gruß Horst

... der Teil der Clones-Datei, welche sich mit der Anpassung des 
Hiland644 beschäftigt, ist seit der CT-m-1.36 unverändert.

Gruß Horst

Danke! Werde es mir anschauen.

Hi,
in der Revision 857 werden nur Hieroglyphen angezeigt, wenn die Sprache 
auf Deutsch eingestellt ist, English funktioniert.
In der vorherigen Revision geht auch Deutsch.
Hardware ist Hiland M644.

Uwe

Uwe S. schrieb:
> ist Hiland M644

... davon ist nicht nur der Hiland betroffen und auch nicht nur DEUTSCH, 
auch andere Display-Versionen an versch. Tester-Nachbauten haben 
Anzeige-Probleme bei unterschiedlichen Font-Abmessungen. Beispielsweise 
der kleinste Font bringt bei meinem Compiler jedesmal Fehlermeldungen, 
die dann zum Abbruch des Compilierens führen.

Scheint bei der REV 857 (Reorganisation of Fonts) eventuell was "schief 
gelaufen" zu sein?

Gruß Horst

Horst O. schrieb:
> Scheint bei der REV 857 (Reorganisation of Fonts) eventuell was "schief
> gelaufen" zu sein?

Ja, da ist etwas schiefgelaufen. Einerseits sollte beim kyrillischen 
Font etwas Platz eingespart werden und außerdem sollten die 
Sonderzeichen von einigen Sprachen unterstützt werden. Es sollte jetzt 
schon besser funktionieren. Die Sonderzeichen werden für die 
Grafik-Displays noch nicht bei allen Fonts unterstützt. Wenn noch etwas 
auffällt, bitte melden.

Die Reihenfolge der Menü-Unterpunkte kann jetzt leichter geändert 
werden. Es gibt zwei Beispiele (function_sequence1.h und 
function_sequence2.h), die am Ende der autoconf.h Datei ausgewählt 
werden können. Außerdem ist es jetzt leichter, Menüpunkte wegzulassen.

Hallo Karl-Heinz,

... hier mal die Zusammenfassung des Font-Tests Rev. 857:

# If option WITH_LCD_ST7565 is present one of the following fonts should 
be
# choosen. With a font width below 8 more than 16 characters can be 
shown in one display line.
#                           Engl    Germ
#CFLAGS += -DFONT_5X8       Comp_Crash!  Comp_Crash!
#CFLAGS += -DFONT_6X8       OK!    OK!
#CFLAGS += -DFONT_8X8       OK!    OK!
#CFLAGS += -DFONT_7X12      OK!    Font ist richtig, zeigt aber "MÜLL"
#CFLAGS += -DFONT_8X12thin  OK!    Font ist richtig, zeigt aber "MÜLL"
#CFLAGS += -DFONT_8X14      OK!    Font ist richtig, zeigt aber "MÜLL"
#CFLAGS += -DFONT_8X15      OK!    Font ist richtig, zeigt aber "MÜLL"
#CFLAGS += -DFONT_8X16      OK!    Font ist richtig, zeigt aber "MÜLL"
#CFLAGS += -DFONT_8X16thin  OK!    OK!

Karl-Heinz K. schrieb:
> Die Reihenfolge der Menü-Unterpunkte kann jetzt leichter geändert
> werden. Es gibt zwei Beispiele (function_sequence1.h und
> function_sequence2.h), die am Ende der autoconf.h Datei ausgewählt
> werden können. Außerdem ist es jetzt leichter, Menüpunkte wegzulassen.

... in der autoconf.h kann man weder die function_sequence1.h noch die 
function_sequence2.h

auswählen und die Dateien sind auch nicht im "trunk" Vezeichnis 
vorhanden?

Gruß Horst

Horst O. schrieb:
> ... in der autoconf.h kann man weder die function_sequence1.h noch die
> function_sequence2.h
>
> auswählen und die Dateien sind auch nicht im "trunk" Vezeichnis
> vorhanden?

Die Dateien sollten aber ab SVN-Version 858 im trunk Verzeichnis 
vorhanden sein.

Karl-Heinz K. schrieb:
> Die Dateien sollten aber ab SVN-Version 858 im trunk Verzeichnis
> vorhanden sein.

... hatte direkt nach Deinem Beitrag um 12.50 Uhr nach neuen Rev. 
geschaut, aber keine gefunden.

Später dann waren 858 und 859 verfügbar und das Font-Problem gelöst!

Vielen Dank,

Gruß Horst

hamburger schrieb:
> hamburger schrieb:
>> Ausserdem moechte ich die Darstellung im Modus PWM-Output soweit
>> ergaenzen, dass neben der %-Angabe auch die Laenge des High-Anteils in
>> us steht.
>
> die Zeiten fuer
> - 1 Cycle,
> - den High-Anteil
> stehen dann in der neuen Zeile 4

Habe die Anzeige der Pulslänge als Option in beide PWM-Generatoren 
eingebaut, wobei die Pulslänge hinter dem Tastverhältnis steht und auf 
der jeweiligen Zeitauflösung des Timers basiert.

Wenn Du mir eine Email schickst, kann ich Dir gerne eine Beta-Version 
zukommen lassen.

!! Achtung SVN ist nich mehr benutzt !! aktuele Stand nur auf 
https://github.com/Mikrocontroller-net/transistortester !!

MisterGNZ schrieb:
> Hi all, I have a SSM85T03h from the datasheet it says (rds on 6mΩ), but
> in my 112k version transistortester, mida 0.4Ω, how is it possible, such
> a difference?

Hi MisterGNZ,

This difference comes mostly from the fact that, according to the 
datasheet, Rdson is measured with a gate voltage of 10 V at a drain 
current of 45 A (!). Clearly, the transistor tester can't handle such 
values, because voltages from the test pins are limited to 5 V and 
currents to a few mA. On top of that, the resistance of the elements of 
your measuring circuit, like test leads, contacts and so on, will almost 
certainly be already well over 6 mΩ. Measuring a short piece of wire 
with my tester gives me 20 mΩ.

By the way, have you calibrated your tester?

Greetings, derri.

45 69 6e 20 42 6c 69 63 6b 20 69 6e 20 64 69 65 20 4b 6f 6e 66 69 67 20 
44 61 74 65 69 20 6f 64 65 72 20 64 69 65 20 44 6f 6b 75 20 64 fc 72 66 
74 65 20 68 65 6c 66 65 6e 2e 2e 2e 3f

Klaus.

Посмотрите файл конфигурации или документацию, чтобы помочь ...?

Ivan schrieb:
> Ivan schrieb:
>> Hallo liebe Entwickler Transistor Tester!!!
>> Bitte sagen Sie mir, ob die neue Firmware für das Display ST7920???

Hallo Ivan,

sowohl K-Software als auch M-Software unterstützen Dein Display 
ST7920!!!

the K-Software and the M-Software too are supported Your Display 
ST7920!!!

Gruß Horst

Horst O. schrieb:
> too are supported Your

soll das english sein?!

Apollo M. schrieb:
> soll das english sein?!

... wenn Du sonst keine Frage hast, nein, es ist natürlich russisch.

Gruß Horst

Hihi schrieb:
> Ist es eigentlich egal, wie man Elkos (Polung) in die Messkontakte
> steckt?

Ja, das ist egal! Bei den Tests hat sich keine Differenz der 
Meßergebnisse ergeben. Für die eigentliche Messung wird der Kondensator 
nur bis max 1.1V geladen. Bei großen Kapazitäten ist die Meßspannung 
noch deutlich geringer. Die Polarität scheint erst bei höheren 
Spannungen und längerer Betriebszeit eine Rolle zu spielen.

MisterGNZ schrieb:
> Hi all, I have T41080 TRIAC 800V 4A - DPAK, but my transistor tester,
> tells me it's a scr, does anyone know why ?.

Probably the testing current of the tester is too low for detecting the
TRIAC. This tester can only detect low power TRIACS doe to the low 
measurement current of about 6mA.

MisterGNZ schrieb:
> Hi Karl-Heinz K., thanks for the answer, now everything is clear to me,
> what do you think about my atmega328p fuses: low E2, high D9, Ext FC?

Your fuse settings depend on your hardware. My settings for the standard 
schematic and a 16 MHz crystal are as follows: low:F7, high:DF, ext:F9.

Mind that with low:E2 you set the clock source to the internal RC 
oscillator at 8 Mhz. This is not suitable for the SamplingADC method 
used to measure small capacitors.

Please see also https://www.engbedded.com/fusecalc for details.

On the other side, if you set the clock source to an external source or 
crystal, you will not be able to program the chip afterwards in ISP mode 
without a clock source applied, but only in-circuit with a crystal 
connected.

Greetings, derri

you have a newer SMD version from GM328A+

look at your quartz whether 8 or 16Mhz version!

https://yadi.sk/d/yW8xa5NJgUo5z/GM328(A%2B)

https://yadi.sk/d/yW8xa5NJgUo5z

MisterGNZ schrieb:
> example 100nf gives me 200nf, any advice
> ?.

You can not change the quartz without recompiling the software.
There is no way for the software to find out the operating frequency.
You must set the OP_MHZ option in the Makefile correctly and recompile 
the source.

ist darüber irgendwo irgend etwas dokumentiert ?

Antwort mit Beta ist am 29.1. raus gegangen. SPAM-Folder?

R. H. schrieb:
> ist darüber irgendwo irgend etwas dokumentiert ?
Hallo snapper,

... habe mal im Anhang einen Auszug aus der "CloneTester"-Übersicht 
hochgeladen, könnte ev. zu Deinem Tester passen? Es existieren leider 
untersch. Versionen.

Viel Erfolg, Gruß Horst

Horst O. schrieb:
> ... habe mal im Anhang einen Auszug aus der "CloneTester"-Übersicht
> hochgeladen, könnte ev. zu Deinem Tester passen? Es existieren leider
> untersch. Versionen.
>
> Viel Erfolg, Gruß Horst

... oh, mein Fehler, war eigentlich für Hajo Piltz bestimmt.

Gruß Horst

Horst O. schrieb:
> ... oh, mein Fehler, war eigentlich für Hajo Piltz bestimmt.

war eh überflüssig, das gleiche hatte ich schon am 13.3. gepostet!

weis denn hier niemand etwas über die Verwendung von TVS Dioden als 
Schutz der Messports ?

R. H. schrieb:
> weis denn hier niemand etwas über die Verwendung von TVS Dioden als
> Schutz der Messports ?

Hallo R. H.

... durch Lesen der Dokumentation zum Tester (von Karl-Heinz und Markus) 
wissen die meisten Anwender dieses Gerätes, es gibt keinen echten Schutz 
der Messeingänge gegen Überspannung. Daher auch immer wieder der 
Hinweis: vor Messung von Kondensatoren diese zuerst Entladen!

Doku Karl-Heinz --> Kap. 2.2.1
https://github.com/Mikrocontroller-net/transistortester

Gruß Horst

Guten Morgen allerseits !!
Dies ist mein erster Beitrag, daher begrüße ich alle herzlich.
So ist es heute, wenn Sie im Internet nach einer Lösung suchen, wenn es 
ein Problem gibt.
Ich habe einen Komponententester aus China gekauft und alles war in 
Ordnung. Aber als ich den Kondensator gemessen habe, ist der Prozessor 
kaputt gegangen und jetzt kann ich die Software nicht mehr an meine 
Version anpassen.
Sie sind sehr nett, bitte helfen Sie mir, die Version anzupassen.
Die Version verfügt über atmega 328p, tl431, ams1117-5V, 
Frequenzgenerator, Encoder und das Display ist monochrom LCM 12864 v1.30
Ich habe auch ein Programm aus dem Internet, aber es zeigt die Werte 
geteilt durch 2.
Ich verwende TL866II Plus oder Wellon VP 988 für die 
Atmega-Programmierung.
Ich bitte um ein gutes Programm für atmega 328p
Vielen Dank

Tomek L. schrieb:
> Die Version verfügt über atmega 328p, tl431, ams1117-5V,
> Frequenzgenerator, Encoder und das Display ist monochrom LCM 12864 v1.30
> Ich habe auch ein Programm aus dem Internet, aber es zeigt die Werte
> geteilt durch 2.
> Ich verwende TL866II Plus oder Wellon VP 988 für die
> Atmega-Programmierung.
> Ich bitte um ein gutes Programm für atmega 328p

Hallo Tomek,

Es braucht noch ein paar weitere Informationen, um das Modell Deines 
Testers genauer zu bestimmen. Offenbar handelt es sich um eine Variante 
des GM328. Das lese ich in dem ZIP-File.

Ich gehe davon aus, dass Du das File "ATMEGA328Pmiernik1.BIN" aktuell in 
Deinem Tester verwendest. Ist das richtig?

- Stammt das File "ATMEGA328Pmiernik1.BIN" aus dem beschädigten Chip 
oder "aus dem Internet"?
- Von wo genau hast Du dieses File heruntergeladen?
- Wird das LCD korrekt angesteuert?
- Ist es dieses File das Dir die zu kleinen Werte liefert?
- Wie sind die Fuses des ATMEGA programmiert?
- Welches ist die Frequenz deines Quarz?

Dass die Werte durch zwei geteilt sind, kommt von einer falschen 
Taktfrequenz für den Mikrocontroller. Da muss die Software für die 
richtige Taktfrequenz neu kompiliert werden, oder die Fuses müssen 
anders gesetzt werden.

Das TL866 sollte auch die *.hex Files aus dem Git-Repository brennen, 
wir müssen "nur" die richtige Variante der Firmware herausfinden. Der 
springende Punkt ist der Display-Controller, und da bin ich bisher nicht 
fündig geworden.

Gruß, derri

Tomek L. schrieb:
> Ich habe auch ein Programm aus dem Internet, aber es zeigt die Werte
> geteilt durch 2.

Die Ursache ist wahrscheinlich die falsche Taktfrequenz für dieses 
Programm.
Normalerweise ist durch die Fuses des ATmega ein Quarzbetrieb 
eingestellt. Dann wäre das Programm für einen 16 MHz Quarz vorgesehen, 
installiert ist aber auf der Platine ein 8 MHz Quarz. Wenn auf der 
Platine doch ein 16 MHz Quarz installiert ist, sind die Fuses 
wahrscheinlich noch auf den internen RC-Takt ohne 8:1 Teiler eingestellt 
(8 MHz).
Das Display hat mit hoher Wahrscheinlichkeit einen ST7565 Controller 
oder etwas kompatibles. So kann man wahrscheinlich auch die 
Programmdaten aus dem Software/trunk/mega328_st7565 Unterverzeichnis im 
git Archiv
(https://github.com/mikrocontroller-net/transistortester) auch 
verwenden.
(Voraussetzung ist natürlich, daß das Display so angeschlossen ist, wie 
in Standard beschrieben.)
Da sind zwei Programm-Daten abgelegt, mega328_st7565.hex für den 
Flash-Speicher und mega328_st7565.eep für das EEprom. Beide müssen in 
den ATmega geladen werden und außerdem die Fuses richtig gesetzt sein 
(lfuse=0xf7, hfuse=0xd9, efuse=0xfc).
Die Dokumentation zum Transistortester ist übrigens jetzt unter
https://github.com/kubi48/TransistorTester-documentation
in einem separaten Archiv.

Tomek L. schrieb:
> Ich bitte um ein gutes Programm für atmega 328p

Nachtrag:

Hallo Tomek,

Schau Dir doch bitte mal folgende Seiten an:
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg1025863/#msg1025863

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

Auf der letzteren ist ein Link zu einer passenden Software: 
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/?action=dlattach;attach=253819

Zusammen mit den Tipps von Karl-Heinz solltest Du Dein Gerät damit zum 
Laufen bringen. Du musst die Fuses setzen wie im angehängten Bild 
(Leider besitze ich nur ein älteres TL866A, da kann die Bediensoftware 
etwas anders aussehen).

Gruß, derri

Vielen dank für ihr Interesse !!!
Die Datei "ATMEGA328Pmiernik1.bin" stammt wahrscheinlich aus China vom 
Verkäufer des Testers, aber die Testergebnisse, z. B. Kondensator, 
Widerstand zeigen geteilt durch 2.
LCD funktioniert OK
Der Quarzresonator ist 8 MHz
FuseByte F7, D9, FC, FF

Das ursprüngliche Programm befand sich im beschädigten 328, es ist 
unmöglich, es zu lesen. Chip 328 ist fehlerhaft.

Ja, TL866 und Vellon programmieren BIN und HEX.

Tomek L. schrieb:
>es ist unmöglich, es zu lesen. Chip 328 ist fehlerhaft.

normalerweise wird da nur 1 Port zerstört,
meistens ist das Lockbit gesetzt und verhindert das auslesen!

Tomek L. schrieb:
> LCD funktioniert OK
> Der Quarzresonator ist 8 MHz
> FuseByte F7, D9, FC, FF

Dann würde ich versuchen, den Chip mit den Files aus dem eevblog zu 
flashen (siehe Bild). Die Files sind zwar von 2016, aber als proof of 
concept geeignet. Sollte Dein Tester dann richtige Werte anzeigen, kann 
man daran gehen, eine aktuelle Version zu compilieren.

Viel Erfolg!

derri

Das Atmega 328 Original ist physisch beschädigt, es hat einen 
Kurzschluss in der Stromversorgung.

Ich kann das Programm nicht von 16MHz auf 8MHz konvertieren :(
Bitte helfen Sie mir bei der Überarbeitung.

Tomek L. schrieb:
> Ich kann das Programm nicht von 16MHz auf 8MHz konvertieren

bei EEVBLOG findest du doch auch die 8MHz Version, was ist jetzt dein 
Problem?

aber ich weiß nicht welche version ich habe.

Tomek L. schrieb:
> Ich kann das Programm nicht von 16MHz auf 8MHz konvertieren :(
> Bitte helfen Sie mir bei der Überarbeitung.

Hallo Tomek,

Wenn ich Dich richtig verstehe, willst Du dein Programm 
"ATMEGA328Pmiernik1.bin" patchen, um es an 8-MHz Taktfrequenz 
anzupassen. Aus verschiedenen Gründen ist das kaum zu schaffen:
- wir kennen die Version der Software-Sourcen nicht,
- wir kennen die Compiler-Version nicht, mit der die Firmware erzeugt 
wurde,
- wir wissen nicht, welche Optionen im Makefile beim Compilieren 
eingestellt waren.

Es ist leider nicht so, dass man einfach irgendwo ein Byte mit dem Wert 
16 auf 08 ändern müsste. Die Sache ist viel, viel, viel komplizierter.

Auf der anderen Seite gibt es die Version "GM328x ESR tester (SVN684) - 
v2" aus dem eevblog. Nach den Fotos, die im Blog gezeigt werden, 
entspricht der Tester genau Deinem Exemplar. Im ZIP-File haben wir ein 
Makefile und fertig kompilierte Firmware für 8 und 16 MHz Taktfrequenz.

Mein Vorschlag ist, die Files "GM328x ESR tester (SVN684) - v2\original 
8MHz\TransistorTester.hex" und "GM328x ESR tester (SVN684) - v2\original 
8MHz\TransistorTester.eep" aus dem ZIP-File "GM328x ESR tester (SVN684) 
- v2.zip\" in Deinen funktionsfähigen 328p-Chip zu brennen. Die 
Fusebytes so lassen wie sie sind, die sind korrekt. Dann sollte der 
Tester erst mal funktionieren.

Ist das der Fall, dann kann man die aktuelle Softwareversion 1.13k von 
Karl-Heinz mit Hilfe eines angepassten Makefiles compilieren und neue 
hex- und eep-Files erzeugen. Dabei bin ich gerne behilflich, wenn Du 
möchtest. Mit Hilfe des Makefile ist es möglich, eine ganze Reihe von 
Funktionen des Testers (im Rahmen des verfügbaren Flash-Speichers) an- 
oder abzuschalten. So kann man den Funktionsumfang Deines Testers 
nachbilden, oder sogar erweitern. Siehe hierzu 
https://raw.githubusercontent.com/Mikrocontroller-net/transistortester/master/Doku/trunk/pdftex/german/ttester.pdf 
ab Seite 49.

Wenn Du unbedingt die "ATMEGA328Pmiernik1.bin" benutzen willst, dann 
bleibt m. E. nur die Lösung, den Quarz mit 8 MHz durch einen mit 16 MHz 
zu ersetzen.

Gruß, derri.

Vielen Dank für die Erklärung und den Hinweis.
Ich habe den Quarzresonator auf 16 MHz geändert und es ist in Ordnung.
Ich empfehle einen so kleinen DC-DC-Wandler von USB auf 9V für die 
Stromversorgung. Für mich geht das. Sie können zum Beispiel bei 
Aliexpress kaufen.
Vielen Dank !!

Tomek L. schrieb:
> Vielen Dank für die Erklärung und den Hinweis.
Bitte, gerne!

> Ich habe den Quarzresonator auf 16 MHz geändert und es ist in Ordnung.
Dies war wohl die einfachste Lösung. Freut mich, dass der Tester wieder 
funktioniert.

derri

Tomek L. schrieb:
> Ich empfehle einen so kleinen DC-DC-Wandler von USB auf 9V für die
> Stromversorgung.

Darüber habe ich mir auch schon mal Gedanken gemacht. An sich gibt es 
mehrere Alternativen zur Stromversorgung:

- die Standardlösung mit einer 9 V Blockbatterie (nicht wirklich 
umweltfreundlich),
- 9 V Stecker-Netzteil,

- deine Lösung mit Spannungswandler 5 V -> 9 V mit Spannung aus einer 
USB-Buchse,

- die direkte Speisung aus einem USB-Anschluss,
- eine günstige kleine USB-Powerbank,
- einen 3,7 V Akku mit Ladegerät, ähnlich RPI Powerpack V2.0 (teuer),

Zur Zeit benutze ich die beiden ersten Varianten. Die letzten drei 
Varianten setzen voraus, den Spannungsregler mit seinen 
Hilfsbauelementen, wie Buchse, evtl. Dioden oder Gleichrichter, 
Siebkondensatoren usw. des Testers zu entfernen und durch eine 
USB-Buchse zu ersetzen. Der Einbau der USB-Buchse erfordert etwas 
Geschick, aber das Einsparen der Batterie reizt mich schon. Der Nachteil 
bei der direkten Speisung per USB ist, dass der Tester dann nicht mehr 
portabel ist.

Deine Idee finde ich nicht übel, daran hatte ich noch gar nicht gedacht. 
Aber der Vorteil ist sicher, dass man am Tester nichts ändern muss. Ich 
bin noch am Überlegen ...

Jedenfalls danke für den Tipp!

...naja, die onboard Lsg mit 18650 und integriertem Lade und Boost Ic 
wie bei den Chins Clones ist schon "nice"!

Klaus.

Hier der Umbau der "FISH8840" Variante von 2015 mit gebrauchten 
Handy-Akku, Stepup und Ladereglung über USB. Der Aufwand hielt sich in 
Grenzen.
Das Teil läuft heute noch...

mit 18650
https://www.mikrocontroller.net/attachment/268547/Fish-Tester-Inductor-Mod--05.jpg

hier mit Handy-Akku
Beitrag "Re: Transistortester AVR"


Gruß Michael

Hallo zusammen, mal eine ganz dumme Frage, ich betreibe seit Jahren 
einen Tester mit Arduino Nano. Bei Version 1.12k läuft das gut außer die 
Messung von Kapazitäten die sehr viel größer werden angezeigt. Beim 
gleichen Aufbau mit 1.13k zeigt gleich ein mosfet an ohne das was 
angeschlossen ist. Compiliert unter Linux mint 20.1 weil ich winavr 
nicht so gut am laufen bekomme. Heute ardutester 1.13 Sketch über 
arduino ide hochgeladen mit auch die mosfet Auswertung.
Wer o wer weiß was da falsch läuft.
Schöne Ostern und Grüße aus Holland

Hast du die D13-LED an PB5 weg genommen oder ist die noch da?

Den zugehörigen wiederstände weggenommen disable—pull-up ausgeschaltet 
aber beide versucht . Ich überlege das Ganze neu aufzubauen
Schöne Grüße und Dankeschön

Du könntest noch den Selbsttest laufen lassen und die Werte posten.

Das Problem scheint sich langsam zu lösen, ich hatte keine Referenz 
Spannung angeschlossen. 47k an A4 hat nicht geklappt, Vcc bei usb 4.63v 
über vin 4.93v.
Lösung 5v über labornetzteil oder buckboost an vcc, ein 2*20k 
spannungsteiler zwischen Vcc und - an A4. 1.12k deutlich besser, 1.13k 
demnächst testen. Das komische ist das man im Internet viele Tester mit 
Nano sieht ohne Referenz teilweise mit .ino Dateien für arduino IDE aber 
funktioniert  genauso schlecht oder schlechter. Somit habe ich jetzt ein 
funktionierendes chinesisches Nano mit zweizeiliges 1602 Display. Wenn 
alles richtig funktioniert werde ich Karl-Heinz mein Aufbau zuschicken.
Zum Problem mit eeprom hochladen über ch340g scheint bei mir zu 
funktionieren mit optiboot von Karl-Heinz wenn Mann baudrate 
zurückschraubt auf 57600.
Schöne Grüße von Leon

Hi, wollte seit langem mal den Frequenzgenerator des Testers mit der
Ver.1.13 REF.781 (Fish8840) verwenden. bei den vorhergehenden Versionen 
waren die Ausgangsfrequenzen fest vorgegeben und durch scrollen 
anwählbar, was ich sehr praktisch fand.
Bei der neuen Menuführung blicke ich überhaupt nicht durch.
Natürlich habe ich auch in der Doku gesucht. Dort wird FG in seiner 
Bedienfunktion nicht erwähnt...

Gruß Michael

Michael D. schrieb:
> Dort wird FG in seiner
> Bedienfunktion nicht erwähnt...

Hallo Michael,

... in den neueren Beschreibungen kannst Du es nachlesen:

https://raw.githubusercontent.com/Mikrocontroller-net/transistortester/master/Doku/trunk/pdftex/german/ttester.pdf

Kapitel 3.2 Optionale Menüfunktionen für den ATmega328

... ab Seite 41

Gruß Horst

Das ging ja fix. Auf die Seite wäre ich nie gekommen, bin da wohl 
woanders rumgedümpelt. Das Projekt wurde nach GitHub verschoben?

Vielen Dank für die schnelle Hilfe Horst!

Gruß Michael

Die Bedienung ist da(ohne Beschreibung) schon ein wenig Tricki, wenn man 
das nicht weiß...

Scheint doch ein problem In die software zum Beispiel 1.12k beim 
selbsttest 30 bis 31 pF bei 1.13k zweite stelle -57000, habe die 
Anschlüsse des Nano neu gelötet mit extra flux 1.12k gibt jetzt 470uF 
wird als 370 angegeben 2200uF als 15mF.
Muss allerdings zugeben das die wiederstände nicht ganz genau 
übereinstimmen. Kann das die Ursache sein?
Schöne Grüße von Leon

Hallo Ralph
Wenn Vcc 10% weniger ist wird die Batterie Spannung 20% abweichen.
Versuch mal im makefile die mindest Batterie Spannung runter zu stellen.
Herzlichen Glückwünsche zum erfolgreichen Bau deines Tester
Schöne Grüße von Leon

Ralph schrieb:
> ich bin stolz auf meinen nach der Grundschaltung komplett selbst
> zusammengebauten Tester auf Basis eines 328P. Er funktioniert jedoch
> nur, wenn ich die Option für die Präzisionsspannungsreferenz in der
> config.h deaktiviere. Verbaut habe ich einen LM4040A (2,5V) und beim
> durchmessen schaut alles gut aus. Bei aktivierter Option schaltet sich
> der Tester nach dem Anzeigen der Batterispanung sofort wieder aus, mit
> deaktivierter Option bleibt er an und misst. Was kann die Ursache sein?
>
> #define HW_REF25
> #define UREF_25           2500

Wahrscheinlich ist der Tester der Meinung, dass die Batteriespannung zu 
niedrig ist. Hast du den Spannungsteiler für die Batteriespannung 
bestückt? Du kannst aber auch die Batterieüberwachung komplett 
abschalten (BAT_NONE).

Ralph schrieb:
> bei deaktivierter Präzisionsreferenz
> läuft der Tester

... hast Du mal die Spannung an der Referenz direkt beim Einschalten 
gemessen, die gibt es ja in unterschiedlichen Werten?

Gruß Horst

Ralph schrieb:
> du noch einen Einfall

... an welchen Port hast Du sie denn angeschlossen, stimmt das mit der 
Pinbelegung in der config_328 überein?

Gruß Horst

Hallo Ralph
Werte im makefile gehen vor Änderungen in config.h
Ich würde außerdem mal folgende Spannungen direct am atmega Pins messen
Vcc und Referenz Spannung wenn ich mich nicht irre a4 Batterie 
spannungsteiler a5. Der Vorschlag von Markus Batterie Check 
auszuschalten würde ich als erstes probieren. Könnte sein das der 
spannungsteiler falsch herum ist angeschlossen?
Viel Erfolg Grüße Leon

Leon T. schrieb:
> Scheint doch ein problem In die software zum Beispiel 1.12k beim
> selbsttest 30 bis 31 pF bei 1.13k zweite stelle -57000, habe die
> Anschlüsse des Nano neu gelötet mit extra flux 1.12k gibt jetzt 470uF
> wird als 370 angegeben 2200uF als 15mF.
> Muss allerdings zugeben das die wiederstände nicht ganz genau
> übereinstimmen. Kann das die Ursache sein?

Mit der Toleranz der Widerstände wächst auch die Toleranz der Messwerte, 
aber nicht so extrem. Merkwürdig ist auch, dass der kleine Elko zu 
niedrig und der grosse viel zu hoch gemessen wird. Für Kondensatoren ab 
etwa 47µF wird die gleiche Messfunktion genutzt, d.h. ein Fehler sollte 
sich auf beide Elkos gleich auswirken. Hast du die Elkos an den gleichen 
Testpins gemessen?

Ralph schrieb:
> Eine Änderung des Wertes hat leider keinen Erfolg gebracht. Beim Start
> wird die Batteriespannung im Display angezeigt mit "ok" und es erscheint
> sehr kurz "Suche", dannach schaltet sich mein Tester stets sofort aus.

Dann liegt es nicht an der Batterieüberwachung. Als Nächstes könntest 
du, wie von Horst vorschgeschlagen, die Pinzuordnung überprüfen.

Hallo Markus, vielen dank für deine Antwort, klar an den gleichen 
testpins, jetzt 2 Platinen in Betrieb eine ohne und eine mit genau 5v 
Vcc und Referenz durch 2x20k spannungsteiler, gleiche Werte mit 
verschiedene nano‘s. Was aber noch mehr stört ist das die 1.13k gar 
nicht richtig funktioniert und ohne Anschluss gleich mit ein mosfet 
anfängt und beim selbstbestimmt wird das 104 nF nicht erkannt, mit die 
ardutester 1.13 arduino Sketch genau den selben Sch...
Und auch mit die uno makefiles von Karl-Heinz ohne Display. Schöne Grüße 
von Leon. Kann es an die chinesischen arduino nano‘s liegen?

Bei den Arduinos ist übrigens der Kondensator an AREF 100nF (statt 1nF, 
wie in der Transistortester-Referenzschaltung). Mit dem größeren 
Kondensator dauert das Umladen beim Wechsel der ADC-Referenzspannung 
länger. Für die k-Firmware kann man das über das Abschalten von 
"NO_AREF_CAP" im Makefile kompensieren. Und für die m-Firmware heißt der 
Schalter ADC_LARGE_BUFFER_CAP.

Hallo Markus NO_AREF_CAP ist eingeschaltet, verstehe ich richtig das ein 
100nF im arduino verbaut ist? Gibt es auch eine M Version die sich für 
das arduino Nano eignet?
Schöne Grüße von Leon

Umgekehrt, NO_AREF_CAP abschalten. Und ja, die m-Firmware läuft auch auf 
den Arduinos mit ATmega.

Ralph schrieb:
> ... natürlich 2,557V

... ist ein zu hoher Wert, laut Datenblatt hat die A-Version max. 2,515 
Volt. Mit welchem Vorwiderstand betreibst Du denn die Referenz?

Wenn die Spannung vom vorgegebenen Wert der config abweicht, kannst Du 
den Wert hier anpassen:

#define UREF_25           2557

Gruß Horst

stimmt so ungefÄhren, Referenz soll genauer sein als dein Messgerät. 
Einzige was ich noch denken kann ist ein Multiplikationsfaktor in die 
Software  um von pc5 1.95v auf die Batterie Spannung zu kommen. Was 
zeigt das Gerät an für Vcc und Batterie bin ausgeschaltete Referenz?
Schöne Grüße von Leon

Hallo Markus gerade versucht die 1.43m zu kompilieren 328p mit 2 Zeilen 
Display. Leider Fehlermeldungen über doppelte Definition in St7565r und 
wenn ich st7565r nicht mitnehme Fehler in Main.c und oder Display.c über 
lcd_contrast. Vielleicht mache ich was falsch könnte ein Hinweis 
brauchen um das Problem zu lösen. Hab mich auch umgesehen zum esp32 
wegen höhere adc Auflösung und dan kam die newsletter mit die Nachricht 
das der adc wandler nicht so gut funktioniert.
Schöne Grüße von Leon und ein schönes Wochenende

Das passiert, wenn man mehr als ein Display konfiguriert. Bei einem 
HD44780 die Konfiguration für das HD44780 aktivieren und die vom ST7565R 
deaktivieren (die ist standardmäßig aktiviert). Sofern LCD_CONTRAST 
gesetzt wurde, obwohl das Display das nicht unterstützt, gibt es die 
LCD_Contrast()-Fehlermeldungen.

Hallo Markus hatte den Fehler gefunden meine Dummheit Dankeschön und 
schönes Wochenende Leon

Frage für Karl-Heinz
Ist es möglich das 1602 Display mit I2c zu benutzen in 1.12k und 1.13k?
Was hat sich geändert zwischen die 2 Versionen, mein Nano Setup hat 
schwere Probleme mit der 1.13k Version mosfet während nicht 
angeschlossen, Selbsttest bricht ab weil Kapazität nicht erkannt wird. 
Ich denke an wait subroutines oder vielleicht adc oversampling.
In 1.12k wird nur die Kapazität mit große Abweichungen gemessen, der 
Rest funktioniert ziemlich gut. Habe das ganze auch auf neue Hardware 
aufgebaut mit gleiches Resultat.
Schöne Grüße von Leon Tummers aus den Niederlanden.

Hallo Markus

Leider habe ich mich vertan, der kleine Elko zeigt jetzt 1180 uF an 
statt 470, der große 15 mF statt 2200uF also der Messfehler steigt 
exponentiel mit die Größe des Elko.
Leider klappt die 1.43m auch nicht so richtig, am Display kommt als 
erste Zeile Grafik raus und dan was mit Pro und dsg was wieder schnell 
verschwindet. Auch die 1.13 ardutester kommt mit mosfet Daten ohne 
angeschlossenes Bauteil. Wenn ich umschalte auf Vt100 das gleiche.
Die wiederstände habe ich unter das Nano zwischen die Pins auf die 
lochplatine verbaut.
Was ist deine neueste m Version die sich noch auf 1.12 von Karl-Heinz 
basiert? Habe jetzt auch ein i2c 1602 zur Verfügung um das ganze noch 
mal neu zu bauen. Vielen Dank und Schöne Grüße von Leon Tummers aus den 
Niederlanden.

Vielleicht ist ein Pin vom ATmega defekt. Starte mal den Selbsttest und 
poste die Werte.

Hallo Markus selbsttest funktioniert auch nicht richtig in der 1.13k 
Version aber Tester 2x aufgebaut und mit verschiedene arduino nano‘s 
versucht. Ich möchte noch einmal neu bauen mit i2c 1602 und nur eine 
Taste sodass der Aufbau so einfach wie möglich ist. Ich will dabei die 
Wiederstände separat auf die Platine aufstellen vielleicht hilft das. 
Nützen die testierte von 1.12k vielleicht?
Schöne Grüße von Leon

Hallo Markus leider nur eine Datei möglich pro Beitrag dies ist der 
einzige vollständige Test die mir gelingt
Schöne Grüße von Leon

Hallo Markus leider nur eine Datei möglich pro Beitrag dies ist was in 
1.13k heraus kommt
Schöne Grüße von Leon

Hallo Markus leider nur eine Datei möglich pro Beitrag und dies ist was 
in 1.43m heraus kommt wahrscheinlich mein Fehler.
Schöne Grüße von Leon und voraus Dank für deine Mühe

Neuer Versuch

Neuester Versuch

Leon T. schrieb:
> Hallo Markus selbsttest funktioniert auch nicht richtig in der 1.13k
> Version aber Tester 2x aufgebaut und mit verschiedene arduino nano‘s
> versucht. Ich möchte noch einmal neu bauen mit i2c 1602 und nur eine
> Taste sodass der Aufbau so einfach wie möglich ist. Ich will dabei die
> Wiederstände separat auf die Platine aufstellen vielleicht hilft das.
> Nützen die testierte von 1.12k vielleicht?

Bis incl. T6 sind die Tests identisch bei k und m-firmware. Es geht nur 
darum zu sehen, ob die Werte ok sind. Wenn aber selbst der Selbsttest 
nicht funktioniert, dann ist wahrscheinlich bei der Hardware etwas 
schief gelaufen, oder das Pinout passt nicht. Am sinnvollsten dürfte 
sein, den Schaltplan zu nehmen und alles Stück für Stück zu überprüfen. 
Und beim Arduino muss auf die LED an D13 (PB5), die TTL-Serielle 
(USB2serial) und den 100nF-Kondensator an AREF aufpassen.

Leon T. schrieb:
> leider nur eine Datei möglich pro Beitrag

Andere konnten mehrere Dateien anhängen, z.B.
Beitrag "Re: Transistortester AVR"

Unter dem "Browse..." Button ist noch der "Weitere Datei anhängen" 
Button.

... und dann gibt es noch zip.

Hallo Alexander

Ein wenig schwierig auf IPAD weitere hat nicht funktioniert
Schöne Grüße von Leon

Leon T. schrieb:
> Angehängte Dateien:
>
>
>
>           tt113k.log (5,02 KB)

Bei Test2 der Version 1.12k fällt auf, daß der 680 Ohm Widerstand an TP3 
deutlich abweicht. Die 680 Ohm Widerstände an TP1 und TP2 scheinen 
ziemlich gleich zu sein. Den Widerstandswert selbst kann der Tester 
nicht messen, aber die Port-Innenwiderstände scheinen plausibel zu sein. 
Bei großen Abweichungen von 680 Ohm würden die Port-Innenwiderstände 
deutlich vom Normalwert abweichen.

Ein völlig seltsames Ergebnis der Null-Kapazität zeigt sich aber bei der 
Version 1.13k. Das zeigt sich sowohl bei der normalen Messung als auch 
mit der SamplingADC Methode.
Zur Klärung der Ursache ist es wahrscheinlich sinnvoll, die Makefile und 
die .hex und .eep an meine Email-Adresse zu schicken.
Ich habe einen Testaufbau mit Arduino-Nano Clone, der mit der 1.13k 
normal läuft. Die 1.13k habe ich über meinen optiboot Bootloader 
geladen. Die LED an PB5 (Arduino D13) des Nano habe ich deaktiviert!

Hi Karl.

I have tried to compile your new version for a mega328_color_kit and for 
a mega328_T3_T4_st7565 but I get errors in the sources.

It only compiles me correctly with the English language and the source 
to 8x16.

I attach photos of the compilation in the mega328_color_kit.

Thanks and best regards.

Hallo Karl.

Ich habe versucht, Ihre neue Version für ein mega328_color_kit und für 
ein mega328_T3_T4_st7565 zu kompilieren, aber ich erhalte Fehler in den 
Quellen.

Es kompiliert mich nur korrekt mit der englischen Sprache und der Quelle 
auf 8x16.

Ich füge Fotos der Zusammenstellung im mega328_color_kit hinzu.

Danke und viele Grüße.

Pepe P. schrieb:
> I get errors in the sources.

Hello,

there is a '.h' missing in

1

#include "language-dependent_characters"

It should read

1

#include "language-dependent_characters.h"

See 
https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk/fonts

Pepe P. schrieb:
> It only compiles me correctly with the English language and the source
> to 8x16.

Many thanks for the error report!
The missing .h is corrected in file 8x8_vertikal_LSB_1.h.

Some special characters for Spanish are now available with the latest 
github source.
But some characters are not yet defined and are replaced as follows:
  a_super='a', o_super='o', n_tilde='n', N_tilde='N',
  updown_exclam='!', updown_question='?' .
As far as I know, no special Spanish characters are currently used in 
the TransistorTester software.
Defined and usable are the characters
 a_acute, c_cedil, e_acute, i_acute, o_acute, u_acute,
 u_uml, A_acute, E_acute, I_acute, O_acute and U_acute.

Hello.

Thanks Karl and Alexander.

I have verified that it compiles well in both English and Spanish and 
with 8x8, 8x16 and 8X12 Thin fonts.

During the morning I will adjust the compilation to my needs and install 
it in the different component testers that I have for testing.

Thank you very much and greetings.

Hallo.

Danke Karl und Alexander.

Ich habe überprüft, dass es sowohl in Englisch als auch in Spanisch und 
mit 8x8-, 8x16- und 8X12-Thin-Schriftarten gut kompiliert werden kann.

Während des Vormittags werde ich die Kompilierung an meine Bedürfnisse 
anpassen und sie in den verschiedenen Komponententestern installieren, 
die ich zum Testen habe.

Vielen Dank und Grüße.

And now for something completely different ...

Für die Source-Code-Historiker habe ich die Entwicklung von Markus' 
Version in GitHub verewigt (ausgelöst durch diese Diskussion 
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg3565497/#msg3565497), 
Version 0.99m ... 1.43m sind jeweils ein Commit als annotated Tag, man 
kann also alle Änderungen von Version zu Version nachvollziehen:

https://github.com/Ho-Ro/ComponentTester

Hallo und guten Abend,

wisst ihr von Problemem mit Grafikdisplays mit ST7920 über SPI Bitbang? 
Ich habe zwei verschiedene Displays getestet, aber erhalte stets nach 
der Versionsanzeige "Timeout Error". Herkömmliche Zeilendisplays bei 
gleichem Aufbau laufen tadellos. Bin für jeden Tip dankbar...

Gruß Ralle

Beim Timeout-Fehler wurde der Watchdog ausgelöst. Probiere bitte in 
ST7920.c in der Funktion LCD_ClearLine() am Anfang nach den Variablen 
Folgendes einzufügen:
  wdt_reset();                /* reset watchdog */

Die Funktion LCD_ClearLine() gibt es zweimal!

Markus R. schrieb:
> Beim Timeout-Fehler wurde der Watchdog ausgelöst.

Hallo Markus,

herzlichen Dank für diesen Tip! Tatsächlich klappt es damit jetzt über 
den Batterietest hinweg bis zur "Suche...". Danach kommt jedoch sofort 
erneut der Timeout Fehler. Sollte ich noch weitere Stellen in der 
ST7920.c berücksichtigen, außer den beiden genannten?

Viele Grüße, Ralle

Das scheint mir Richtung MCU-Takt zu gehen. Hast du vielleicht den 
8:1-Vorteiler in den Fuses aktiviert? Oder ist die MCU-Frequenz im 
Makefile falsch?

Hallo Ahmed,

Ahmed schrieb im Beitrag #6716582 (aus dem Arabischen mit 
translate.google.com):

> Ahmed M.
>...
>Kannst du mir den Code und Schaltplan schicken?

Den Schaltplan findest Du unter
https://c2.at.ua/1SX/1/ESR_shema.png oder
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg709934/#msg709934

Der Code befindet sich in
https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk

>...
>Ich möchte den Bildschirm meines Nokia 1100 LCD ändern

Wenn ich richtig verstehe, willst Du das Original-LCD des T4 durch ein 
Nokia-1100-LCD ersetzen? Dann ist das Makefile im Unterverzeichnis 
"mega328_PCF8814" wahrscheinlich das richtige (@Karl-Heinz, bzw. andere 
Sachkundige: bitte korrigieren, falls das nicht stimmt).

Tipp: Anpassungen an verschiedene Anwendungsfälle der Software sollen 
soweit wie möglich im Makefile erfolgen, und nicht in den *.C- oder 
*.H-Files.

Gruss, derri.

Marcel D. schrieb:
> Der Code befindet sich in
> 
https://github.com/Mikrocontroller-net/transistortester/tree/master/Software/trunk
Die neueste Version der Software ist jetzt unter:
https://github.com/kubi48/TransistorTester-source

Die Dokumentation ist getrennt auf:
https://github.com/kubi48/TransistorTester-documentation

Scripts zur Unterstützung einer Linux Installation findet man auf:
https://github.com/kubi48/TransistorTester-Linux-install

Die Trennung wurde durchgeführt, weil es praktisch unmöglich ist, alte 
Inhalte aus dem Git Archiv zu löschen. Der Download von den neuen 
Adressen geht jetzt schneller, weil viel alter Ballast fehlt.

Der früher in das Projekt integrierte spezielle optiboot Bootloader ist 
jetzt ebenfalls getrennt auf:
https://github.com/kubi48/avr-assembler-optiboot

Marcel D. schrieb:
> Dann ist das Makefile im Unterverzeichnis
> "mega328_PCF8814" wahrscheinlich das richtige
Das ist das richtige Verzeichnis. Ich habe aber nicht selbst getestet, 
weil mir das Display fehlt.

@kubi48
Danke für die Klarstellung, Karl-Heinz.

Mit meinen besten Grüssen, derri.

Markus R. schrieb:
> Das scheint mir Richtung MCU-Takt zu gehen. Hast du vielleicht den
> 8:1-Vorteiler in den Fuses aktiviert? Oder ist die MCU-Frequenz im
> Makefile falsch?

Hallo Markus, hallo zusammen,

ich habe meinen Testaufbau wieder mit einem einfachen Zeilendisplay 
verbunden und verschiedene Tests gemacht, der Tester arbeitet tadellos 
und erkennt die Bauteile. Alle Softwareschalter sind auf default, ich 
stelle wirklich nur in der config_328.h das Display um auf das ST7920, 
wechsle das Display aus und schon ist der Timeout-Fehler sofort wieder 
da, kurz nachdem "Suche" erscheint.
Damit würde ich eine falschen MCU-Takt ausschließen, könnte es am 
Display liegen? Ich habe es ausgewählt, da es sehr groß ist und ohne 
Brille gut lesbar. Vielleicht sollte ich doch ein anderes Display 
versuchen, was besser unterstützt wird?

Viele Grüße
Ralle

Du könntest noch ein "wdt_reset();" in die Funktion LCD_DotPos() in der 
Datei ST7920.c packen. Ich hatte beim Schreiben des ST7920-Treibers auch 
mit einem ATmega328 bei 8 MHz und Bitbang-SPI getestet. Daher bin ich 
etwas über das Timeout verwundert. Der ST7920 braucht zwar bei SPI drei 
Bytes statt nur einem, aber das ist bei einem Monochromdisplay nicht 
weiter tragisch. Ich denke, dass das Timeout (2s) eine andere Ursache 
hat.

Hallo Markus,

kleiner Eintrag, große Wirkung! Mit dem wdt_reset läuft es jetzt, was 
bin ich froh! Damit kann ich den ganzen Aufbau endlich fest 
zusammenlöten.
Vielen herzlichen Dank!

VG Ralle

Hello I just joined the forum today.  I apologize that this is in 
English using a google translator to read posts.  I Have a GM328A just 
bought from Amazon.  I believe this would be the "mega328_color_kit" 
hex/eep files from Mikrocontroller github trunk.  I flashed another 
Atmega328P using two Arduino unos, one as an ISP obviously the second 
one I put a zif socket for easy insertion/removal.  Using Arduino IDE to 
load ISP sketch all connections are correct.  I am using the Flash 
Software "avrdudeprog33" this version I have supports Arduino.  Once I 
flash and insert the MCU into the GM328A there is a lot of latency on 
startup and moving through the menus.   I was guessing maybe some of the 
Fuses are customized for this device and tried a few combinations using 
the "https://www.engbedded.com/fusecalc/"; and none seem to help the 
latency issue.  I cannot extract the firmware from this default MCU they 
have locked it so no way to figure out the differences between the 
default firmware and the one available from the Github.  Any suggestions 
as to what else I could try or fuse settings?  Maybe the firmware from 
the trunk is not exactly correct for this device could that be why? 
There is another firmware by this person and has a game Tetra on it and 
it does not work at all.  He also has the GM328A but maybe a different 
version hardware?

https://dragaosemchama.com/en/2019/04/gm328a-reverse-engineering-new-firmware-and-tetris/#comment-31406

Ronald G. schrieb:
> Any suggestions
> as to what else I could try or fuse settings?

The default fuse setting for the teste is lfuse=0xf7, hfuse=0xd9 and 
efuse=0xfc.
You should ignore a error message, if the unused bits of efuse are read 
back as '0'. It is important, that the clock source in the lfuse is 
selected correctly.
Usually you can program the ATmega with the Makefile. You need only the 
commands "make fuses-crystal" to set the fuses and "make upload" to 
upload the firmware.
The type of ISP programmer must be selected in the Makefile with a 
source editor (PROGRAMMER=... and PORT=...).
With Windows you should install the Arduino package first and you need 
additionally a make.exe program (suggested: with cygwin package).

I know only a wrong clock selection as reason for a slow menu function.
You can additionally speed up the output for the color display by 
changing the crystal with a 16MHz version and recompile the the software 
(Makefile setting OP_MHZ=16).

Ronald G. schrieb:
> I Have a GM328A just bought from Amazon.
> I believe this would be the "mega328_color_kit" ...
> hex/eep files from Mikrocontroller github trunk.

Yes, I think you're right. I have the same one, see figure 2.24 in the 
manual "ttester.pdf" from the github repository. Download from:
< 
https://github.com/kubi48/TransistorTester-documentation/blob/main/TransistorTester_english.pdf 
>. It is a good idea to read the manual any way, especially the chapters 
about customizing the software.

> Once I flash and insert the MCU into the GM328A there is a lot
> of latency on startup and moving through the menus ...

Maybe the processor runs on the internal 1 MHz clock, which is the 
factory setting.
Please check the frequency of the crystal on your device. The default 
setting of the precompiled firmware is 8 MHz. If the hardware has a 16 
MHz crystal, the parameter OP_MHZ in the makefile must be changed to 
OP_MHZ=16, and the firmware recompiled (see manual). You need a 16 MHz 
crystal to use the better resolution offered by the sampling ADC 
feature.

> I tried a few combinations using the "https://www.engbedded.com/fusecalc/"; ...

Please try to set the fuses to: lfuse=F7; hfuse=D9; efuse=FC; this works 
for me and almost any atmega328p setup. You can check these settings in 
fuscalc.

> I cannot extract the firmware from this default MCU ...

That's the chinese way of handling open source projects. :-(

Greetings, derri

Thanks for the reply I’ll look over the documentation tonight.  The 
crystal is 8mhz so so I choose external crystal 8mhz for the fuse? 
That’s the only thing I can think of. The one I have says GeekTeches 
printed on the board is this the one you have and your not noticing any 
latency?  I even accidentally flashed the mcu that came with it same 
issue but the original MCU ran perfectly fine. I’ll double check the 
settings but I have L/H Fuse the same as yours the efuse will let me 
disable or enable boot…….0/1/2 I forgot the name but I think it’s 
related to brownout protection so I don’t see how that would impact the 
way it runs it has to be something with the settings of the MCU clock 
and external crystal onboard 8mhz.  I’ll have another one today just to 
make sure.  Is the software I am using to flash possibly the cause?

Ok the issue must be the flash software avrdudeprog33 or something I am 
doing wrong with the settings in there, because the software is missing 
some data in the microcontroller after it’s flashed, for example there 
is no hard coded list of frequencies in the frequency generator menu, 
something either wrong with the hex and epp files or the software flash 
programming ?   I use the program all button after loading both the HeX 
and Epp files so now I have to try a different approach.  You can load 
the make file into the arduino IDE software did not know that, thought 
only sketches or code went in there.  Can I use the make file that is 
located in the folder where you find the hex and epp files from the 
software folder then trunk?    I still don’t understand why flashing 
with the combination of two arduino’s and avrdudeprog33 is not working? 
I will first try a couple of different approaches such as instead of 
programming all button, I’ll program the fuse followed by the hex file 
then followed by the epp if you can do this?

Sorry tried to edit my last post but it was over 1 hour so I could not. 
I could run Arduino IDE and whatever else I need in MAcOS BigSur.  After 
watching some Youtube video tutorials, they were able to compile and 
flash to the arduino from a command line.  The tutorial was about the 
GNU make and they downloaded both the Arduino-cli and CppLint for 
flashing the firmware onto the Arduino's instead of using IDE's for 
embedded programing I am guessing they mean instead of using the Arduino 
IDE.  I am not sure what exactly else I would need to do or which 
direction to go without making this too complicated, is there a tutorial 
for this on a MacOS?  Over 20 years ago I was configuring making and 
compiling linux kernels when USB was becoming popular, but in linux not 
MacOS.  If its just easy in windows 10, I could use EditPlus or 
Notepad++ to modify the make file and just do this in the Arduino IDE if 
that would be easier , but I would need all the source files then 
correct?

Hi Ronald,
Ich hatte die gleichen Probleme. Ich habe alles getestet, aber unter 
Windows klappte es nie. Die einfachste Lösung war, auf einem alten 
Notebook ein aktuelles Linux Mint und die nötigen Pakete installieren. 
Damit hast du den einfachsten und besten Weg, mit nur einem Befehl alle 
Quelldateien zu kompilieren und die Firmware-Dateien zu übertragen. 
Schau dir die Anleitung an, dort ist alles sehr gut beschrieben.

Hallo zusammen,

da ich meinen LCR T4 gerne "einhausen" möchte und dabei auch mit Lipo + 
5V step up versorgen möchte - ist es funktional nachteilig, von den 
ursp. 9V Versorgung weg auf 5V zu gehen? Nutzt er die höhere Spg für 
bestimmte Messungen?

EDIT: Laut Schaltplan ja nicht, weil DUT nur an den uC Ports hängt - 
einzig die LED + Einschalt-Mimik ist auf 9V ausgelegt.

Danke, Klaus.

Klaus R. schrieb:
> Nutzt er die höhere Spg für
> bestimmte Messungen?

Es muß nur die Schaltung zum Abschalten angepasst werden und der
Spannungsteiler für die Batteriespannungsmessung sollte für eine bessere 
Auflösung auch angepasst werden (z.B. 2:1).
Leider muß die Batteriespannung hinter dem Einschalt-Transistor gemessen 
werden, weil sonst dauerhaft Strom aus der Batterie gezogen wird. Das 
ist auch dann der Fall, wenn man den Spannungsteiler ganz weg lässt 
wegen der Schutzdioden an den ATmega-Eingängen.

Hallo Karl-Heinz,

ist das zufällig im git dokumentiert, der nötige Umbau?

Muss man die Batt SpgsM im Code ändern, so dass sie nicht zu früh 
reagiert (wie man sie abschaltet, weiß ich)?
Eigentlich kann ich sie ja eh deaktivieren, oder ich messe damit die 
LiPo Zelle (das wäre natürlich super) - denn nach dem step-up sinds ja 
eh konstant 5V :)

Danke, Klaus.

Hallo Klaus,

vielleicht hilft die Schaltung der Funkamateure (FiFi 2013)weiter,
die hier immer noch zum Download bereitsteht:
https://o28.sischa.net/bauteiltester/trac/browser/trunk/Hardware?order=name

Die passenden Makefiles findet man unter mega328_1.9V für die 
Batterieversion
und mega328_3.3V für die LiPo Version.

Klaus R. schrieb:
> der nötige Umbau?

… ev. kann die Schaltung des TC1 Dich ja inspirieren.

Gruß Horst

...uiii, dachte nicht, dass der TC1 so viel weiter ist / kannte ihn 
nicht. Wenn man das mal in Betracht zieht, sollte ich den nehmen und um 
Drehencoder sowie Buchse für fGen und fMess erweitern und fertig. Auch 
wenn ich das monochrome LCD des LCR T4 besser finde.

Edit: Und IRMP haben die da auch noch eingeklaut..eieiei :)

Klaus.

Hallo Klaus,

... ist das jetzt Ironie?

Am 16.10.2020 19:41 in einem Betrag von Dir wolltest Du doch schon div. 
Mod 's an Deinem TC1 durchführen? ;-)

Gruß Horst

Hallo,

bin mit dem Umbau des LCR T4 fast fertig - kann ich den Drehencoder auch 
verkabeln, ohne die Option erstmal im Code zu nutzen, also HW Vorhalt? 
Und dann hinterher aktivieren, so dass es zunächst keine neg. 
Auswirkungen hat?

Karl-Heinz K. schrieb:
> und der
> Spannungsteiler für die Batteriespannungsmessung sollte für eine bessere
> Auflösung auch angepasst werden (z.B. 2:1).

Wo ist das im Code dann anzupassen? Werde direkt die LiPo Spg messen.

Danke!

Horst O. schrieb:
> wolltest Du doch schon div.
> Mod 's an Deinem TC1 durchführen? ;-)

Ne, habe "nur" den LCR T4, aber ewig - ja, ich hatte das vor, bin aber 
nie dazu gekommen - bis heute :)

Klaus.

Klaus R. schrieb:

> Karl-Heinz K. schrieb:
>> Spannungsteiler für die Batteriespannungsmessung sollte für eine bessere
>> Auflösung auch angepasst werden (z.B. 2:1).
>
> Wo ist das im Code dann anzupassen? Werde direkt die LiPo Spg messen.
>
> Danke!

Das sollte nicht im Code angepasst werden, sondern im Makefile. Da sind 
extra zwei Konstanten für den Spannungsteiler definiert:

// Voltage divider for battery voltage measurement  10k / 3.3k = 133/33
CFLAGS += -DBAT_NUMERATOR=133
CFLAGS += -DBAT_DENOMINATOR=33

Suche nach diesem Text und ersetze die beiden Werte mit den 
entsprechenden Kennwerten deines Spannungsteilers. Beispiel: Teiler 2:1 
mit 10k/10k also
CFLAGS += -DBAT_NUMERATOR=2
CFLAGS += -DBAT_DENOMINATOR=1

Gruss, derri

Ja, kapiert - Danke! Hätte es iwio als #define erwartet aber so ist es 
vermtl eleganter...

Bleibt noch die Frage der späteren Aktivierung des Drehencoders?

Klaus.

Hallo Klaus,

... in diesem Beitrag vom 16.10.2020 hattest Du "LCR T1" geschrieben,was 
ich dann wohl falsch ausgelegt habe, es hätte sicher "LCR T4" heissen 
sollen.

Gruß Horst

Ronald G. schrieb:

> The crystal is 8mhz so so I choose external crystal 8mhz for the fuse?
Yes, that's correct! But just set the fuses to the values Karl-Heinz 
gave you (See attached screenshot). These values DO WORK!

> I have L/H Fuse the same as yours the efuse will let me disable or enable
> boot…….0/1/2 I forgot the name but I think it’s related to brownout
> protection
Yes, it's BODLEVEL, and defines the minimal supply voltage level. An 
automatic reset occurs when the supply falls below it. You may ignore it 
for now.

> Is the software I am using to flash possibly the cause?
Right now I'm confused about which software you mean ... avrdudeprog33 
or the MCU firmware?

> I use the program all button after loading both the HeX and Epp files

I suppose you have also set the fuses and checked all three "Programm" 
Options FLASH, EEPROM and FUSES?

> I’ll program the fuse followed by the hex file then followed by the epp
> if you can do this?

Yes, try that, in that order, each time hitting "Programm" and then 
"Verify". If you get errors, then there is something wrong with your 
setup or your microcontrollers are defective!

As for compiling the firmware from the github repository, I would 
postpone that for the moment. Since your device has a 8 MHz crystal, you 
can use the precompiled hex and eep files provided by Karl-Heinz 
Kübbeler. It should run on your tester without modification. So just use 
the files from the subdirectory "mega328_color_kit". If that works for 
you, we can talk about customizing.

Hope this helps, derri

...damit ich nicht nur Fragen stelle hier mal der Stand, vll ist es ja 
für irgend wen interessant / inspirierend:

- Gehäuse 8x10x2,5 - Prototyp aus Wellpappe (vermtl mache ich ein 
Pultgehäuse draus)
- alte Powerbank geplündert
- LiPo Spg wird gemessen (3.3k -> 10k ändern)
- Drehencoder ist eingebaut aber noch nicht final angeschlossen
- der ZIF Sockel ist schon zml durch, den muss ich mal durch einen neuen 
ersetzen...
- Anschlussmgl für PWM out / FreqMess fehlt noch (weiß noch nicht, was 
ich "praktisch" finde)
- SMD Testfeld TBD (ich hatte leicht federn gelagerte Kupferstreifen am 
externen Feld, das verschafft besser Kontaktmöglichkeiten durch Andruck
- eine Messbuchse für Cs kommt noch dazu, ähnlich wie in meinem alten 
Voltcraft DMM
- SW TBD: BattMsg auf 2:1 anpassen, Warnschwelle auf 3.3V / 3.0V (Lipo) 
setzen, Drehencoder aktivieren

-> "So" funktioniert er aber erstmal wieder...

Klaus.

Moin
woher hast Du den Lipo-Lader/Wandler?
Gruß