Transistortester mit AVR

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.

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.

:)

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.

Ist mir garnicht aufgefallen, das muss ich nochmal testen ;)

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

naja fast, ich benutze 168, aber vllt sollten die leute hier mal voten.

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.

=> microhead:
Have you tried it with the newest version from the SVN repository?
http://coremelt.net/files/software/repository-tarballs/semiconductor_tester.tar.gz

Markus F. schrieb:
> => microhead:
> Have you tried it with the newest version from the SVN repository?
> 
http://coremelt.net/files/software/repository-tarballs/semiconductor_tester.tar.gz

Was soll der Quatsch? - Dieses Forum hat Dein Projekt erst bekannt 
gemacht. Warum pflegst Du es nicht weiter in diesem Forum?

Beitrag "Re: Transistortester mit AVR"

Warum gehst Du fremd?

...

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

> 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).

http://viewvc.coremelt.net/viewvc/avr/semiconductor_tester/?view=log

Hier sind die Aenderungen, inkl. Dateilisten und diffs.

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

Brauchst es nicht zu verwenden.

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

> 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.

warum lasst ihr es nicht beim Transistortester. Muss es denn die 
"eierlegende Wollmilchsau" sein? Alles mögliche zu kombinieren ist noch 
nie geglückt.

Tja, Timo, das ist der Grund, weshalb ich es auch noch nicht aufgebaut 
habe. ;-)

...

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 ;-).

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.

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.

Cool, das mir auch schon aufgefallen, je nach Polung ;)

@Claudio
Have you verified the fusebits, flash and eeprom content?

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?

=>  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,
I can't log for SVN, I don't know why ?
Here is Transistor tester with 3 version, german, polish, and english.

Bei fast allen IGBTs ist eine Freilaufdiode miteingebaut.
Die Ströme und Spannungen sind Dekaden zu hoch für diesen Tester, das 
wird nichts.

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

Hello everybody,
I have finally build the tester, the photo attached show all...
on the right is the "homemade" TO-3 test socket

Thank You Markus!

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

i po Russki:
Теперь, есть три языка: немецкий, английский и польский язык.
Вы можете выбрать между языками, программируя передачу
Файл.eep в 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.

Ich bin einfach nur begeistert.
Grüße
Wolle

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.

=> 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

=> 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.

Markus F. schrieb:
> => Mc Gill:
> Im Prinzip musst du an den Fuses nix ändern.

Lass die Fuse-Bits lieber in Ruhe.

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...

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.

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

Ähm... wird doch bereits mit 4 Bit angesteuert...

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

Das Display, das Du Dir ausgesucht hast, hat aber nur 2 x 8 Zeichen.
Der Transistortester braucht aber 2 x 16 Zeichen.

Ups jawol dass stimmt dann werde ich mir wohl noch ein anderes LCD 
mitbestellen müssen.

Gruss

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

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

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 F.,

auch von mir vielen Dank für dieses tolle Projekt.
So etwas habe ich schon immer gesucht

Michael

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.

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?

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!

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 ;)

@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...

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"

Hi, Jamal,
I know my explanation was very short, but my English is poor. I'm glad, 
that it works now .
dolivo

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!

Ist es denn wirklich sooooo viel Aufwand, den Mega8 für dieses Projekt 
mit 1 MHz (auslieferungszustand) laufen zu lassen?

MfG

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.

maddin schrieb:
> ...sagt mal, ist es ungefähr das was dieses Teil hier kann?
>
> 
http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=D124;GROUPID=4024;ARTICLE=81766;START=0;SORT=artnr;OFFSET=16

Japp, schau mal hier:
http://www.mikrocontroller.net/articles/AVR-Transistortester#Links

=> 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.

DerTi schrieb:
> Dieser ist bei Germaniumtransistoren sehr sehr wichtig !!!

Nur Germaniumtransistoren sind heutzutage nicht mehr wichtig.

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 :)

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.

Wenn es dir aus Österreich nicht zu teuer ist.
Schau mal auf www.schorsch.at

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. ^^

Das sind meine Werte:
unsigned int H_CAPACITY_FACTOR EEMEM = 250;
unsigned int L_CAPACITY_FACTOR EEMEM = 172;

In welcher Sprache soll ich es machen, es gibt:
/*  Sprache
  GERMAN = deutsch
  ENGLISH = englisch
  POLISH = polnisch
  CZECH = tschechisch
  SLOVAK = slowakisch
*/

Version in English für ATmega8A

Es tut mir leid, ich habe die falschen Files gepackt.
Das sollten jetzt die richtigen sein.