Bei mir sind es mit dem ATMega48 "nur" 4082 Bytes (99,7% Full). Geht
also...
Ich habe aber auch noch das avr-gcc aus März 2009. Muss ich mal updaten.
Das mit der fehlerhaften Transistor-Erkennung überprüfe ich mal.
> Du hast nicht die Archiv-Version genommen, ich pflege Deine> Aenderungen jetzt manuell ein. Ich bitte Dich aber, dann auch auf dem> Archiv weiter zu arbeiten, sonst bringt das nichts.
Ja, sorry. Mache ich in Zukunft.
Naja bei mir wird es zu gross, da kein fertiges Hexfile in Deinem Update
vorhanden war hab ich es jetzt in diesem Release geloescht. Den Fix hab
ich manuell eingepflegt. Ist keine gute Idee das so knapp zu halten, Du
solltest noch was raus nehmen, sonst kann man es nicht ohne Weiteres
selber compilieren, nicht jeder verwendet die selbe Compiler-Version.
Michael G. schrieb:
> Naja bei mir wird es zu gross, da kein fertiges Hexfile in Deinem Update> vorhanden war hab ich es jetzt in diesem Release geloescht. Den Fix hab> ich manuell eingepflegt.
Genau deswegen sollte die aktuelle Version weiterhin auf der
Artikelseite veröffentlich werden, wo sie auch jeder wie gewohnt findet
können sollte.
Markus' Projekt ist ein toller Erfolg und hat viele Nachbauer gefunden.
Wieso sollte es jetzt umziehen?
> Wieso sollte es jetzt umziehen?
Das habt ihr falsch verstanden:
Das Projekt bleibt auch weiterhin hier, und in dem Artikel werden auch
zukünftige Versionen veröffentlicht werden.
Das mit dem SVN ist vor allem für die noch nicht "offiziellen" Versionen
gut: Man hat immer einen Ort, an dem die neueste Version zu finden ist.
Hier in dem Thread gehen diese Versionden nämlich schnell wieder unter:
Wenn nahc dem Post mit der neuesten Firmware schon 20 weitere Posts
kamen, schaut sich kaum noch einer den Post mit der Firmware an.
Man braucht ueberhaupt keine Files mehr hier posten, dazu wird ein
Snapshot generiert, der immer aktuell ist. Das reicht. Dazu reicht ein
einziger Link an der richtigen Stelle. Und der Rest passiert
automatisch.
Hallo Markus,
Das Projekt ist schon weltweit benutzt(!). Ich verstehe bisschen
deutsch, aber nicht alle diese Sprache verstehen zu können, deswegen
viele lokale Versionen schon spin-off gemacht haben. Das macht kein
Sinn, weil deine Änderungen später noch mal bei dieser lokalen
Versionen wiederholen müssen sein.
Findest Du richtig zusammen alle Übersetzungen sammeln schon und als
ein Teil des Projekts pflegen? Ich denke, es wird kein Thema freiwillige
Dolmetschern zu finden. Das ist kleine Dinge 5 Minuten für
Übersetzung zu finden. Wenn die Länge aller Texte für alle Sprachen
gleich werden, nur lokales Eprom vorbereitet muss.
Was eben keinen Sinn macht ist diese dezentrale Entwicklung. Wuerde
jeder am Archiv arbeiten, traeten diese Probleme eben nicht auf: D.h.
wenn Person A einen Fehler behebt fliesst diese automatisch in die
Version von Person B mit ein (durch den Merge), die andere Aenderungen
(z.B. eine Uebersetzung) vornimmt.
Ich kann ja mal versuchen die anderen Sprachversionen zu mergen.
Insofern es eine gemeinsame Codebasis gibt, geht das auch. Dann muss man
halt z.B. im Makefile angeben, welche Sprache man benutzen will.
Arbeitet dann wieder jeder auf einer nicht-offiziellen Version weiter
bringt das natuerlich nichts auf Dauer, denn die Arbeit mach ich mir
dann auch nicht staendig, nur weil man die Leute nicht zu einer
vernuenftigen Arbeitsweise bringen kann. Dann kann man aber auch nicht
von einem Gemeinschaftsprojekt sprechen.
I attached latest version of Transistor tester :
Polish version - file Transistortester-PL.zip and
English version - file Transistortester-EN.zip.
My proposition is add jumper, to select language version.
fe. jumper on PC4 ON - English version
jumper on PC4 OFF - German version
jumper on PC3 ON other language version fe. Polish
Markus und Janusz haben (neben mir) jetzt Schreibzugriff auf das Repo.
Falls noch jemand mitarbeiten will bzw. weitere Layouts usw. zur
Verfuegung stellen wollen, soll er bescheid geben.
Ich möchte bei dieser Gelegenheit mal auf
Beitrag "Re: Versionsverwaltung" hinweisen.
Kurzfassung: Mikrocontroller.net bietet einen SVN-Server an, auf dem man
sich mit dem Forenaccount einloggen kann. Welche Benutzer Zugriff haben
kann der Besitzer des Repositorys selbst per Webinterface einstellen.
Hallo zusammen,
weil Janusz hat keine Quelle geschickt, schicke ich polnische
Übersetzung als Quelle für SVN. Ich denke, es macht kein Sinn durch PIN
die Sprache auswächlen, das kostet Flash und Eprom. Und das ist kein
Produkt für den Markt :) Ich denke, es wird besser einfach verschiedene
Eproms vorbereiten oder - das benutze ich persönlich - einfaches Menu
mit drei Tasten, weil das für weitere Dienge dienen kann. Atmega8 sehr
klein ist und wird , ich denke, bald mit etwas ersätzen. Ich benutze
Atmega16 dafür, mehr PIN-e und Speichern, JTAG etc.
Ich hab das Teil nun aufgebaut und in ein Gehaeuse verfrachtet. Dank
Markus' Aenderungen funktioniert nun auch die Erkennung sehr gut, vorher
wurden Bauteile oft falsch erkannt und manche Messungen haben gar nicht
funktioniert.
Waere sinnvoll wenn jeder seine FW auch updaten werde, die aktuelle
Version findet Ihr hier:
http://coremelt.net/files/software/repository-tarballs/semiconductor_tester.tar.gz
Michael
Mit der neuesten Firmware aus dem SVN gibt es ein neues Problem:
Verarmumgs-FETs werden jetzt größtenteils als Anreicherungs-FET
erkannt...
Ein Update ist also erst dann sinnvoll, wenn dieser Fehler auch noch
behoben ist. Ich kümmere mich darum.
Nochmal eine andere Frage:
Besteht überhaupt noch Interesse an der Firmware für den ATMega48?
Mittlerweile fehlen der ja schon eine ganze Menge Features, weil die in
den 4kB Flash einfach keinen Platz haben.
Und da in der neuen avr-libc die EEPROM-Zugriffsroutinen geändert wurden
und nun mehr Flash kosten, müssen sogar noch Features entfernt werden,
damit das Programm überhaupt in den Mega48 passt (oder man müsste selbst
EEPROM-Routinen in Assembler schreiben).
Hat jemand den Tester mit Mega48 aufgebaut oder plant, das zu tun?
Wenn nicht ergibt es ja auch keinen Sinn, diese Version noch weiter zu
verfolgen.
Also wenn Du mich fragst, hat sich mir der Sinn nicht ganz erschlossen,
zwei Versionen so zu pflegen, denn der Mega48 ist nur unwesentlich
guenstiger als ein Mega8. Daher werden wohl fast alle den Mega8
verwendet haben, wer verzichtet wegen weniger als einem Euro schon auf
viele Features ;)
Michael
Von mir aus kann's gerne beim 168 bleiben, damit ist genügend Raum für
zukünftige Erweiterungen. Den 48 halte ich nicht für attraktiv und den
Zusatzaufwand nicht wert.
Hi!
als glücklicher Benutzer eines AVR-Transistortesters (Danke Markus
F.!!!!), bin ich auch dafür, es beim ATmega8 zu belassen, de 48 lohnt ja
kaum ...
Gruss, Ingo.
Dears All,
I’m sorry for English but I can’t speak German. I built original tester
from Markus F and it worked for the first time. I tested more components
and get different results. Please look below. Do you have idea, what
could be wrong here or its normal behavior of this built.
Please let me know, because I like this construction, because is simple
a clever. Many thanks Martin Hlavicka
Transistors
2N3416
Connected in order 123: NPN B=3, C=2, E=1, hFE=20 Uf=765m … GOOD RESULT
Connected in order 321: P-D-MOS, GDS=132 … WRONG RESULT
SC1815
Connected in order 123: NPN B=3, C=2, E=1, hFE=58 Uf=814m … GOOD RESULT
Connected in order 321: P-JFET GDS=132 … WRONG RESULT
BC549
Connected in order 123: NPN B=2 C=3 E=1 hFE=282 Uf=795m … GOOD RESULT
Connected in order 321: N-JFET GDS=213 … WRONG RESULT
Capacitors:
Connected in order 12 (both polarity): N-JFET GDS=132
Connected in order (both polarity): CAPACITOR 3-2 102,64uF
Connected in order (both polarity): CAPACITOR 3-2 102,04uF
Resistors:
Totally wrong for value 18k and connected between 1-2 the result was:
REZISTOR 3-1 R=89,7k, same component, but between 2-3:
N-JFET GDS=132
Hello Markus,
Thank you for the link, I uploaded there now, but behaviour is same.
May-be I must have some issue in circuit, if everybody else works fine.
Please let me know if you have some idea.
Martin
Ich habe eine Frage an den Autor.
Wenn jemand das Programm verbessert. Und sagt, dass auf dem Forum.
Schützt den Code. Er gilt als der Autor. Er hat es nicht den
überarbeiteten Programm. Ob es fällt so.
Ich möchte Janusz begrüßen.
Hallo MSZR.
Ich habe den Tester auch nachgebaut und habe auch dafür einen Atmega16
benutzt.
Leider hab ich noch Probleme mit der Softwareanpassung.
Wäre es möglich das du das Programm für den Atmega16 hier ins Forum
stellst?
Und vielleicht deinen Schaltplan dazu?
MFG
Hallo,
ich versuche das ganze mit einem Mega 32 zum Laufen zu kriegen. Bisher
werden so ziemlich alle Bauteile falsch erkannt :( Nur das Makefile und
die Pinbelegung anpassen reicht offenbar nicht. Richtige Erkennung
bisher nur bei einer Diode (auch nur in einer bestimmten Polarität) und
ohne angeschlossenes Bauteil. Dh. aber, dass der ADC funktioniert, und
die Signale über die Pins an den Widerständen werden auch ausgegeben -
woran kann es dann liegen??
Hallo Matthias,
ja, es geht aber ich bin unterwegs leider. Wenn nach Hause komme, tue
ich das gerne. Leider das kann ziemlich lang dauern und das basiert
nicht auf die neue Version des Testers.
> Was soll der Quatsch? - Dieses Forum hat Dein Projekt erst bekannt> gemacht. Warum pflegst Du es nicht weiter in diesem Forum?
Es wird ja hier weiter gepflegt, nur die neueste Version der Firmware
(die häufig auch nur zu Testzwecken da ist) kommt eben in des
SVN-Repository.
Damit sich hier keiner beschweren kann, hänge ich sie auch noch an
diesen Beitrag an.
Neue, stabile Versionen werden auch weiterhin in dem Artikel eingefügt
werden.
Im wesentlichen bleibt also alles beim Alten.
Für die Entwicklung bietet das SVN jedoch Vorteile, vor allem weil
mehrere Leute gleichzeitig an dem Projekt arbeiten können.
=> microhead:
I don't know, but perhaps there ist something wrong with your setup. I
think something on test pin 1 is bad (from your test results).
Hallo,
nu läufts bei mir mit dem Mega 32! Ich musste nichts ändern außer die
Pinbelegung und das Makefile. Der Fehler lag darin, dass ein oder
mehrere Pins defekt sind. Nu habe ich das auf einen anderen Port verlegt
und es geht. Zumindest werden mein Transistor und meine Diode nun
korrekt identifiziert. Mehr habe ich noch nicht ausprobiert.
Michael G. schrieb:
> http://viewvc.coremelt.net/viewvc/avr/semiconductor_tester/?view=log>> Hier sind die Aenderungen, inkl. Dateilisten und diffs.
schön .. aber Michael, wenn du schon so überall schreibst "with a board
layout from me", dann mach bitte vernünftiges board.
Z.zt. ist es wirklich "pfui", schon mal dir gedanken gemacht das für
tragbares, stromsparendes gerät (so wie von Markus F. entworfen ist)
etwas wenig sinn mach diese ollen elkos, brückengleichrichter und
schraubklemmen einzusetzen ? Also ich persönlich halte ungerne 5m langes
verlängerungskabel und labornetzteil nur um einen transistor zu testen
:)
Du hast mal gesagt "Dazu koennte ich noch ein alternatives Layout (mehr
SMD) anbieten" - dann mach es bitte so - guck dir die bilder und
platinnen von leuten die seit einem jahr bei dem projekt "dabei" sind.
Nicht das ich unbedingt ein board brauche, nur wenn ich smd lese und
dann diese vor-meiner-zeit-bauteile sehe :) Da sind die DIL versionen
schon faktor 2 kleiner als dein smd entwurf.
gruss
Thomas
Hallo zusammen,
esteinmal möchte ich (wie viele zuvor) sagen, das dies ein klasse
Projekt ist. :)
Aber jetzt kommt mir eine Idee, für dessen Beurteilung und Umsetzung mir
das Wissen fehlt.
Könnte man nicht auch eine Prüfung von Akkus einbauen?
Grüße
Kay
Ja (je nachdem was man da prüfen will) Sinnvoll wäre evtl. die
Spannungen mit 2 verschiedenen Belastungen zu messen und daraus den
Kurzschlussstrom/Innenwiderstand zu berechnen. Akkus die frisch
aufgeladen trotzdem die Digitalkamera nicht versorgen können, kann man
so ermitteln.
> Könnte man nicht auch eine Prüfung von Akkus einbauen?
Jain. Mit einem zusätzlichen Portpin müsste das möglich sein, mit der
jetzigen Hardware geht es aber nicht.
Ein Problem ist aber der Messbereich:
Um auch mal Akkupacks messen zu können, sollte die Maximalspannung schon
so 20V sein. Dann ist allerdings die Auflösung "nur noch" 0,02V.
Für eine einfache Spannungsmessung reicht das, für eine
Innenwiderstands-Messung aber nicht.
Eigentlich wäre das als extra Gerät aber besser. Zum Beispiel ein Gerät,
das den ESR von Elkos messen kann und gleichzeitig auch noch zum
Akku-Test verwendbar ist. Für beides ist nämlich eine recht ähnliche
Hardware erforderlich.
Die Elko-ESR-Messung könnte man z.B. folgendermaßen machen:
Erst wird der Elko komplett entladen.
Dann wird er über einen Widerstand langsam aufgeladen und die Zeit
gemessen, bis die Spannung einen bestimmten Wert erreicht. Daraus lässt
sich die Kapazität berechnen (so macht es auch der Transistortester für
die Kapazitätsmessung).
Für die ESR-Messung braucht man eine Last, also einen niederohmigen
Widerstand.
Um auch mal Elkos mit sehr geringem ESR messen zu können, sollten
mehrere Messbereiche vorhanden sein.
0,1 Ohm sind für den "niedrigsten" Messbereich durchaus realistisch.
Bei 5V Elkospannung würden da kurzzeitig ca. 50A Entladestrom fließen.
Das ist kein Problem für einen geeigneten MOSFET.
Hierin besteht nun die Herausforderung: Man muss die Last so schnell wie
möglich mit dem Elko verbinden, sonst wird das Messergebnis falsch.
Da Power-MOSFETs mit geringem Rds aber auch eher viel Gate-Kapazität
haben, braucht man einen sehr starken Gate-Treiber. Vielleicht reicht
ein ICL7667.
Als MOSFET sollte man einen mit schnellen Schaltzeiten, wenig Rds und
wenig Gatekapazität verwenden.
Ich habe noch ein paar 2SK3572 rumliegen (von einem defekten Mainboard),
die könnten geeignet sein: 4,4mOhm Rds; 3,2nF Gatekapazität; 300A
Peak-Drain-Strom (80A Dauerstrom) und 14ns Anstiegszeit. Könnte
brauchbar sein...
Kurz (also z.B. 0,5µs) nach dem Einschalten der Last muss mit einer
Sample+Hold Schaltung die Elkospannung gespeichert werden, um sie dann
in aller Ruhe per ADC auswerten zu können.
Mal sehen, vielleicht versuche ich das mal.
Ein Problem sehe ich aber noch:
Es passiert leicht mal, dass man einen geladenen Kondensator anschließt.
Dabei sollte der Tester nicht kaputt gehen.
Das Dumme ist, dass dafür der MOSFET für den Lastwiderstand die
Elkospannung verkraften muss. Das geht aber nicht, weil es keine MOSFETs
gibt, die hohe Nennspannung mit oben genannten Eigenschaften
kombinieren.
Na gut, man könnte z.B. eine 6V Surpressordiode und eine Sicherung
einbauen.
Aber bitte keine 5*20mm Feinsicherung, im Zusammenhang mit Elkos haben
die ihren Namen nicht verdient: Die ohne Sandfüllung haben nur so 50A
Trennschaltstrom, darüber kann der beim Durchbrennen entstehende heiße
Metalldampf die Sicherung weiterhin leiten lassen.
Die 10,3*38mm-Sicherungen sind aber perfekt (120.000A
Trennschaltstrom...)
Prinzipiell könnte man dann vielleicht auch mit einem ATMega16 oder 32
einen "Kombi-Tester" aufbauen, der Halbleiter, Elko-ESR und Akkus testen
kann.
Guten Tag.
Ich finde das Projekt ist super.
Ich würde es gern nachbauen aber es gibt da folgendes Problem: C
Leider bin ich nicht so geistreich in C sondern nur in Assembler.
Auch habe ich noch nie ein C-File in Assembler umgeschrieben.
Hätte jemand einen guten Rat für mich wie ich das machen könnte?
MFG Tino
OT:
Ich verstehe C auch nicht und will diesen kryptichen Mist auch nicht
erlernen.
Trotzdem habe ich diese überaus nützliche Schaltung nachgebaut.
Man muss sich ja auch nicht, nur um Auto fahren zu können, die
Getriebeteile selbst fräsen...;-)
MfG Paul
Du brauchst doch für einen Nachbau kein C zu erlernen. Das brauchst Du
erst, wenn Du in den Quellcode eingreifen willst.
Das Werkzeug, das C in Assembler-Code umwandelt, nennt sich übrigens
C-Compiler ;-).
>Das Werkzeug, das C in Assembler-Code umwandelt, nennt sich übrigens
C-Compiler ;-).
In AVR Studio gibts es ja einen, aber ich weis nicht wie man den in so
einem Fall anwendet.
Hätte jemand einen Tip?
MFG
Tino schrieb:
> Guten Tag.>> Auch habe ich noch nie ein C-File in Assembler umgeschrieben.> Hätte jemand einen guten Rat für mich wie ich das machen könnte?
Von der Sinnlosigkeit mal abgesehen: Versuch es mal mit einem Compiler.
Und an C ist nichts kryptisch, das glaenzt eigentlich durch seine
Einfachheit (das ist natuerlich relativ), wenn man es vom Level der
Sprache aus betrachtet.
Michael G. schrieb:
>Von der Sinnlosigkeit mal abgesehen: Versuch es mal mit einem Compiler.>Und an C ist nichts kryptisch, das glaenzt eigentlich durch seine>Einfachheit (das ist natuerlich relativ), wenn man es vom Level der>Sprache aus betrachtet.
Zum Compiler: siehe Eintrag obendrüber.
Und warum ist es sinnlos? Wäre es auch sinnlos wenn das Programm in
Assembler geschrieben wurde und es in C umgeschrieben werden müsste?
Ich kann mich des Eindrucks nicht erwehren, dass da die Sprache C
schlecht gemacht wird, weil jemand den Compiler nicht bedienen
kann/möchte.
Dabei ist das keine Kunst; das Projektfile (*.aps) ist mitgeliefert.
Die ganze Kunst beschränkt sich also auf ein, zwei Klicks im AVR Studio.
Und davon abgesehen, braucht man zum Zusammenbau des Testers nicht
einmal zu kompilieren oder AVR Studio hochzufahren, da sowohl das .hex
als auch das .eep sich im Zipfile befinden.
C ist doch auch nur ein prozessorunabhängiger Assembler...
"C combines the power of assembler with the portability of assembler. -
Anonymous, alluding to Bill Thacker.
Tino schrieb:
> Michael G. schrieb:>>>Von der Sinnlosigkeit mal abgesehen: Versuch es mal mit einem Compiler.>>Und an C ist nichts kryptisch, das glaenzt eigentlich durch seine>>Einfachheit (das ist natuerlich relativ), wenn man es vom Level der>>Sprache aus betrachtet.>>> Und warum ist es sinnlos? Wäre es auch sinnlos wenn das Programm in> Assembler geschrieben wurde und es in C umgeschrieben werden müsste?
beachte den unsinn nicht, wer nur c kann und kein assembler kann
schlecht die vorzüge von asm "sehen".
Die .aps ist dabei, im avrstudio öffnen und compilieren, dann hast du
auch eine .lss file, wenn unbedingt asm sein muss kann man diese file
wunderbar als vorlage benutzen.
Ich habe gerade nochmal einen (kleineren) Fehler beseitigt:
Bei einigen Bauteilen floss auch nach Test-Ende noch Strom durch das
Bauteil.
Z.B: Wenn man eine LED reinsteckt, mit Anode an Pin 1 und Kathode an Pin
2, dann leuchtet die auch nach den Test noch, bis sich der Tester wieder
abschaltet.
Das lag an der Kondensator-Messung, die unter bestimmten Bedingungen
fälschlicherweise mit einem "return" verlassen wurde, ohne die I/O-Pins
wieder auf Eingang zu schalten.
Anbei (und im SVN) die neue Firmware.
Hello everyone,
I'm realizing this tester and I have difficulty for programming the
ATmega8 processor.
I have a programmer GALEP 4 and I do not know 'how do I use the two
files in the flash and EEPROM circuit.
I tried to schedule the first block of flash memory with the fuse bits
and then the EEPROM of the LCD but the screen remains dark, I measured
the signals with the oscilloscope and are "freezed".
This is the problem,
on the galep program this fusebits is very hard too find, I have find
the clock fuse but the lfuse and hfuse is not present....
And the eeprom file (.eep)and the flash file (.hex) I need to loads in
two separate steps.
I think the problem is precisely the fusebits and programming with
galep4 is more complex.
Possibly you can have an Atmega8 already programmed?
my email is emili.claudio(at)tiscali.it
Anyone can help me?
I'm very worried.....I have recheck all connections of my circuit and
are all good the problem is the ATmega8...my programmer not "program"
I have buyed the processor on RS components with pn 628-1788
ATmega8-16PI
is correct or not?
Vor einigen Tagen bin ich über dieses tolle Projekt gestolpert - genau
so was hab ich gesucht! Seit vorgestern ist der Tester zunächst auf
einem Steckbrett aufgebaut und sagt mir endlich, was da bei mir
herumliegt. Im Zuge der Tests ist mir aufgefallen, dass für die
Messungen der ganze ADC-Port immer wieder umprogrammiert wird, obwohl ja
nur drei Pins für die Messungen verwendet werden. Bemerkt hab ich es,
weil ich die Pin-Belegung etwas geändert hab, um RxD und TxD für
künftige Erweiterungen frei zu bekommen. (vgl. den Header in der
beigelegten Datei) In meiner Version liegen ON-Pin und RST-Pin ebenfalls
am Port C. Das lässt sich aber über die defines leicht ändern. (vgl.
Zeile 279-284)
Im Zuge der Anpassung hab ich dann begonnen, die Software etwas zu
reorganisieren, besondern um Erweiterungen leichter einbauen zu können.
Was ich eingebaut hab:
- beim Messen werden nur noch die drei beteiligten Pins von Port C
umprogrammiert
- $Id$-String für das automatische Eintragen der Version durch SVN
- Watchdog mit define "SIMULATION" abschaltbar (Mein AVR-Studio
generiert den Reset zu früh und zeigt ihn auch nicht im Status-Register
an)
- Watchdog wird nach einem Reset gemäß der Doku zu avr/wdt.h
abgeschaltet
- define für englische Texte, so ähnlich könnten auch weitere Sprachen
eingebunden werden, ohne mehr Platz im Speicher zu benötigen
- zerlegen der main-Funktion auf einzelne Funktionen, vgl. die
Main-Funtkion am Ende der Datei
Was haltet ihr davon?
=> Claudio Emili:
> ATmega8-16PI> is correct or not?
This is correct.
But I don't have the Galep4 and don't know how to program an AVR with
it.
=> Avery:
> Was haltet ihr davon?
Zu der Aufteilung der main() in einzelne Funktionen:
Kann man machen, ich halte es aber für nicht sonderlich sinnvoll: Die
Funktionen werden nicht mehrfach aufgerufen.
Programmtechnisch hat es nur Nachteile: Es verbraucht mehr Flash, und
verschwendet wegen des eigentlich unnötigen Sprungs in eine andere
Funktion, bei dem wieder alle Register in den Stack gechoben und nachher
wieder rausgeholt werden, auch etliche CPU-Zyklen.
Es macht den Code eben evtl. etwas übersichtlicher.
> beim Messen werden nur noch die drei beteiligten Pins von Port C> umprogrammiert
Das schadet nicht und ist auch sinnvoll, wenn man die Pin-Belegung mal
ändern will. Es macht das Ganze auch besser erweiterbar.
Der einzige Nachteil ist (wie üblich), dass es Flash kostet. Und der
wird eben allmählich knapp.
> Watchdog wird nach einem Reset gemäß der Doku zu avr/wdt.h> abgeschaltet
Ja, das ist sehr sinnvoll. Sonst könnte sich der AVR nämlich allein
durch diese Funktion
1
lcd_eep_string(TestTimedOut);//Timeout-Meldung
2
_delay_ms(3000);
in einer endlosen Reset-Schleife aufhängen.
> Watchdog mit define "SIMULATION" abschaltbar (Mein AVR-Studio> generiert den Reset zu früh und zeigt ihn auch nicht im Status-Register> an)
Das kann auch nicht schaden.
> define für englische Texte, so ähnlich könnten auch weitere Sprachen> eingebunden werden, ohne mehr Platz im Speicher zu benötigen
Das ist auch gut.
Ich würde vorschlagen, man könnte auch .eep-Files in verschiedenen
Sprachen mit ins Archiv packen. Dann muss man nur die Datei für die
gewünschte Sprache ins EEPROM programmieren.
Ich baue das mit dem abschaltbaren Watchdog und der WDT-Abschaltung beim
Einschalten auch mal in meine Version ein und lege alle LCD-Strings ins
EEPROM, um das mit den verschiedenen Sprachen per .eep-Datei möglich zu
machen.
Good news (for me of course ..)
I've finally managed to correctly program the processor ....
A show this tester, really useful and practical, I spent all day Sunday
I happened to test any semiconductor in the house, and all have given
excellent results.
Was wrong to send the files in the memory block of the processor program
GALEP, does not recognize the location automatically and not loads them
correctly, just programmed it worked perfectly, except the battery
indicator, I had to change the divider ranging up to 3 ,9Kohm.
A single question:
-you could implement the testing of IGBT?
would be complete in this way since these semiconductors are now
widespread and difficult to test properly
What do you say? you can 'do?
> you could implement the testing of IGBT?
IGBTs with a gate threshold voltage of less than 5 volts will be
detected as a MOSFET, I think
At the moment, I don't have many IGBT's. I tried it with a 600V/40A IGBT
(http://www.fairchildsemi.com/ds/HG/HGTG20N60B3D.pdf).
The test failed, because this IGBT has a gate threshold voltage of about
6.5 volts.
The problem is that the tester can't deliver more than 5 volts; because
of the supply voltage of the ATMega8. And most IGBTs habe threshold
voltages of 5 to 7 volts.
To generate test voltages of more than 5 volts, external devices (for
example transistors) are required. This makes the circuit of the tester
much more complicated.
And it would be difficult to tell IGBT and MOSFET apart.
Due to the saturation effects of the IGBT, the collector-emitter voltage
drop doesn't rise proportional to the current:
My 600V/40A IGBTs have a voltage drop of about 1.4V at 10A and 2.4V at
40A.
A MOSFET has an ohmic drain-source resistance; so the voltage drop is
directly proportional to the drain-source current.
But you can already see the problem: Huge currents are required for this
test. And it won't be good if the tester pushes 40 amperes through a
little SMD MOSFET ;)
Or the short form:
No, with the current hardware I can't implement the IGBT testing.
IGBTs shouldn't have a body diode. Wouldn't it be sufficient to check if
the device under test has a body diode and then decide if it's a fet or
transistor? This will of course not work for j-fets...
> IGBTs shouldn't have a body diode
My 600V/40A IGBTs have a body diode, and I looked into a datasheet of a
huge IGBT (3300V/1500A; type 5SNA 1500E330300). Even this one has a body
diode.
Hi,
>Zu der Aufteilung der main() in einzelne Funktionen:>Kann man machen, ich halte es aber für nicht sonderlich sinnvoll: Die>Funktionen werden nicht mehrfach aufgerufen.>Programmtechnisch hat es nur Nachteile: Es verbraucht mehr Flash, und>verschwendet wegen des eigentlich unnötigen Sprungs in eine andere>Funktion, bei dem wieder alle Register in den Stack gechoben und nachher>wieder rausgeholt werden, auch etliche CPU-Zyklen.
Stimmt nur bei ganz ausgeschalteter Optimierung (die man sowieso nicht
verwenden sollte)
Laut http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html :
>-finline-functions-called-once>Consider all static functions called once for inlining into their caller >even if
they are not marked inline. If a call to a given function is
>integrated, then the function is not output as assembler code in its own >right.>> Enabled at levels -O1, -O2, -O3 and -Os.
Von daher macht es vom Resourcenverbrauch her keinen Unterschied, der
AVR-GCC optimiert die Funktionsaufrufe sowieso weg.
Ist aber Geschmackssache
NIMRA
Ich habe jetzt die verschiedenen Sprach-Versionen eingefügt, außerdem
ist der Watchdog in dieser Version per Define ein- und ausschaltbar.
Now, there are three languages: German, English and Polish.
You can choose between the languages by programming the corresponding
.eep file into the EEPROM.
.. and in polish ...
Od teraz oprogramowanie dostępne jest w trzech językach, Niemieckim,
Angielskim i Polskim. Możesz wybierać pomiędzy językami programując
odpowiednią wersję .eep do EEPROM
...und keiner denkt an deutsch ;)
Es gibt jetzt 3 Sprachen: Deutsch, Englisch und Polnisch. Man waehlt zw.
den Sprachen durch das Programmieren der gewuenschten .eep datei ins
EEPROM.
Hi Markus,
Thanks very much again ...
I ask if it is possible to modify the ( Line 1110):
====> if((HighPin == cb) && (LowPin == ca)) return;
with this line:
====> if(PartFound == PART_CAPACITOR) goto end;
Thanx...
misser wrote:
> I ask if it is possible to modify the ( Line 1110):> ====> if((HighPin == cb) && (LowPin == ca)) return;> with this line:> ====> if(PartFound == PART_CAPACITOR) goto end;> Thanx...
Yes, this is possible. And it even saves a few bytes of flash memory.
I changed it in the attached version.
Hallo!
Möchte mich anschliessen:Dolles Projekt,habs noch nicht nachgebaut,werd
es aber versuchen.Leider kenn ich mich net so dolle aus mit der
Materie,hätte aber mal ne Frage.
Könnte mann nicht die Werte irgendwie speichern im PC oder nem
2.ATmega?Und anschliessend mit ´ner 2.Messung vergleichen?
Also wenn ich in der Bastelkiste zB.´n Transistor finde,brauche aber
3stck davon und hätte die Werte gespeichert,könnte ich doch weitere Tr´s
testen,mit den Werten vergleichen und angezeigt bekommen :Ja den und den
kannste nehmen.Weil sonst muss man ja wieder Datenblätter suchen und
vergleichen.Das soll ja gerade eingespart werden.Da die Daten für
Pinn,hfe,usw eh vorliegen.Oder ist das zu umfangreich und eher ein neues
Projekt?
Grüße aus dem Westerwald
Nic
=> syr:
> May I ask you to add Czech localization too. Thank you.
Yes, I will add it.
=> McGill:
> Oder ist das zu umfangreich und eher ein neues Projekt?
Ein neues Projekt wäre es eigentlich nicht, vielleicht aber eine
Abwandlung von diesem Projekt, mit etwas anderer Hardware.
Die letzten paar Test-Ergebnisse könnte man im EEPROM speichern. Das
wäre relativ leicht realisierbar.
Mit 8 Byte je Ergebnis dürfte man auskommen.
Die Controller (ATMega8, ATMega16 und ATMega168) haben 512 Byte EEPROM,
von dem ca. 350 Byte für die LCD-Strings und die Konfiguration
verbraucht werden.
Man könnte also etwa die letzten 20 Testergebnisse im EEPROM speichern.
Naja, wirklich viel ist das nicht.
Da wäre es eher sinnvoll, die Daten gleich während des Tests per UART
(RS232) an einen PC zu senden.
Nur leider ist der UART hier eigentlich nicht nutzbar, weil dessen Pins
für die LCD-Ansteuerung benutzt werden.
Man könnte aber z.B. per Jumper einstellbar machen, ob das LCD verwendet
werden soll oder ob die Daten per UART gesendet werden sollen.
Allerdings wäre es dann ratsam, den AVR mit einem Quarz laufen zu
lassen.
Normalerweise läuft der AVR bei dem Transistortester mit 1Mhz.
Man kann also einen 1MHz-Quarz anschleißen.
Aus mir nicht bekannten Gründen sind 1MHz-Quarze aber (vergleichsweise)
extrem teuer, bei Reichelt über 3 Euro (!) pro Stück (andere Quarze
kosten ca. 0,20€).
Man kann die Firmware aber auch für andere Takte verändern, dann ist sie
allerdings nicht mehr mit der Original-Firmware kompatibel.
Oder man nimmt einen Mega88 oder Mega168 + 8MHz-Quarz und setzt das
Fusebit für die interne Taktteilung durch 8. Das ist die günstigste
Lösung.
Und das mit dem UART dürfte schon noch in den Mega8/Mega88 passen,
immerhin ist ja noch mehr als 1kB frei.
Noch was zu der UART-Sache:
Um mit der aktuellen Hardware 100% kompatibel zu bleiben, könnte man
auch einen Software-UART verwenden. Als "TxD" könnte dann der Pin PC3
oder PC4 dienen.
Das hat auch noch den Vorteil, dass man sich mit einem etwas
"schmutzigen Trick" einige Bauteile einsparen kann:
Alles invertiert senden und den "TxD" direkt mit dem RxD der
RS232-Schnittstelle verbinden. Gemäß Spezifikation ist das nicht
zulässig (man hat damit nur 0V/5V-Pegel), aber es funktioniert in fast
allen Fällen.
Man spart sich damit eben den MAX232.
Natürlich wäre das aber nur optional, es würde auch eine Version für
einen Pegelwandler wie den MAX232 geben.
Einfach nur geil !
Habe diese Projekt länger beäugelt und bei der letzten
Bauteil-Bestellung einfach mal eingeplant. Es ist ein tolles Projekt,
und so ein Messgerät hat noch in der Bastelkiste gefehlt.
Vielen herzlichen Dank !
Peter
So Habe das Teil jetzt mal gelötet(Board vom Armin Diehl),warte noch auf
das Display.Allerdings ist das Mit dem Programmieren von dem Atmega
einfach zu hoch für mich.(Mir fehlen da zu viele Gehirnwindungen)Ich hab
mir von Videocafe den programmer gebaut(si prog i/o)
Dann aber rausgekriegt das das Ding wohl nur mit Pony-prog läuft,wofür
es einige Beschreibungen im Netz gibt.Mir aber alles zu
kompliziert,zumal man mit dem Teil den chip zerschiessen kann.Obendreien
sind da im Verzeichnis Firmware einige files mit bin.eep und welche mit
.eep ich würde also erst das Transistortester.Hex laden und Brennen und
dann das German.eep.ich hab mal in das Ponyprog reingeschaut aber nix
von fusebits gesehen da muss ja au noch was eingestellt werden.Kann mir
jemand sagen "Was" und Wo ich des einstellen mus
Übrigens haben die mir 3 Atmega 8-16 geschickt,kann ich die auch
verwenden,oder brauchts da andere files?
LG
Hallo Mc Gill,
hast Du den Videocafe Programmer schon getestet? Wird der ATmega im Pony
Prog erkannt? Ich glaube nicht, dass Du den Atmega mit dem Programmer
zerschießt, wenn Du alles nach der Anleitung gemacht hast. Wegen der
Fusebits
schau mal bei http://www.engbedded.com/fusecalc/ rein. Als erstes den
ATmega8 auswählen und in der folgenden Seite ganz unten bei Current
settings die beiden Hexwerte eingeben, die in der Fusebits.txt der
AVR-Transistortester.zip angegeben sind. Dann auf Apply values clicken
und die einstellungen werden in den oberen Fenstern der Seite angezeigt.
Bei Ponyprog kannst Du die Hexfiles hintereinander in den ATmega
programmieren.
Also mit "Open Data Memory(EEProm)File" und "Open Program
Memory(Flash)File".
Kaputt geht da so schnell nix. Außerdem wird der Prozessor auf Deinem
Programmer extern Getaktet. Den ATmega8-16 kannst Du auch langsamer
Takten. In diesem Fall intern mit 1 MHz. Geht alles. Warte bis Dein
Display da ist und dann Programmier mal. Wird schon werden. Am Anfang
fand ich auch alles verwirrend. Aber das gibt sich, wenn Du Dich im Netz
ein wenig umschaust, findest Du überall hilfreiche Tips. Also dann mal
los...
Viele Grüße
Yogi
Jo vielen Dank yogi.Werd erstmal warten bis das Displ.da ist .Hab mir
von der selben Seite auch noch das Atmega Testboard gebastelt.Dachte zum
rumprobieren.Ist das denn so ,das der extern getaktet wird?Da ist ja nur
´n Quarz drauf,kein Q.oszill.Hab gerad gelesen,daß wenn mann was
versemmelt hat,mit ner ext Taktquelle wieder alles richten kann.Also
kann ich ja mal rumprobieren werd dann mal berichten wie´s ausgegangen
ist
Schönes rest WE
=> Mc Gill:
Im Prinzip musst du an den Fuses nix ändern. Man könnte damit den Start
noch um 64ms beschleunigen (durch Ändern der Start-Up-Time), aber mit
der Werkseinstellung der Fuses funktioniert es auch.
> hab gerad gelesen,daß wenn mann wasversemmelt hat, mit ner ext Taktquelle> wieder alles richten kann
Jain. Wenn man die Takt-Fuses ändert stimmt das.
Allerdings haben viele AVRs (der ATMega8 auch) ein Fusebit, mit dem man
den RESET-Pin deaktivieren kann und ihn somit als normalen I/O-Pin
nutzen kann.
Setzt man dieses Fusebit, kann man den Controller nur noch über einen
Bootloader oder einen HV-Programmer programmieren. Mit den üblichen
ISP-Programmern geht dann nix mehr.
So hab gelesen,daß das stzen der fuse bits(=security+configuration
bits?)
invertiert gesetzt werden bei pony prog.Also überall hacken rein und bei
den relevanten Bits Hacken raus?Hab mal´n Bild angehängt.
Oben:"das kam bei engbeddet raus"
Unten:"so will ich es einstellen"
Könn´t ich des also so braten? Oder soll ich erstmal alles so lassen
wie´s ist also alle Hacken draussen?Außerdem gibt´s da bei spien ´n
problem da ist bei ponyprog ´n Hacken der sich net verstellen
lässt(Grau)aber entfernt werden soll?
Ich stell mich ziemlich blöde an,tut mir echt leid,wenn die Dinger
billiger währen,würd ich ne Hand voll bestellen und so lange
rumprobieren,bis es klappt ;-)
LG
=> Mc Gill:
Nö, ist leider verkehrt. Du musst die Hacken bei Ponyprog nach dem
oberen Bild setzten. Ich habe das bei meinen Transistortester ebenso
gemacht. Also nach dem engbedded. Lies doch die Fuses von Deinem Atmega
erstmal aus. Wahrscheinlich ist es so wie Markus schon schrieb. Du
brauchst nichts ändern. Programmiere die Flash Datei und EEProm Datei in
Deinen ATmega und lass die Fuses wie sie sind. Wenn Dein Display da ist
wirst Du schon sehen das es läuft.
Viele Grüße
Yogi
So hab jetzt mal ´n atmega8-16 gebraten :-) An den fuses hab ich nix
geändert.Morgen wird das display kommen,leider fehlt mir noch der
7805.Hab nur To220,da is wenig Platz aus dem Board,aber spätestens
samstag weis ich ob´s geklappt hat.Also erstmal Danke für die Info´s
LG
So.Hat alles geklappt.leider war das Displ für
Neg.Kontrastspannung,sodaß ich 2 Batterien reinmachen musste,aber mit
dem Atmega funzt alles prima.Dolles gerät.Kompliment
LG
Here is the version with the Czech lamguage included.
Marian wrote:
> Hello I have serious interest and I want to buy it as construction kit> with newest software please.
As far as I know, there is no complete kit available. You can get the
circuit board (and the other components) from the German shop IT-WNS,
but I think the shipping to England will be expensive...
Thanks
Markus F. schrieb:
> Here is the version with the Czech lamguage included.
but when i write device with TransistorTestNew.hex and
TransistorTestNew_Czech.eep so tester will show wrong messages on
display.
In czech it must show zadna neznama vadna soucastka but show only
na.aoucastka. Same in english version.
With your german version it's OK.
Please advice me with programming. It's my programming ok with
TransistorTestNew.hex and TransistorTestNew_Czech.eep ?
What is TransistorTestNew_Czech_Binary.eep file?
Thanks
btw. your tester is really great!
Zdenek schrieb:
> Thanks>> Markus F. schrieb:>> Here is the version with the Czech lamguage included.>> but when i write device with TransistorTestNew.hex and> TransistorTestNew_Czech.eep so tester will show wrong messages on> display.> In czech it must show zadna neznama vadna soucastka but show only> na.aoucastka. Same in english version.> With your german version it's OK.> Please advice me with programming. It's my programming ok with> TransistorTestNew.hex and TransistorTestNew_Czech.eep ?> What is TransistorTestNew_Czech_Binary.eep file?> Thanks>> btw. your tester is really great!
Same problem English, czech working not good- german is ok
btw. your tester is really great!
Tolles Projekt hier.
Beim Nachbauen ist mir aufgefallen, daß die Batteriespannungsmessung so
nicht
ganz richtig sein kann. Beim ATmega48 und ATmega88 ist die interne
Referenzspannung nur 1.1V. Dafür ist dann auch der Spannungsteiler
falsch
dimensioniert. Den R11 kann man z.B. auf 27k ändern.
Meinen Änderungsvorschlag habe ich mal hier angehängt.
Wenn jetzt noch meine bestellten Bauteile endlich da wären...
Mc Gill schrieb:
> So.Hat alles geklappt.leider war das Displ für> Neg.Kontrastspannung,sodaß ich 2 Batterien reinmachen musste,aber mit> dem Atmega funzt alles prima.Dolles gerät.Kompliment> LG
Hallo,
ich hatte auch ein Display "erwischt", welches eine negative
Kontrast-Spannung braucht. Diese lasse ich mir vom ATMEGA erzeugen,
schau mal nach meinen Beiträgen vom August-September letzten Jahres.
HTH
I have a new version:
Now, all languages should work (before, all lamguages except German
didn't work properly).
And I added a software UART that sends all the test results. It sends
almost the same data as shown on the LCD, except the characters which
are not implemented in the standard ASCII character set (for example the
"Omega" sign).
The UART output is PC3 (Pin 26 of the ATMega8).
The properties of the UART:
2400 baud
8 data bits
1 stop bit
no parity, no handshake
The internal timing error of the UART is almost zero.
So, the RC oscillator of the ATMega8 may have up to +/-3% tolerance to
get a stable connection. And according to the datasheet, the oscillator
has a 3% tolerance at 5V , 25°C and 1.0MHz.
So, it should work in most cases.
And there are two hex files:
In one("TransistorTestNew_UART_not_inverted.hex), the UART sends in
"normal" mode, to connect it to a TTL level RS232 receiver or to a level
shifter like MAX232.
In the other file ("TransistorTestNew.hex"), the UART sends in inverted
mode, for direcly connecting it to the RxD pin of a PC's RS232 port or a
USB=>serial converter with a "normal" PC-level input/output.
This makes the level shifter obsolete.
This solution is a bit "dirty" because a logical one is just 0V, and
according the RS232 standard it should be between -3V and -15V.
But in most cases, it works without problems.
Zdenek schrieb:
> Hi.>> Sorry but looks like the problem with text is still here. Czech, slovak>> and english version is not working. Only german language is ok.
Yes, already tested only German works :(
Markus F. schrieb:
> I have a new version:> Now, all languages should work (before, all lamguages except German> didn't work properly).
Ins Archiv gehen diese Neuerungen nicht mehr, wie ich sehe...
Now, all languages should really work...
The problem was not difficult, but I simply forgot that this will cause
errors:
In the different languages, the strings for the LCD have different
lengths and so also different starting positions.
But the hex file doesn't know that because there is only one hex file
for all 5 languages.
Now, I added "waste" characters to some strings, to get them all to the
same length. These characters are the "€" symbol (ASCII 0x80).
These characters are then filtered out before sending the data to the
LCD.
Now, every .eep file contains 350 bytes of EEPROM data and all strings
have the same lengths.
At least in my tests this works without problems for all languages.
I also added it in the SVN again.
Hallo!
Ich finde diesen Transistor Tester suuper und möcht ihn unbedingt
nachbeuen, aber ich hätte mal ne ganz banale Frage und hoffe ihr könnt
mir helfen.
Ich habe mir bei Pollin dieses LCD-Display gekauft: LCD-Modul C0802-04;
Bestellnummer: 120 622. Nun hat dieses aber nur einen 4Bit-Bus zur
Ansteuerung. Und hier ist diese Schaltung für ein 8Bit-Bus LCD
ausgelegt.
Wäre es eine grosse Sache das Programm für so ein 4Bit-LCD
umzuschreiben, wenn nein könnte das vielleicht jemand für mich machen.
Ich verstehe leider noch kein C (bin selber gerade Assembler am
erlernen).
Vielen Dank im Voraus
Gruss
Michi
A du hast natürlich Recht!!!
Ich habe mir den Schaltplan nur mal so flüchtig angesehen.
In diesem Fall freue ich mich dass ich diesen Tester jetzt demnächst
bauen kann!!
Vielen Dank
Michi
Hallo,
zunächst vielen dank Markus F. für deinen super Tester.
ich habe 2 Probleme mit dem Teil festgestellt:
1. Bei Kurzschluß wird unbek. Bauteil angezeigt.
2. Bei antiparallel geschalteten Dioden wird ein Widerstand angezeigt.
Gruß
Stefan
P.S.: Anbei Foto von meinem Tester
Hallo
Der Tester ist wirklich genial.
Ich habe für einige Funkfreunde, die nichts mit Programmieren und µC am
Hut haben, aber doch eifrig basteln, einen kleinen Bausatz
zusammengestellt und den Kontroller programmiert.
Das Ding hat bis jetzt ungeteilte Begeisterung ausgelöst. Auf diesem Weg
von allen Nutzern ein herzliches Danke an Markus F.
Das Gehäuse ist 100 x 80 x 25
Grüsse Hubert
Habe mich nun auch dazu durchgerungen so ein Teil zu bauen. Klappt ganz
gut. Bei meinem bisherigen "Platinchen" (seinerzeit als Bausatz bei
Conrad erworben) muß man wissen, welcher Anschluß B,C und E ist. Danke
für dieses Projekt!
Markus F. schrieb:> Now, I added "waste" characters to some strings, to get them all to the> same length. These characters are the "€" symbol (ASCII 0x80).> These characters are then filtered out before sending the data to the> LCD.> Now, every .eep file contains 350 bytes of EEPROM data and all strings> have the same lengths.
Das hätte man aber auch viel einfacher hingekriegt, mit einem Define,
wie lang die Strings sein sollen, was man dann einfach in der Array
Deklaration mit angegeben hätte. So ist das aber ganz schön umständlich
oder nicht?
> Das hätte man aber auch viel einfacher hingekriegt, mit einem Define> wie lang die Strings sein sollen, was man dann einfach in der Array> Deklaration mit angegeben hätte.
Das habe ich auch gedacht, nur leider landen Defines im Flash, was
bedeuten würde, dass man für jede Sprache eine eigene Flash (.hex)-Datei
brauchen würde.
Wäre ja auch zu schön...
Man könnte höchstens am Anfang des EEPROM eine Tabelle anlegen, in der
die String-Längen stehen. Diese werden dann beim Programmstart
ausgelesen.
Das wäre eleganter, kostet aber vermutlich viel mehr Flash als meine
"Lösung".
Hallo Markus F.,
ich bin so begeistert von dem Projekt, dass ich es mit Boards von myAVR
(www.myAVR.de) aufgebaut habe. Leider sind die PINs für das LCD-Modul
anders beschaltete, so dass ich Deine Software an die Gegebenheiten
angepassen musste. Nun meine Frage: gibt es von Deiner Seite Einwände
oder Vorgaben zur Veröffentlichung des Projektes im dortigen Forum?
Gruß Bernd
hallo,
bin gerade dabei den transistortester nachzubauen,könnte mir jemand
sagen wie die einschaltung funktioniert und auch die led will nicht so
richtig leuchten. ist der 27k widerstand zu groß oder wird die led nur
als referenz benötigt???
vielen dank im vorraus!!!
Schau Dir mal im Artikel AVR-Transistortester den Abschnitt mit der
automatischen Abschaltung an. Da steht, warum dier LED drin ist. Und ja,
sie ist nicht zum Leuchten da :-)
Hallo Markus,
interessant wäre auch ein automatischer Kennlinienschreiber mittels
Mikrocontroller, DAC für die Erzeugung der Basis (bzw. Gate) -Spannung,
ADC für das Einlesen des als Spannungsabfall gemessenen Kollektor
(Drain)-Stromes.
Damit könnte man Transistoren bzw. Fets selektieren.
Ich habe so ein Projekt vor.
Gruß Thomas
Ja, so ein Kennlinienschreiber wäre wirklich interessant.
Um die Kennlinie von Transistoren zu ermitteln bringt allerdings ein
reiner DAC für die Basisspannung nicht viel.
Entscheidend ist ja meist das Verhältnis zwischen Basis- und
Kollektorstrom.
Die Basisspannung ist natürlich auch noch wichtig, wenn man z.B. 2
praktisch identische Transistoren selektieren will, z.B. für einen
Differenzverstärker.
Man könnte z.B. an den DAC eine Pufferstufe anschließen, daran kommt
dann ein Widerstand, der zur Basis führt.
Die Basis-Spannung kann man per ADC messen.
Aus Basis-Spannung, dem Basis-Vorwiderstand und der DAC-Ausgangsspannung
kann man dann den Basisstrom berechnen.
Am besten baut man verschiedene Widerstände ein, um Basisströme von so
10µA...50mA einigermaßen präzise einstellen zu können.
Für den Kollektorstrom sollten auch verschiedene Widerstände vorhanden
sein, um verschiedene Strombereiche zu haben.
Für kleine Transistoren sind einige 100µA bis ca. 100mA sinnvoll. Wenn
man mal Leistungstransistoren (z.B. 2N3055 oder Power-MOSFETs)
selektieren will, wäre auch noch ein hoher Strom von vielleicht 1...2
Ampere wünschenswert. Diese Strom-Einstellungg sollte aber per Jumper
o.ä. zuverlässig deaktivierbar sein, um nicht versehentlich 2 Ampere
über einen BC547 o.ä. zu jagen...
Den fließnenden Kollektorstrom kann man einfach berechnen, indem man per
ADC den Spannungsabfall am Kollektor-Vorwiderstand misst.
=> eku:
Germanium-Dioden lassen sich damit testen, zumindest hat es bei mir mit
3 verschiedenen Typen funktioniert.
Ob Germanium-Transistoren gehen weiß ich nicht.
Das Problem könnte sein, dass sie einen recht hohen Leckstrom haben und
damit evtl. als JFET o.ä. erkannt werden.
Getestet habe ich es aber nicht, weil ich keine Germanium-Transistoren
habe.
Hallo Markus!
Markus F. schrieb:> => eku:>> Germanium-Dioden lassen sich damit testen, zumindest hat es bei mir mit>> 3 verschiedenen Typen funktioniert.>> Ob Germanium-Transistoren gehen weiß ich nicht.>> Das Problem könnte sein, dass sie einen recht hohen Leckstrom haben und>> damit evtl. als JFET o.ä. erkannt werden.>> Getestet habe ich es aber nicht, weil ich keine Germanium-Transistoren>> habe.
So, nun habe ich letztes Wochende Schaltplan, Leiterplatte und Sourcdode
überarbeitet und mir einen Transistortester gebaut. Ich verwende die
UART des ATmega8 und eigene LCD-Routinen. So konnte ich das Layout auf
einfachste Leiterführung optimieren. Den Rest macht dann die Software.
Darf eigentlich jeder im SVN des Projektes Dateien ablegen? Würde gerne
meine Version der Allgemeinheit zur Verfügung stellen.
Dei Tests mit den Germanium-Halbleitern mache ich nächstes Wochenende
und werde die Ergebnisse hier veröffentlichen.
eku schrieb:> So, nun habe ich letztes Wochende Schaltplan, Leiterplatte und Sourcdode> überarbeitet und mir einen Transistortester gebaut. Ich verwende die> UART des ATmega8 und eigene LCD-Routinen. So konnte ich das Layout auf> einfachste Leiterführung optimieren.
Einfachste Leiterführung ist immer ein gutes Argument.
> Den Rest macht dann die Software.>> Darf eigentlich jeder im SVN des Projektes Dateien ablegen? Würde gerne> meine Version der Allgemeinheit zur Verfügung stellen.
Was spricht dagegen, Deine Variante (auch) hier zu veröffentlichen?
Guten Tag,
ich habe 2 Fragen:
1. Habe ganzen Thread gelesen aber nicht gefunden: wenn ich ATMega88
verwende, soll die Firmware geändert werden (interne Referenzspannung
bei M88 ist kleiner).
2. Markus-F, darf ich diese Projekt auf meine Internetseite (auf
russisch) veröffentlichen?
MfG aus Westerwald
Dimi schrieb:> 1. Habe ganzen Thread gelesen aber nicht gefunden: wenn ich ATMega88> verwende, soll die Firmware geändert werden (interne Referenzspannung> bei M88 ist kleiner).
Firmware ändern reicht nicht. Dazu habe ich hier was geschrieben:
Beitrag "Re: Transistortester mit AVR"
Dimi schreib:
> ich habe 2 Fragen:> 1. Habe ganzen Thread gelesen aber nicht gefunden: wenn ich ATMega88> verwende, soll die Firmware geändert werden (interne Referenzspannung> bei M88 ist kleiner).
Am einfachsten ist es, die Firmware nicht zu ändern und stattdessen für
R11 einen 27k-Widerstand einzusetzen.
> 2. Markus-F, darf ich diese Projekt auf meine Internetseite (auf> russisch) veröffentlichen?
Ja, gerne!
Kluchscheißender Kluchscheißer schrieb:>> Was spricht dagegen, Deine Variante (auch) hier zu veröffentlichen?
Hier schon mal meine Schaltung und die Platine. Als Anzeige kommt ein
LCD 16x2 von Pollin (tc1602e-01, VCC-GND vertauscht) zu Einsatz. Die
Hintergrundbeleuchtung liegt nicht auf dem Pfostenverbinder, daher die
Lötaugen am oberne Ende der Platine.
Markus F. schrieb:> Germanium-Dioden lassen sich damit testen, zumindest hat es bei mir mit> 3 verschiedenen Typen funktioniert.
Konnte ich nachstellen. Funktioniert.
> Ob Germanium-Transistoren gehen weiß ich nicht.> Das Problem könnte sein, dass sie einen recht hohen Leckstrom haben und> damit evtl. als JFET o.ä. erkannt werden.
Genau so ist es, wenn auch nicht bei allen Typen aus meiner Bastelkiste.
Hat jemand eine Idee, mit welchem Testalgorithmus dies herausfinden
könnte? Ein bisschen Platz ist ja noch im Flash.
Und da kommt gleich die nächste Frage. Wie geht man bei Transistoren mit
4 Anschlüssen vor? Ich weiß nur noch, dass es Dual-Gate-Fets sind.
Hallo,
Ich habe den Transistortester aufgebaut, und wen ich einen Transistor
teste dan zeigt das Display ´´Bauteil unbek. oder Defekt´´.
Bitte um Hilfe
Hallo zusammen,
ich habe mir heute den Transistortester von Markus gebaut. Leider habe
ich ein Problem. Das Display zeigt Müll an, z.B. nach dem Einschalten
kommt: Test läuft, dann wird gelöscht und mit angeklemmten Transistor
erscheint: =2=13
in der Zeile 2 steht dann: =223 770m
Es deutet sich ein Problem mit dem eep.file an. Ich habe die Files in
Bascom geladen und damit programmiert. Hat jemand ähnliches schon mal
gehabt? Ich habe schon stundenlang gegoogelt, aber ich bin noch nicht so
richtig schlau geworden, wie das epp.file erzeugt wird. Den Sourcecode
in c kann ich mangels know how nicht compilieren. Habe die Files aus dem
SVN geholt.
Hallo noch mal,
kann mir vielleicht jemand das epp.file ins Intel-Hex-Format umwandeln?
Das sollte sich beim compilieren einstellen lassen. Das könnte für mich
ein neuer Lösungsansatz sein. Danke im voraus.
Hallo zusammen,
auch von mir ein dickes Lob an Markus. Tolles Projekt!!
Seit einigen Wochen - wenn nicht sogar Monaten - spiele ich mit dem
Gedanken, das Teil nachzubauen. Nachdem mein Messgerät jetzt langsam den
Geist aufgibt und das neue keinen Transistortester mehr hat, habe ich
mich jetz doch mal drangesetzt.
Hauptproblem war - wie immer - ein passendes Gehäuse zu finden, dass
nicht zu groß ist. Als ich dann bei Pollin die kleinen LCDs gesehen
habe, konnte ich endlich loslegen :-)
Für den Fall, dass es jemand nachbauen will: Im Anhang findet Ihr alle
benötigten Dateien für die Platine. Wer will, kann sich gerne noch was
mit der Target-Datei spielen; ich habe einige Brücken drin, die mir
selbst nicht gefallen, aber am Ende doch egal waren (wollte das Teil
endlich fertig haben :-)) Ich wollte halt unbedingt die Belegung der
Anschlüsse
beibehalten, damit man die SW nicht umschreiben muss.
Die Stückliste, wo welche Teile herkommen (außer dem normalen
Kleinzeug), ist auch dabei.
Für diejenigen, die jetzt nicht mit Target 3001 arbeiten, das Layout
aber trotzdem umgestalten wollen... Unter:
http://www.target-3001.de/target/v14/deutsch/tarv14viewer_d.exe
und
http://www.target-3001.de/target/v14/deutsch/discover/target3001_discoverd_v14.exe
gibt es kostenlose Viewer, bzw. "Einsteigerversionen"; aber die kennt ja
vermutlich schon jeder :-)
Für diejenigen, die es nur nachbauen wollen, sind entsprechende PDFs mit
dabei.
Also nochmals: Markus, vielen Dank. Bin echt begeistert; das Teil
funktioniert einwandfrei :-)
Steyr CVT schrieb:
> Hallo,> Ich habe den Transistortester aufgebaut, und wen ich einen Transistor> teste dan zeigt das Display ´´Bauteil unbek. oder Defekt´´.
Vielleicht sind die Widerstände (die 680 Ohm und 470kOhm) irgendwie
nicht korrekt angeschlossen, oder die Leitungen von den Test-Anschlüssen
zu den ADCs sind unterbrochen oder vertauscht.
Jedenfalls dürfte der Fehler irgendwo bei diesen Widerständen oder bei
den ADCs liegen. Die Betriebsspannung scheint ja ok zu sein, die
Firmware und das LCD auch.
be-cool schrieb:
> kann mir vielleicht jemand das epp.file ins Intel-Hex-Format umwandeln?
Das Format ist Intel Hex, nur die Datei-Erweiterung ist "eep".
Wenn du willst, kannst du die aber einfach in "hex" ändern. Vielleicht
kommt Bascom ja mit der Erweiterung ".eep" nicht klar.
An alle:
Vielen Dank für das viele Lob und die Verbesserungsvorschläge an diesem
Projekt. Ich hätte wirklich nicht erwartet, dass dieses Projekt so eine
Begeisterung auslöst ;)
Markus, danke für die schnelle Antwort. Werde es heute nach Feierabend
noch mal probieren.
Ist übrigens 'ne gute Leistung von Dir. Programmieren können ja viele
hier im Forum, aber die ganzen technischen Zusammenhänge zu
implementieren ist schon was ganz besonderes.
Danke für dieses Projekt
Ich bin es noch mal, jetzt funktioniert alles (siehe Bild). Der
Knackpunkt war, das Bascom zwar eep-Dateien brennt, aber es wird
irgendwas gebrannt und dann auch noch mit "verified ok" bezeichnet. Das
LCD zeigte dadurch nur Müll. Nachdem ich die Datei in .hex umbenannt
habe und neu gebrannt habe funktionierte alles richtig gut. Ist
vielleicht ein Tipp für alle die Probleme beim Brennen haben. Gibt ja
bestimmt noch ein paar mehr Leute, die Bascom verwenden.
Ja ich zum Beispiel, hatte unter Bascom den gleichen Fehler. Danke für
den Tipp be-cool, darauf wäre ich nicht gekommen. Ansosnten ein super
Projekt, da muss man ja zum Lötkolben greife! An dieser Stelle mein Dank
an Markus.
Hallo,
ich habe jetz mochmal alles überprüft und keinen Fehler gefunden.
Aber wen ich dei eep Datei Brenne kommt eine Fehlermeldung kan das
Proplem auch daran liegen ?
Ich habe das Teil nachgebaut und bin total begeistert. Riesen Dank an
Marcus F.. Ich habe so glaube ich einen kleinen Bug gefunden. Bei der
Widerstandsmessung mit einem 15 Ohm Widerstand werden bei mir 156 Ohm
angezeigt. Vieleicht habe ich auch nur eine etwas ältere Firmware
erwischt. (12.04.10 glaub ich)
Weiterhin hab ich noch eine Frage: Bis zu welcher Kapazität kann man
Elko´s relativ genau messen?
Macht alle bitte weiter so an dem schon fast genialen Projekt.
Danke olli
@olli:
Also ich habe eben einen 15Ohm gemessen und bekomme auch überall (1-2,
2-3, 1-3) 15 Ohm angezeigt. Meine FW habe ich am 22.5.2010 hier im
Artikel runtergeladen; Deine (12.04.) ist jetzt aber auch nicht gerade
alt...
Was für Messwiderstände (R1-R6) benutzt Du denn? Vielleicht passen die
nicht genau? Ich arbeite mit 1%-Teilen; wenn Du jetzt normale
Kohleschicht mit 10 oder gar 20 % hast, dürfte das eher daran liegen...
danke für die schnelle Antwort. Klingt logisch.Ich werde die Widerstände
am Wochenende mal wechseln. Mich hat nur stutzig gemacht, das der
Transistortester 156 Ohm anzeigt und mein Fluke-Multimeter 15,6 Ohm.
Hi Markus,
I made this tester, but i have a problem with the programation of the
atmega8, i use PONYPROG and i can't program the eeprom file in the
divice??.
I need olso to know how to set the configuration bits in PONYPROG.
A screenshot for this can help me.
Thanks a lot
Jamal
Hello.
I know this problem. Show this:
Ich habe das jetzt so gelöst: Nach verschiedenen Versuchen habe ich
mitbekommen, dass bei Ponyprog das EEPROM ab Adresse 2000 beginnt. Ich
habe mit einem Editor die *.eep-Datei einfach in die *.hex-Datei dorthin
geschrieben und jetzt bin ich glücklicher Besitzer des
Transistortesters. Vielen Dank für die Hilfe.
Beitrag "Re: Transistortester mit AVR"
No need, I found the solution in PONYPROG!
Just upload the flash file and then upload the eeprom file, wich appears
on the PONYPROG interface after the flash file from line 2000.
In the command menu use: WRITE ALL.
That's all and it's working very fine!
Thanks,
Jamal
Ich möchte mir das Teil auch aufbauen. Kennt Ihr eine Möglichkeit die
Eagledateien in Sprintlayout-Dateien umzuwandeln? Oder hat jemand von
euch evtl. ein Platinenlayout für den Tester mit Sprint-Layout entworfen
und könnte es hier rein stellen?
Ich komme leider nicht mit eagle klar und möchte das Layout für das LCD
Modul 1602A abändern.
Hallo!
Ich habe mir das Programm auf mein Atmega8-Board geladen, das läuft
allerdings mit 8 MHz. Ich habe das Programm mit dem define F_CPU=8000000
kompiliert, dann geht das LCD-Display, und ich kann messen. NPN wird
beispielsweise erkannt. Allerdings werden Kapazitäten ca. mit dem Faktor
8-10 gemessen, und statt Widerständen erkennt das Programm eine winzig
kleine Kapazität.
Ich habe den Thread durchsucht, dazu aber nichts gefunden, daher die
Frage: Geht das Programm auch mit 8 MHz, oder gibt es irgendwo
Zeitschleifen, die anzupassen sind. Oder ist das Programm einfach auf 1
MHz ausgelegt?
Danke für die Antwort!
Erwin Unger schrieb:> Geht das Programm auch mit 8 MHz, oder gibt es irgendwo> Zeitschleifen, die anzupassen sind. Oder ist das Programm einfach auf 1> MHz ausgelegt?
Überall wo in main.c der Text "Schleife dauert 7 Zyklen" steht, ist
diese Schleife für 1MHz berechnet. Daher der Messfehler bei 8MHz.
Kluchscheißender Consulter schrieb:> Ist es denn wirklich sooooo viel Aufwand, den Mega8 für dieses Projekt> mit 1 MHz (auslieferungszustand) laufen zu lassen?
Nein natürlich nicht. Da ich nur auch die delay-Funktion gefunden habe
(da ja das define korrekt auswertet), war ich einfach nur nicht sicher,
ob es an der Taktfrequenz liegt, dass ich falsche Ergebnisse habe.
eku schrieb:> Überall wo in main.c der Text "Schleife dauert 7 Zyklen" steht, ist> diese Schleife für 1MHz berechnet. Daher der Messfehler bei 8MHz.
Habe mir die Schleifen angeschaut, die auf Auswertung des defines für
die Taktfrequenz umzustellen, ist nicht so einfach, sonst hätte ich
gerne da bei dem Projekt weitergeholfen, aber das traue ich mir nicht
zu.
In Summe: danke für die Antworten, werde den Tester mit 1 MHz aufbauen.
Finde das Projekt wirklich toll.
Danke für das Projekt. Habe den Tester auch aufgebaut. Nie war Messen so
einfach....
Für alle die ihn auch nachbauen wollen, stelle ich die Platine als PDF
und Sprintlayout mit ein.
Die Platine ist SMD-Frei.
Hi,
ich hab deinen Tester nachgebaut und ich muss sagen: Respekt!
Super einfach und zugleich noch wahnsinnig vielseitig.
Zwischen 2 und 3 misst meiner aber bei einer Diode einen Widerstand. Bei
anderen Kombinationen nicht. Ist das normal? Was hab ich falsch gemacht?
Mfg,
Flo
=> Eberl Florian:
Probiere es mal mit der aktuellsten Firmware
(http://www.mikrocontroller.net/attachment/75033/AVR-Transistortester.zip).
Die aus dem Artikel ist nämlich schon etwas älter, ich aktualisiere den
Artikel demnächst mal wieder.
Zumindest mit der neuesten Firmware sollte der Fehler bei der
Dioden-Erkennung nämlich nicht passieren. Falls doch, ist vermutlich
irgendwas an der Hardware nicht ok.
Hallo Markus,
was hältst Du von der Idee, beim Teststart in der zweiten Zeile - die ja
leer ist, wenn in der ersten "Test läuft..." steht - noch die
Versionsnummer und / oder Versiosdatum einzublenden?
Die von Dir eben beigefügte Datei war nämlich neuer als die bei mir
aufgespielte und so könnte man das noch vor einem Update leicht
überprüfen (Oh, Version x.y; und was habe ich drauf? Ah, Update :-))
Einen Binärvergleich der Hex-/EEP-Dateien kann man zwar leicht machen,
aber welche von beiden dann neuer ist, sieht man dann vermutlich auch
nicht.
Viele Grüße,
Michael.
Michael B. schrieb:
> was hältst Du von der Idee, beim Teststart in der zweiten Zeile - die ja> leer ist, wenn in der ersten "Test läuft..." steht - noch die> Versionsnummer und / oder Versiosdatum einzublenden?
Das ist eine gute Idee. Das werde ich einbauen, und dann den Artikel
auch wieder auf den "neuesten Stand" bringen.
Markus F. schrieb:> => Eberl Florian:> Probiere es mal mit der aktuellsten Firmware> (http://www.mikrocontroller.net/attachment/75033/AV...).> Die aus dem Artikel ist nämlich schon etwas älter, ich aktualisiere den> Artikel demnächst mal wieder.> Zumindest mit der neuesten Firmware sollte der Fehler bei der> Dioden-Erkennung nämlich nicht passieren. Falls doch, ist vermutlich> irgendwas an der Hardware nicht ok.
ok, danke. Das wars. Die Firmware hab ich mir natürlich direkt aus dem
Artikel gezogen.
Und meistens braucht man e nur wechselstrom. Warum werden Messgeräte für
Gleichstrom gebaut???? -> Währe die gleiche Frage
Germaniumtransistoren sind vor allem für Gitarreneffektgeräte sehr gern
verwendete Transistoren. Wenn man den Leckstrom vom HFE nicht
gegenrechnet, dann stimmt der HFE nicht. Über einem gewissen Leckstrom
sind die Transistoren gar nicht zu gebrauchen.
Ausserdem: Wenn man etwas altes herichten möchtet, dann bin ich mal
gespannt, wie du ein komplettes Germanium Design in Silizium umbauen
möchtest.
Hi :)
Ohne Studium des gesamten Threads und nur mit kleiner
Schaltplanübersicht mal frei heraus eine Frage:
Meine ganzen jetzigen und künftigen Messspielzeuge möchte ich via USB
versorgen, dem ganzen Kram mit Batterie hier, Netzteil da, hier ne
Buchse, da ne andere, dort ne neue Spannung, ..., kann ich nix
abgewinnen. Was spricht dagegen, den Transistortester rein auf 5V
Versorgungsspannung aufzubauen?
Laut Schaltplan hängt an den +9V ja der 7805 dran, der ohnehin 5V +- n
bisschen was an VCC des Atmegas gibt. Der Atmega 8L selbst läuft laut
Datenblatt mit 2,7...5,5V. Schonmal prima (bitte korrigieren, wenn ich
was übersehe!). PC5 schnappt sich über nen Spannungsteiler auch noch
grob 2,2V, das wäre mit 5V-Versorgung bei geänderten Widerständen auch
kein Problem. PC6 hängt über einen 10kOhm-Widerstand ohnehin an den 5V
des 7805. Das Display hängt ebenfalls daran.
...also sehe ich nirgendwo die Notwendigkeit auf 9V Versorgungsspannung
zu bauen. Ja? Nein?
Andererseits gabs gegen 21. Nov 09 mal die Bedenken, dass es eher 6V
sein sollten. Ist das "noch" aktuell, oder ist das ne Sache der
Belastbarkeit der Spannungsversorgung, die bei nem 2A-USB-Hub ja
sicherlich weniger das Problem ist?
Besten Dank :)
Hey Mathias B,
die ganze Schaltung läuft mit 5V. Damit der 7805 seine 5V stabil regeln
kann, braucht dieser ca +2-3V mehr. Also ca 7-8V Eingangsspannung.
Wenn du eh den 5V USB Hub als Stromversorgung nehmen willst, dann würde
ich alles rausschmeißen, was unnötig ist.
Der 7805, die "Einschalt"-beschaltung, den Spannungsteiler für die
Batterieversorgung etc. Dann noch im Quellcode alles anpassen und fertig
ist der USB-Transistortester. Die Abschaltautomatik würde ich auch aus
dem Quellcode werfen.
Wenn man den Spannungsteiler für die Batterie-Versorgung rausschmeißt,
dann muss auch der ADC-Pin (Pin 28) fest auf 5V gelegt werden.
Damit meint der Tester immer, die "Batterie" wäre voll. Sonst kann es
sein, dass der mit der Meldung "Batterie leer" gleich wieder abschaltet.
Ohne Spannungsregler und Abschalt-Automatik müsste der Tester auch mit
den 5V vom USB prima laufen.
Der einzige Nachteil ist, dass USB nicht wirklich exakt 5V liefert, es
können auch mal 5,7V oder 5,3V sein. Damit werden eben manche Messungen
(z.B. Dioden-Durchlassspannung) ungenauer. Meistens stört das aber
nicht.
Hi,
@Alex: Danke für die Doppelantwort :)
Ist natürlich klar, dass der 7805 dann weder läuft noch gebraucht wird.
Von der Schaltung bleibt da echt nicht mehr viel übrig...zwei Kondis,
neun Widerstände, der Atmega und das Display...
Alle Stromsparfeatures fliegen ebenso raus, warum auch hier und da ein
mW sparen bei Netzbetrieb.
@Markus: Geht klar. Spart auch wieder Bauteile und Platz g
Ich habs eben mal bei meinem Hub nachgemessen, und auch bei meinem
Laptop-Netzeil, das mir eigentlich meine RGB-Beleuchtung befeuert (das
bietet zwei Anschlüsse, einen davon kann man auch mit nem USB-Adapter
als 1A-Quelle nutzen).
Leerlaufspannung liegt beide Male bei etwa 5,2V, damit hatte ich bei der
Dimensionierung des Vorwiderstands für die Displaybeleuchtung schon als
obere Grenze gerechnet...untere war 4,8V.
Bei 0,4A Belastung sinken beide allerdings schon recht stark ab, das
Hubnetzteil gurkt noch bei 4,5V, das andere eher bei 4,3V rum. Bei
Belastung von etwas über nem Ampere geht dann auch das Hubnetzteil in
die Knie und hat noch 3,5V. Nun wird der Transistortester selbst mit
Displaybeleuchtung kaum in solche Regionen kommen (Imax sind dort afaik
220mA), aber wenn mal alles zusammen in Betrieb ist, sollte ich das
vielleicht bedenken. Oder mir noch ein extrastarkes USB-Netzteil bauen
;)
(vielleicht so als zusätzliche DC-DC-Einheit, das Lappinetzteil würde
90W bringen, die ich derzeit eh nicht mittels LEDs verbraten kann)
Wo könnte so die untere Schmerzgrenze liegen?
> Wo könnte so die untere Schmerzgrenze liegen?
Das hängt davon ab, wie genau die Messungen sein sollen...
Die Messung von allen Spannungen (also Dioden-Durchlassspannung und
Transistor-Schwellspannung) ist auf jeden Fall
betriebsspannungsabhängig:
Also wenn eine Diode 0,75V Flussspannung hat, dann zeigt der Tester ca.
1V Flussspannung an, wenn die Versorgungsspannung vom Tester 4V statt
der "korrekten" 5V ist.
Und manche Leistungs-MOSFETs brauchen zum Teil 4...5V Gatespannung, um
überhaupt etwas durchzuschalten und damit vom Tester erkannt zu werden.
Bipolar-Transistoren und Logik-Level-FETs müsste man aber auch mit
geringer Betriebsspannung noch problemlos erkennen können.
Das Problem ist eher, dass die meisten HD44780-LCDs unter ca. 4...4,5V
nicht mehr ablesbar sind, weil die Kontrastspannung zu niedrig wird.
Also das Display lässt sich problemlos weiterhin ansteuern (das geht
auch mit 3,3V noch), aber man sieht halt die angezeigten Zeichen nicht
mehr.
Das geht nur, wenn man an den Kontrastspannungs-Anschluss eine Spannung
anlegt, die etwas unter GND liegt (z.B. -2V). Eben so, dass das LCD gut
ablesbar ist.
Hallo allerseits,
durch einen Link im qrpforum.de (Amateurfunk) wurde ich auf diesen
Transistortester aufmerksam. Das wäre eine große Bereicherung meines
kleinen Messparks!
Ist auch der Atmega 8L8 DIP (Low Power?) hierfür geeignet?
Wenn ja, eine ganz bescheidene Frage: Könnte mir jemand diesen Atmega
8L8 programmieren? (Ich will nicht groß in die Atmegaprogrammierung
einsteigen) Ich möchte mir die vereinfachte Version - ohne automatische
Abschaltung - auf Lochrasterplatine aufbauen. Bei den wenigen Bauteilen
wohl kein Problem.
Gruß in die große Runde
Winfried
Hi,
@Markus: Flussspannungen ausmessen ist jetzt nicht so mein primäres
Interesse, ebenso Leistungsmosfets. Andererseits dürfte die Sache ja
tatsächlich mit einer belastbaren Stromquelle gelöst sein, wenns
wirklich mal hoch hergeht. Das ist momentan noch nicht der Fall, aber
ich werds mir merken.
Das mit dem Displaykontrast wird man ebenfalls ausprobieren müssen, da
ich bisher noch gar nicht mit Displays gearbeitet hab, und demnach auch
keine Vergleichswerte kenne (und auch keins zum Testen da hab!). Auch da
natürlich: Je stabiler man bei den 5V ist, desto problemloser. Ich sehs
schon, irgendwann kreuz ich hier auf und such nach ner Netzteillösung,
mit der man auch den kompletten Handypark einer mittelgroßen Firma
zeitgleich laden könnte ;D
@Winfried: Den Atmega 8L8 hatte ich auch vorgesehen, der müsste passen.
Kommt mit einem größeren Spannungsbereich aus als der 16er, taktet aber
eben auch nur mit bis zu 8 MHz. Hier kein Ding, da man den 16er wohl
ohnehin bremsen oder Veränderungen am Skript vornehmen müsste.
Was die Programmierung betrifft: Sofern du irgendwo noch auf einen
nativen Parallelport zugreifen kannst, kommt dich der einfachste
Programmer rein von den Bauteilkosten her auch kaum teurer als 1x Porto.
Solltest du einfach bedenken, aber wenn dus natürlich fertig haben
möchtest, wird sich wohl auch jemand dafür finden. Oder du nimmst die
Schorsch-Version.
Sollte jemand einen ATmega8A verwenden, dann nicht vergessen die
Faktoren für die Kapazitätsmessung anpassen. Bei mir waren die
notwendigen Werte weit neben den Standardwerten.
unsigned int H_CAPACITY_FACTOR EEMEM = 250;
unsigned int L_CAPACITY_FACTOR EEMEM = 172;
GermaniumFreak schrieb:> Leckstromberechnung währe wirklich eine Bereicherung dieses Projektes.
Dann bau' es doch bitte ein. Oder benutze die Messmittel, die zur
Germanium-Zeit aktuell waren.
MfG
P.S.: Ich gehe davon aus, dass Du den Leckstrom nicht berechnet,
sondern gemessen haben willst. ^^
In welcher Sprache soll ich es machen, es gibt:
/* Sprache
GERMAN = deutsch
ENGLISH = englisch
POLISH = polnisch
CZECH = tschechisch
SLOVAK = slowakisch
*/
Der Unterschied zwischen ATmega8 und ATmega8A ist nur in den "Electrical
Characteristics"
Aus diesem Grund müssen die Korrekturwerte für die Kapazitäts-Messung
unterschiedlich angepasst werden.
Hallo !
ich habe heute die Platinen aus dem Artikel
Beitrag "Re: Transistortester mit AVR"
erhalten und mache mich dann das WE ans aufbauen !
Bin mal gespannt, wie der "Transistortester mit AVR" läuft.
Bei Bedarf kann ich noch eine Platine abgeben, FR4, einseitig, chemisch
verzinnt.
Moin moin,
auch ich habe mir gestern die Zeit genommen den Tester einmal
aufzubauen. Bei der Suche nach einem passenden Display vielen mir diese
Mini-LCDs von Pollin in die Hände. Da ich auch schon einen RC5-Tester
gebaut habe, kam mir die Idee beide Tester in einem Gehäuse
unterzubringen.
Herausgekommen ist dann dieses kleine Gerät auf dem Bild. Ich habe
danach gleich angefangen die verschiedensten Bauteile durchzutesten. Bis
auf wenige Ausnahmen wurde jedes Bauteil korrekt erkannt, wobei ich
manchmal schon die Anschlüsse einmal durchtauschen musste, um ein
brauchbares Ergebnis zu bekommen.
Macht weiter so!
Profi schrieb:> Ist jetzt schon die Leckstrommessung mit drinnen,
Könntest Du vielleicht aufhören, unter verschiedenen Pseudonymen nach
Deiner Leckstrommessung zu quengeln? Du führst Dich auf wie ein Kind im
Supermarkt, das seinen Schokoriegel nicht bekommt.
Du hast den Source, bau's ein.
Hc Zimmerer schrieb:> Profi schrieb:>> Ist jetzt schon die Leckstrommessung mit drinnen,>> Könntest Du vielleicht aufhören, unter verschiedenen Pseudonymen nach> Deiner Leckstrommessung zu quengeln? Du führst Dich auf wie ein Kind im> Supermarkt, das seinen Schokoriegel nicht bekommt.>> Du hast den Source, bau's ein.
Vielleicht kann der ja garnicht programmieren. Schon mal daran gedacht?
Leckstrom währe wirklich nicht schlecht. Aber ob das ohne Referenz so
einfach möglich ist, möchte ich mal bezweifeln. Dazu müssten schon
mehrere Kalibrierwerte abgespeichert werden.