Hier würde ich gerne Support für den RCT geben...
ja, so solle es auch hier sein.
ich wollte nur mit meinem geschreibsel sagen, einlöten würde ich die direkt nicht.
Allgemeine Diskussion über IC-Tester
-
Wenn aber slabbi das in seiner anleitung alles erklärt, dann ist es doch auch nicht sein problem
und ihr müsst nur seine anleitung durchlesen und selbst entscheiden ob es so ok ist.
ich werde mir mal, wenn ich ruhe habe, die anleitung auch durchlesen.
Kapitel 10, ab Seite 128
-
Kapitel 10, ab Seite 128
vielen dank, dann werde ich es mir später durchlesen.
mehr als 128 seiten? dann hast du ja eine menge wohl da erklärt.
mein motto war damals, meine anleitungen sollten auf zwei seiten passen
gruß
helmut
-
-
Ein 16MHz ATMega kann bestimmt so schnell zugreifen wie ein 1MHz System.
Da braucht es noch nicht mal Assembler.
In Assembler geht das noch deutlich höher, so man das will und braucht.
hallo Diddl
es geht ja nicht nur um rams und darum, ob ein atmega, ein ram selbst ansprechen kann,
das kann er ja auf jeden fall, denn er bestimmt ja selbst nur das timing.
es geht ja hier aber um einen bauteile tester.
und du hast viel mehr erfahrung, mit den atmegas als ich, mein stand mit denen ist ca. 20 alt.
als sie gerade herauskamen und zuletzt habe ich mich mit denen 2004 beschäftigt.
kannst du mir bitte erklären, wie du es, selbst mit assembler schaffen würdest,
mit 62,5 nS ein port zu setzen und dann noch abzufragen?
würdest du es auch viel langsammer mit 250 nS schaffen?
die ganzen daten über die ports ans dram anlegen
und dann alles mit den schnellsten routine, die je möglich sind, dann auch sofort abfragen?
da benötigt man doch ganz viele befehle, die hintereinander, mit den 62,5 nS, erstmal abgearbeitet werden müssen?
ich gehe mal davon aus, es hat sich nichts extremes bei den avrs, die letzten 20 jahre da geändert.
gruß
helmut
edit.......und was ist mit den um ca. faktor 20 schnelleren anderen und ganz normalen TTL ics?
-
kannst du mir bitte erklären, wie du es, selbst mit assembler schaffen würdest,
mit 62,5 nS ein port zu setzen und dann noch abzufragen?
Na klar gibt verschiedene IC Tester, von Perfekt bis brauchbar.
Perfekte Tester sind vermutlich kaum leistbar.
Die meisten von uns kommen mit einem einfachen Tester aus.
Wir müssen ja oft nicht die Qualität eines DRAM messen.
Meistens genügt es ja zu prüfen, ob jedes Bit im Speicher funktioniert.
Wenn ich irgendwo DRAM erwerbe, zB. bei eBay, dann will ich halt schnell raus finden ob das Ding überhaupt geht.
Bis jetzt war es immer so, wenn er prinzipiell funktioniert dann läuft er auch im C64.
Im übrigen ist der C64 selbst schon ein ganz passabler DRAM Tester ...
-
Im übrigen ist der C64 selbst schon ein ganz passabler DRAM Tester ...
ja, und viel besser als jeder anderer tester.
da kommt kein bauteiletester auf basis eines atmegas nie und nimmer mit.
ich behaupte sogar, die angeblich getesteten und defekten bauteile funktionieren sogar einwandfrei!
und das noch nicht mal selten!
also bauteile testen und dann als defekt aussortieren. die garnicht defekt sein können,
sondern nur ganz falsch, mit ganz falschen pegeln getestet wurden.
bitte sammelt die defekten bauteile, für mich und ich werde sie bei meinem retro und reparaturtreffen,
vom 16. bis 18. september, in euerem beisein gerne untersuchen.
gruß
helmut
-
Wir müssen ja oft nicht die Qualität eines DRAM messen.
das verstehe ich leider nicht, was ist das für ein testparameter bei den herstellern?
mein englisch ist sehr schlecht.
ich habe in den 50 jahren noch nie mitbekommen, das der hersteller noch seine bauteile
in verschiedene qualitätsgruppen unterscheidet?
es gibt unterschiedliche anwendungsgruppen, z,b, temperaturen und spannungs toleranzen,
aber von einer qualitäts unterscheidung habe ich wirklich nichts gehört.
edit.....
doch, es gab ddr und ostblock ics, die nicht die eigenen daten erfüllten,
so durften die nur z.b. für private anwendungen benutzt werden.
und wie kann man glauben, das ein ic, egal wie alt es ist, mit dem alter langsammer wird und es
laut hersteler auch darf?
dann ist es doch kaputt?
oder glaubt ihr, es gibt einen einzigen hersteller, auf der welt, der in seinen datenblättern schreibt,
das sich mit dem alter, die garantierten werte mit den jahren verschlechtern?
jeder hersteller wird sofort bestätigen, wenn z.b. sich sein timing verändert,
wenn es langsammer wird, dann stimmt doch etwas mit dem ic, aus irgeneinem grund was intern nicht
und es ist defekt.
so ist doch ein timingtest doch ein wichtiger test.
wir reparieren doch geräte, da muss man jetzt noch nach jahrzehnten das entsprechende timing einhalten,
genau so, wie es auch schon bei der produktion damals war.
stellt euch nur mal vor, die unterschiedlichen ics, in einem c64 würden anfangen,
ihr timing mit dem alter zu verändern. bitte, wer sollte da die geräte noch reparieren können?
sie fallen, aus irgendeinem grund aus, oft weil sie ihre parameter nicht mehr einhalten können.
und dann ist es doch hoffentlich klar, dann kann die schaltung nicht mehr korrekt funktionieren.
ein signal geht oft durch mehrere gatter und dann summiert sich die signallaufzeit,
die verzägerungszeit und am signal ausgang muss dann spätestens zu einer max. zeit,
das korrekte signal anliegen.
jetzt geht ein signal, nehmen wir an, durch 5 ics, und diese würden mit dem alter ihre laufzeiten verändern.
so hoffe ich, das es jeder verstehen kann, was ich sagen möchte, wer soll das alles bei einer
entwicklung auch noch einplanen? einen alters zeitfaktor?
gruß
helmut
-
in 62,5 ns etwas zu überwachen, zu vergleichen und zu überprüfen.
ich würde ganz klar sagen, das ist mit 16 MHz unmöglich.Naja mit 16MHz nicht.
Mit 16 MHz. und einem Hilfsmittel (CPLD, FPGA) schon.
Aber man muss ja nicht bei 16MHz bleiben.
Ein STM32 mit mehreren hundert MHz ...
... kostet auch nur ein paar Euros.
-
Mit 16 MHz. und einem Hilfsmittel (CPLD, FPGA) schon.
ja,
und die könnten die paar nS auch wirklich überwachen.ich hätte es etwas komplizierter mit den ttl ics gemacht, so wie ich es seit jahrzehnten gewohnt bin.
aber dann auch etwas preiswerter. aber nicht so flexiebel wie mit einem cpld oder fpga.
Aber man muss ja nicht bei 16MHz bleiben.
Ein STM32 mit mehreren hundert MHz ...
... kostet auch nur ein paar Euros.
ja, schneller geht immer.
ich bin von dem nun mal eingesetztem atmega ausgegangen.
kennst du dich mit der programmierung der atmegas aus?
gruß
helmut
-
kannst du mir bitte erklären, wie du es, selbst mit assembler schaffen würdest,
mit 62,5 nS ein port zu setzen und dann noch abzufragen?
Der ATMega2560 hat 86 IO-Ports. Ich vermute mal, das slabbi z.B. den Port A dazu verwendet, ein Bitmuster an den Chip an zu legen. Der Schreibbefehl, um Port A zu beschreiben, benötigt einen Takt , und Port B "Parallel" zu Port A geschaltet ist z.B. in etwa so:
Port A ----> 470 Ohm ----> Pin von zu testenden Chip ---> Port B (mal die Schutzmaßnahmen wie Z-Dioden & Co. außen vor)
dann kann einen Takt später der Pegel an Port B gelesen werden, um geprüft zu werden, der über Port A an den Chip gesendet wurde.
Der Assembler-Befehl "OUT P, Rr" benötigt laut Atmel-Datenblatt einen Takt, ebenso "IN Rd, P". Mit dieser "Konstruktion" ist es möglich in 62,5ns ein Ergebnis zu erhalten, wenn beide Befehle direkt hintereinander stehen...
-
Alles anzeigen
Der ATMega2560 hat 86 IO-Ports. Ich vermute mal, das slabbi z.B. den Port A dazu verwendet, ein Bitmuster an den Chip an zu legen. Der Schreibbefehl, um Port A zu beschreiben, benötigt einen Takt , und Port B "Parallel" zu Port A geschaltet ist z.B. in etwa so:
Port A ----> 470 Ohm ----> Pin von zu testenden Chip ---> Port B (mal die Schutzmaßnahmen wie Z-Dioden & Co. außen vor)
dann kann einen Takt später der Pegel an Port B gelesen werden, um geprüft zu werden, der über Port A an den Chip gesendet wurde.
Der Assembler-Befehl "OUT P, Rr" benötigt laut Atmel-Datenblatt einen Takt, ebenso "IN Rd, P". Mit dieser "Konstruktion" ist es möglich in 62,5ns ein Ergebnis zu erhalten, wenn beide Befehle direkt hintereinander stehen...
Ach ja, Zeitliche Verzögerungen von 62,5ns lassen sich mit "NOP" mit einem Takt auch gut einbauen...
-
Wenn solche Dinge noch nicht mal in den sogenannten "Profi-Geräten" drin ist, dann ist das in einem erstklassigen Hobby-Projekt auch kein muss...
"muss" nicht... Aber "kann"...
Ich bin bei der Diskussion etwas zwiegespalten...
slabbi hat hier definitiv was absolut geniales gebaut... Das steht außer Frage und ich glaub auch das wird hier niemand anzweifeln!
Überhaupt so viele Chips in einen Tester zu bringen und zu testen...
Die Software und die Datenbanken dazu aufzubauen: absolut genial! Und beides ist definitiv unbezahlbar!
So was hat definitiv kein anderes "Hobby-Projekt" zuvor geschafft...
Ich bin mir nicht Mal sicher, ob die teuren Geräte die Menge an Chips hin bekommen...
Wenn ich mir die Incircuit-Tester-Videos der amerikanischen YouTuber anschau, dann laufen die Teile deutlich schlechter und raten auch noch deutlich mehr herum, als der Chiptester Pro!
Das ist irre wie viele "False Positives" die bekommen ..
In deren Fall würde ich glaub lieber ne Münze werden... Das wäre glaub statistisch besser xD
Aber: sollte man irgendwann Mal eine neue Version davon planen - und ich bin mir sicher, dass ich mir die dann auch zulegen werde: dann wäre es definitiv eine Überlegung wert, ob man es evtl. hin bekommen könnte, dass man die Bauteile in der vorgegebene Spezifikation testet...
Selbst wenn das mehr an Hardware etc. kosten würde...
Denn wenn man die Chips halt außerhalb der Spezifikationen betreibt - und das schließt sowohl die Pegel, als auch den Takt ein - sind halt die als defekt erkannten Chips tatsächlich defekt, es werden aber auch ein paar Chips durchs Raster fallen...
Interessant wurde das Ganze ja auch noch, als Mal erwähnt wurde, dass ein zusätzliches angeschlosser SD-Karten-Leser dazu geführt hat, dass auf einmal ein Chip ein positives Ergebnis brachte...
Deswegen check ich alles grundsätzlich ohne den SD-Leser...
Und wenn man die Chips in die andere Richtung außerhalb der Spezifikationen betreibt, passiert so was wie bei MT...
Hab ich diese Woche erfahren: Es gab damals ein Verfahren vor Gericht, das damit endete, dass beide Seiten - sowohl MT, als auch Commodore schuld waren an den vielen Ausfällen...
Commodore betrieb die Chips außerhalb der Spezifikationen und MT stellte keine gute Ware her...
-
kennst du dich mit der programmierung der atmegas aus?
Ein wenig.
-
Alles anzeigen
Wenn ich mir die Incircuit-Tester-Videos der amerikanischen YouTuber anschau, dann laufen die Teile deutlich schlechter und raten auch noch deutlich mehr herum, als der Chiptester Pro!
Das ist irre wie viele "False Positives" die bekommen ..
In deren Fall würde ich glaub lieber ne Münze werden... Das wäre glaub statistisch besser xD
[...]
Denn wenn man die Chips halt außerhalb der Spezifikationen betreibt - und das schließt sowohl die Pegel, als auch den Takt ein - sind halt die als defekt erkannten Chips tatsächlich defekt, es werden aber auch ein paar Chips durchs Raster fallen...
Interessant wurde das Ganze ja auch noch, als Mal erwähnt wurde, dass ein zusätzliches angeschlosser SD-Karten-Leser dazu geführt hat, dass auf einmal ein Chip ein positives Ergebnis brachte...
Deswegen check ich alles grundsätzlich ohne den SD-Leser...
Das in-circuit Testen ist bei unseren Rechnern nicht wirklich machbar. Schon einmal gar nicht mit dem klassischen Ansatz, den zu testenden IC einfach mit einer Klammer mit einem Tester zu verbinden und dann darauf zu hoffen, dass etwas vernünftiges dabei herauskommt.
Da die alten ICs keine boundary scans kennen, gibt es hier nur einen sinnvollen Ansatz: Einen IC während des normalen Betriebs zu "beobachten" und sein Verhalten zu analysieren, Das erfordert aber wieder sehr schnelle Hardware.
Mit "außerhalb der Spezifikation" zu testen, wäre ich sehr vorsichtig. Da wäre hier niemand wirklich glücklich mit.
Die meisten ICs sind inzwischen 30-40 Jahre alt (teilweise sogar schon 50 Jahre). Wenn ein SRAM auf exakt 150ns Zugriffszeit getestet werden würde, weil es steht ja so im Datenblatt, würden etliche ICs durchfallen, die aber in einem z.B. C64 noch problemlos funktionieren würden, nur weil sie vielleicht 151ns benötigen.
Es ist einfach eine Frage, ob ich ein IC grundsätzlich wegwerfe, nur weil er nicht mehr 100% seiner Spec entspricht, aber im Grund noch ok ist, oder aber geringe Abweichungen von der Spec noch akzeptiere. Meiner Meinung nach rechtfertigt es nicht den Aufwand (und die damit verbundenen Kosten) auf wenige ns genau zu testen. Timing Probleme kommen vor, ohne Frage, aber sie sind relativ selten. Häufiger sind funktionale Defekte, wie defekte Speicherzellen, defekte Adressdecoder etc. Danach kommen in meiner Liste thermische Probleme (industrielle Speichertester testen auch bei unterschiedlichen Temperaturen) und erst ganz am Ende die Timing-Probleme.
Wenn der SD-Kartenleser verwendet wird, also während des Tests ein "dump" des Speicherinhalts geschrieben wird (OK lange gedrückt), verändert sich das Timing natürlich enorm. Das ist aber kein Problem, da hiermit untersucht werden kann, welche Zellen defekt sind oder ob z.B. der Adressdecoder defekt ist, die Geschwindigkeit spielt keine Rolle. Ist die SD-Karte nur gesteckt, der Test wurde aber normal gestartet (Ok wurde nicht lange gedrückt), bleibt das Timing exakt identisch.
-
Es ist einfach eine Frage, ob ich ein IC grundsätzlich wegwerfe, nur weil er nicht mehr 100% seiner Spec entspricht, aber im Grund noch ok ist, oder aber geringe Abweichungen von der Spec noch akzeptiere. Meiner Meinung nach rechtfertigt es nicht den Aufwand (und die damit verbundenen Kosten) auf wenige ns gena
Stimmt, man muss nur wissen, das das IC außerhalb seiner Spec liegt, damit man ihn noch in unkritischen Projekten nutzen kann...
-
slabbi: lass dir bitte nicht dein supertolles Projekt / Produkt von irgendwem hier "zerreden"
..ich hab das auch schon durch und ich weiss, wie böse das einem aufstösst ..nicht umsonst hat mein 5A-C64 - Netzteil niemals den Weg zu jemand anderem gefunden und wird ausschliesslich von MIR benutzt
dass ein Messgerät immer nur so gut sein kann, wie der User, der es bedient auch intelligent genug dafür ist - sollte wohl klar sein!
"wer viel Misst, misst Mist! "
ich finde deinen Tester super - und die defekten ICs, die er mir bislang angezeigt hat SIND auch wirklich defekt / teildefekt
..ich hab ja in meinem Video drauf hin gewiesen, dass ich einen D-Ram hab, der bei Richi z.B. als Ok getestet wird, bei mir als False ..der läuft zwar in einem C64 ..aber spätestens nach 30 Min. kommen dann die ersten Fehler ... und dann werden es schnell mehr
er IST also angeknackst - und selbst das hat dein Tester einwandfrei raus bekommen - Prima!
-
-
Sag mal slabbi , wenn ich die IO-Belegung durchzähle, komme ich bei der Rev.1.2i auf 76 belegte IO-Pins. Kommt das in etwa hin?
Etwas mehr. Display, ISP, LED und Taster mitgezählt?
-
slabbi: lass dir bitte nicht dein supertolles Projekt / Produkt von irgendwem hier "zerreden"
Dem schließe ich mich vorbehaltlos an...
..ich hab das auch schon durch und ich weiss, wie böse das einem aufstösst ..nicht umsonst hat mein 5A-C64 - Netzteil niemals den Weg zu jemand anderem gefunden und wird ausschliesslich von MIR benutzt
Echt??? Schade... ich hätte bedarf. Die anderen Lösungen im Internet gefallen mir nur nicht so sehr. Ich bin jetzt echt am überlegen, ob ich mir was selber designe. Ich möchte auch direkt einen Überspannungs-Schutz mit integrieren. Eventuell nutze ich mehrere isolierende DC/DC-Wandler um die Spannungen hin zu bekommen, und betreibe das ganze mit einem Notebook-Netzteil... Je nach Wandler könnte man dann auch ein C64-Retro-Treffen auf der grünen Wiese machen, weil dann schon 12V am Eingang des Wandlers reichen... Die Schaltung sollte dann im Original C64-Netzteilgehäuse platz finden...
ich finde deinen Tester super - und die defekten ICs, die er mir bislang angezeigt hat SIND auch wirklich defekt / teildefekt
..ich hab ja in meinem Video drauf hin gewiesen, dass ich einen D-Ram hab, der bei Richi z.B. als Ok getestet wird, bei mir als False ..der läuft zwar in einem C64 ..aber spätestens nach 30 Min. kommen dann die ersten Fehler ... und dann werden es schnell mehr
er IST also angeknackst - und selbst das hat dein Tester einwandfrei raus bekommen - Prima!
Stimmt... kann ich für meine mit den RCT getesteten Bauteile zu bestätigen...
Ich habe zwei davon. Der grüne RCT hat einen "Bestückungs-Fehler", weil ich den Hinweis auf die 470 Ohm Widerstände sogar auf der Platine übersehen habe, weil Ich hab' mich einfach gefreut habe, ein Testwerkzeug bekommen zu haben, bei dem die Spec sagt, was mich erwartet und ich deswegen zu ungeduldig war, da zwei mal hinzusehen...
. Da sind jetzt 1K Ohm Widerstände drin. Der rote RCT hat die 470 Ohm bestückt. Von daher kann ich den grünen für einen strengeren Test für die Eingänge/Ausgänge mit weniger Strom nutzen, und den roten für einen Regelkonformen Test. Hat für auch was... -
Etwas mehr. Display, ISP, LED und Taster mitgezählt?
Ja, aber offensichtlich habe ich etwas übersehen...
-
Etwas mehr. Display, ISP, LED und Taster mitgezählt?
Ja, aber offensichtlich habe ich etwas übersehen...
Die LEDs... -
slabbi: lass dir bitte nicht dein supertolles Projekt / Produkt von irgendwem hier "zerreden"
Alles gut
Ich weiß, was der RCT kann, schließlich setze ich es bei meinen eigenen Reparaturen regelmäßig ein und an "Testobjekten" habe ich nun wirklich einige zur Auswahl
Wer meint, er müsse einen IC auf eine Nanosekunde genau prüfen, Pegel auf wenige mV genau einhalten und unbedingt kalibrierte Geräte einsetzen, damit er seinen C64 repariert bekommt, darf sich gerne passendes Equipment für mehrere 10.000 EUR kaufen. R&S, LeCroy, Keysight etc. freuen sich bestimmt ein passendes Angebot zu machen. Die Fehlerrate beim RCT ist sehr gering, da kommen einige andere (um einiges teurere) Geräte, die ich bereits zum Vergleich da hatte, nicht einmal in die Nähe.
Für Speicher habe ich einen Tipp:
https://www.advantest.com/products/memory/
Bericht z.B, unter https://epp.industrie.de/allge…hertest-mit-vollem-speed/
ein paar Daten: http://www.mathisci.com.cn/upl…f0ea4b80453f075da3640.pdf
Echte Schnapper, wenn dann der C64 noch nicht läuft, weiß man zumindest, dass es nicht am Tester gelegen hat.
-
Etwas mehr. Display, ISP, LED und Taster mitgezählt?
Ja, aber offensichtlich habe ich etwas übersehen...
Die LEDs...Geschaltet sind aber nur zwei (die Active-LED und die Vcc-LED über den MOSFET).
-
der Buzzer
-
der Buzzer
Dafür gab es früher auch ein nettes Easter Egg. Das ist nun in die Troubleshooter-FW zu finden.
-
der Buzzer
Auch den...
... der hat sich unter dem Display versteckt - aus den Augen, aus dem Sinn. slabbi , damit komme ich jetzt auf 79 belegte IO-Pins... und ich muss mal die Troubleshooter-FW laufen lassen... Das Ester Egg interessiert mich jetzt...
-
Ach ja, Zeitliche Verzögerungen von 62,5ns lassen sich mit "NOP" mit einem Takt auch gut einbauen...
das sehe ich aber ganz anders.
da kann man doch einen einzigen mikroprozessor befehlsschritt nicht mit einer
dann dazu nötigen befehlsabfolge vergleichen. das geht so nicht.
ganz einfach, einen zähler, z.b. den 4040 nehmen, während dem rct test, an die test pins halten
und dann hat man schon sehr genau, welche zeit, er wirklich benötigt.
und ich bleibe dabei, 62,5 nS sind unmöglich.
und hier geht es nicht nur um ein optimal angeordnetes port, sondern wohl um mehrere die
abgefragt und dann mit den tabellen verglichen werden müssen.
so würde man mit einem frequenzmesser und dem 4040 sehr schnell die wirklich möglichen
zeiten ganz einfach herausbekommen.
aber bitte, es ist ein schöner tester, mit sehr vielen ics zum testen und vergleichen.
alleine die vielen daten zusammen zu stellen benötigt wohl hunderte, eigentlich tausende stunden.
was ich nur vermeiden möchte, das besonders anfänger anfangen, bei einer fehlersuche,
z.b. auf einem c64 board, die ics auszulöten, dann im rct zu testen und dann der meinung zu sein,
nach der aussage ok oder nicht ok, weitere ics auszulöten.
so freute ich mich, das nun der rct nun um die für mich sehr sinnvole lösung, als programmer,
für alte eproms, erweitert wurde. da neue programmer das nicht können.
wohl aber auch, das ich für den pet damals, als erster, auch einen eprom programmer erstellte.
ich nannte ihn damals aber fälschlicher weiser, ein eprom brenner, weil ich vor dem eprommer,
einen prom brenner entwickelte. und ja, bei den damaligen proms wurden die internen sicherungen,
wie z.b. bei der 82s100 pla weggebrannt.
das dann auch die nachbauer, meines eprom programmers, meine bezeichnung als
brenner übernommen hatten, war ich nur am staunen und es war mein beweis,
sie haben die schaltung oft von mir sogar 1:1 kopiert und auch noch meine
fölschliche bezeichnung brenner übernommen. z.b. die firma vero = vobis,
die damals die größte versandfirma auch war. aber dazu habe ich schon woanders etwas geschrieben.
so muss ich nun, nach 44 jahren, schmunzeln, wenn ich jetzt noch, ab und zu
von einem eprom brenner lese. und ich denke mir, was habe ich damals angestellt?
wo ich doch möglichst keinen, in meinem ganzen leben, unnötig verwirren möchte.
die ersten käufer, meines damaligen eprom programmers, waren zum größten teil, funkammateure.
gruß
helmut
-
was ich nur vermeiden möchte, das besonders anfänger anfangen, bei einer fehlersuche,
z.b. auf einem c64 board, die ics auszulöten, dann im rct zu testen und dann der meinung zu sein,
nach der aussage ok oder nicht ok, weitere ics auszulöten.
Wo wir bei dem Spruch wären "wer viel misst, misst Mist."
Deine Aussage gilt für _jedes_ Werkzeug. Man muss wissen, wie man es korrekt einsetzt. Kein Messgerät kann ein 100%iges Ergebnis geben (selbst dann nicht, wenn es noch so gut kalibriert ist). Das Ergebnis muss immer interpretiert werden. Aus diesem Grund erläutere ich auch viele Kleinigkeiten im Handbuch, was bei anderen Geräten vorausgesetzt wird. Alles kann aber auch ich nicht ansprechen. Das würde dann eine mehrbändige Reihe werden.
