Matt hat geschrieben:
Nur bei 500Ms/s bei TDS520 wird ADC abwechselend angesteuert, das hatte ich davor auch gemerkt, da ist einwandfrei, mit defekte ADC ging bedingt (in untere Hälfte gab Schwingung)
![IMG_20180109_204719.jpg](./download/file.php?id=383&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180109_204719.jpg (273.49 KiB) 13319 mal betrachtet
EDIT: Ramp2, es ist sowie du gesagt hast, dass Verzögerungszeitbasis es steuert.
Grüss
Matt
chronos42 hat geschrieben:
Hm, das sieht eigentlich schon mal ganz gut aus.
Jitter ramp 1 und der time interpolator scheinen zu funktionieren. zumindest der statische interpolator. Für das random sampling wird ja ein Zufallssignal erzeugt, vielleicht stimmt da etwas nicht. Ist schon eine Weile her dass ich mich damit befasst habe, ich muss selbst erst mal wieder in meinen Unterlagen nachschauen, wie das im Detail war.
Zudem ist das beim 520 doch etwas anders, beim 540 werden 1,2 oder 4 ADCs zeitversetzt angesteuert, je nach Zeitbereich und Anzahl der benutzten Kanäle.
Um die Sache weiter einzukreisen wäre jetzt vielleicht ein Neuabgleich hilfreich. Der wird mit Sicherheit scheitern, aber man sieht dann wenigstens, was sich nicht abgleichen / kalibrieren lässt.
Notwendig ist dazu ein historischer DOS PC mit ISA GPIB Karte, die Tek Software (gibt es im Netz), eine DC Kalibrierquelle, ein Tek SG 503 und SG 504 oder vergleichbarer HF Generator mit konstanter Amplitude im Bereich von von einigen MHz bis zu 500MHz.
Vorher vorsichtshalber ein Backup des NV-RAMs machen.
Matt hat geschrieben:
Ich weiss NICHT.... habe nur paar Schaltung an U1703 (EXT-Trigger-IC ) gemesst und geputzt (ich habe 2x gammelige Lötstelle an Diode) übergesehen.
Fehlermeldung exitisiert noch, "PulseWitdDiag Failed" also irgendwas mit Trigger-Schaltung, der vorher nicht aufgefallen ist.
Das war Grund, warum ich an U1703 gemesst habe.. Dafür ist vorherige Fehlermeldung mit "ctlConfidcencDiag" verschwundet.
JETZT macht der wie es soll, nachdem ich ihm paarmal durch SPC quälen lässt. Da kann ich aber nicht erklären, warum , wodurch ist spärliche Darstellung in Samling-Modus verschwindet.
![IMG_20180109_230652.jpg](./download/file.php?id=384&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180109_230652.jpg (320.58 KiB) 13319 mal betrachtet
![IMG_20180109_230806.jpg](./download/file.php?id=388&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180109_230806.jpg (284.45 KiB) 13317 mal betrachtet
Grüss
Matt
PS: uralte PC ist gar keine Problem für mich, denn ich bin beruflich bedingt davon auch geschädigt.
Wobei diese System sicherlich erheblich potenter ist (Celeron 423 1,06Ghz, 1GB RAM, hat ISA Schnittstelle)
chronos42 hat geschrieben:
Hallo Matt,
ADC clock Phasenlage und Interpolation der Samplingzeitpunkte scheint nun zu passen. Vermutlich wurden bei früheren SPCs mit der der defekten Schaltung völlig falsche Werte ermittelt und gespeichert, diese wurden nach meheren Kalibrationslufen schrittweise wieder in die richtigen Größenordnungen gebracht.
Jitterramp time interpolator funktioniert auch wieder, zumindest die der Main Timebase. Somit werden die Differenzen zwischen starrem Timing der digitalen Triggerlogik und den dazu asynchronen Triggerereignissen korrigiert.
Funktion: Das ist ein Dual slope System. Im Zeitbereich zwischen zwischen Triggerereignis und Digitalclock wird ein Kondensator geladen. Dieser wird danach controlliert entladen, über die Ladung wird die Abweichung ermittelt zwischen diesen beiden Taktflanken. Der Haupprozessor bekommt eine Information wieviel er das Signal horizontal verschieben muss. Somit wird eine stabile horizontale Darstellung gewährleistet, auch bei hohen Frequenzen.
Unbedingt auch die jitter ramp der zweiten Zeitbasis überprüfen.
Ein Problem hast Du wohl noch beim Extendet Trigger.
Das ist ein Chip der für die erweiterte Pulse Trigger Funktion zuständig ist. Damit wird auf Pulslängen getriggert, also entweder kurze glitches oder auf Impulslängen die größer oder kleiner als eine voreingestellte Zeit sind. Der Referenzimpuls, mit dem verglichen wird, wird spannungsgesteuert in dem extendd Trigger Chip erstellt und aus dem Ergebnis ein extendet Trigger Signal erzeugt, welches zur Haupt-Triggerlogik geht.
Entweder funktioniert dieser Chip nicht richtig oder die Steuerspannungen sind nicht in Ordnung.
Erst mal die Steuerspannungen an dem Chip überprüfen und auch mal schauen, was der extendet Trigger überhaupt macht.
Matt hat geschrieben:
Jawohl, alles (auch Verzögerungszeitbasis) passt prima bis auf Trigger-Geschichte.
Ich habe Fehlermeldung nachvollziehen und verifizieren wollen.
Logik-Trigger funktioniert 1A, Glitch-Trigger (damit ist Problemteil gemeint) funktioniert nach meine Wahrnehmung korrekt.
U1703 (extendet Trigger-IC), analoge Arbeitspunkt stimmt erst, wenn ich bei Trigger auf <Pulse> wähle. Da denke ich , dass es auch stimmt.
![IMG_20180110_182559.jpg](./download/file.php?id=386&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180110_182559.jpg (260.51 KiB) 13317 mal betrachtet
Huch...was nun. Riecht nach korrupte bzw. vermurkste Kalibierung für diese Teil.
Dafür ist heute 2x NVSRAM reingekommt. Diesemal frage ich, ob es kein Problem gibt,wenn ich NVSRAM Typ mit schnellere Timing von 70ns verbaue. Orginale hat Timing von 120ns.
![IMG_20180110_182909.jpg](./download/file.php?id=387&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180110_182909.jpg (318.88 KiB) 13317 mal betrachtet
Grüss
Matt
chronos42 hat geschrieben:
Bei den NV Rams habe ich teilweise auch schnellere eingebaut, das war kein Problem. Ist an der Stelle recht unkritisch.
Größeres Problem war immer welche zu bekommen, die wirklich unbenutzt waren. Alle günstig angebotenen "neue" NV Rams enthielten bereits Daten und waren teilweise neu bedruckt. Alles was auch China preiswert angeboten wird, ist nach meinen Erfahrungen nicht neu, sondern bereits benutzte Gebrauchtware. Die funktionieren dennoch einige Jahre, aber man weiß halt nicht, wie alt die wirklich sind und wie lange die eingebaute Lithiumzelle noch lebt. Das aufgedruckte Fertigungsdatum war meistens gefälscht.
Ansonsten würde ich jetzt einfach mal einen kompletten Neuabgleich machen, dann wird sich zeigen ob und wo es noch Probleme gibt oder ob die Fehlermeldungen sogar verschwinden.
chronos42 hat geschrieben:
Nachtrag:
Der extendet Trigger Chip hat zwei Arbeitsbereiche: Pulse (scheint wohl zu funktionieren) und glitch. Letzteres ist für (sehr) kurze Pulse. Hast Du das auch überprüft? Das wird von unterschiedlichen analogen Spannungen konfiguriert. Wenn pulse funktioniert heißt das nicht automatisch, dass auch glitch funktioniert.
Matt hat geschrieben:
Du hast mich auf Fehler gebracht.. Glitches (= kurze Puls) geht prima. Bei Puls schaut anders aus.
bis ca 400ns als Einstellwerte ist pausibel, darüber weicht extrem (logarithmisch) ab.
wenn ich es auf 560ns einstellt, ist das Werte nah 1µs.
Bei 620ns Einstellwerte , es beträgt dann nah 10µs. Analoge Spannung an IC beträgt nah 0V (2stellige mV )
Da riecht nach Problem mit Umschaltung des Zeitbereich in IC oder IC ist halbkaputt.
Es wird mit 74HCT164 als Schieberegister angesteuert.
Grüss
Matt
chronos42 hat geschrieben:
Aha, interessant, wir kommen der Sache näher.
Kann sein, dass da in der SPI Kette, die mit 74HCT164 aufgebaut ist, was nicht stimmt, das hatte ich aber noch nie.
Was nicht sein kann ist, dass die Steuerspannung (welche?) immer bei 0V liegt, die muss sich ändern, abhängig von der Glitch und Pulse Einstellung.
Das sind insgesamt 4 Steuerspannungen und eine Referenzspannung, die in das extended trigger IC gehen, zudem ist noch ein TL074 dazwischen. Ich vermute den Fehler bei den Spannungen oder bei dem TL074.
Das IC kann natürlich auch kaputt sein, ist das mit Elektrolyt geflutet worden?
Davon habe ich auch noch eins in Reserve, falls notwendig....
Gruß
Karlheinz
Matt hat geschrieben:
Bis ca 620ns ist Steuerspannung verändertlich, in fast 20mV Schritte, danach tümmelt es an 0V bzw. 0,5V herum.
Schieberegister-Ansteuerung müsste ich schon untersuchen.
Zu Frage, ob besagte IC auch mit Elektrolyt geflutet ist: Leider ja. Ich melde erstmal Bedarf an IC, wenn ich weitere Untersuchung anstelle. (TDS540 wird auch reingeguckt, ob es geschlachtet oder repariert wird)
Wie immer bin ich froh, dass ich damals TDS210 (Digitale Gurke mit grausame LCD Display) nur wegen 3x P6149A für 50€ gekauft habe. Diese Gerät ist recht nützlich für Untersuchung in digitale Schaltung.
Grüss
Matt
Mario_nks hat geschrieben:
Ich drücke dir für den 540 die Daumen, daß er sich reparieren lässt! Wäre schade um das Gerät!
Markus
Matt hat geschrieben:
Moin
Ich hoffe, dass ich nicht zu viel verlangt, kurze Messung an Extendet Trigger-IC zu machen ( Bild zeigt auch welchere Pin)
Kurze negative Puls ist mit Puls-Breite Einstellung veränderlich, postitve Puls verschwindet mit ca 70ns.
ABER, Flankesteilheit sieht sehr ungesund aus.
![IMG_20180111_194419.jpg](./download/file.php?id=390&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180111_194419.jpg (291.78 KiB) 13316 mal betrachtet
![IMG_20180111_194336.jpg](./download/file.php?id=389&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180111_194336.jpg (309.55 KiB) 13316 mal betrachtet
Grüss und danke in Voraus.
Matt
chronos42 hat geschrieben:
Hallo Matt,
kann ich machen, aber aus Gründen der Vergleichbarkeit wäre es gut, wenn du die genauen Triggereinstellungen noch dazuschreibst.
Gruß
Karlheinz
Matt hat geschrieben:
*Trigger_Modus steht auf <Pulse>
* Puls-Breite ist auf 60ns (Bild mit schmale postive Puls) und auf 400ns (Bild mit dicke negative Puls).
*Es müsste auf postive Glitches getriggert werden, sonst keine Puls.
* Triggerung auf negative Glitches ergibt beschriebene Puls , der jedoch an Pin vertauscht ist.
Restliche Einstellwerte ist egal.
Grüss
Matt
chronos42 hat geschrieben:
Ok, dauert aber etwas, ich muss das erst vorbereiten und einen TDS 540 öffnen.
chronos42 hat geschrieben:
So, leider scheinen wir unterschiedliche Einstellungen zu haben.
Ich nehme einen Puls mit 60nS Pulsbreite.
Einstellung Glitch positiv , 400nS
Dann ergibt sich an Pin 32 Bild 1.
Bei negativem Puls und Trigger auf neg. Glitch ist das Signal an Pin 32 nahezu gleich, an Pin 14 sehe ich kein Signal.
Irgendwas passt da nicht.
![1(1).gif](./download/file.php?id=391&sid=020dd6a19b82b33dde166161b3c100e5)
- 1(1).gif (20.92 KiB) 13315 mal betrachtet
Matt hat geschrieben:
Okay, flache Flanke ist bei dir genauso ?
EDIT, jetzt sehe ich GIF, da denke ich also, dass es OK ist.
60ns , da schrieb ich, dass Puls-Breite auf 60ns eingestellt ist und es getriggert wird. Aber es ist erledigt, denn flache Flanke ist schon richtig.
Kleine letzte Wunsch, 74HCT164, Daten (Pin2) oder Takt (Pin 8) .
Wird es etwas reagiert?, wenn man Puls-Breite auf mehre Mirkosekunde stellt. Meine Vermutung ist immernoch, dass es eigentlich umgeschaltet wird.
Bei mir reagiert es nur beim umschalten des Trigger-Modus auf Logik / Pulse. Inhalt von 8bit ist nicht wichtig.
Danke schonmal.
Grüss
Matt
![U1703.png](./download/file.php?id=392&sid=020dd6a19b82b33dde166161b3c100e5)
- U1703.png (363.12 KiB) 13315 mal betrachtet
Matt hat geschrieben:
Denke ich genauso, dass eine IC (U1703 oder CTL) kaputt ist. Nötigsfalls kann ich damit leben, denn es wirkt nur auf Trigger-Modus "Pulse'" aus.
Morgen kommt TDS540-Leiche, ich werde erstmal ihm um paar IC erleichtert.
Tek Servicemanual hat mehre Fehlerdiagramm. Deren Ergebnisse sagt beim Extendet-Trigger-Fehlerdiagramm dass Clock Trigger-Logic verantwortlich ist.
OK, wir mache so. 10V Referenz ist OK, 9,94V (mit Metex 3,5stellige DMM gemesst, reicht für Fehlersuchen aus)
Glitch, postive Puls, getriggerte Zustand
2ns
TP1705 -10,34
TP1706 -5,42
TP1707 -5,80
TP1708 -5,44
10ns
TP1705 -1,109
TP1706 -5,42
TP1707 -0,982
TP1708 -5,44
100ns
TP1705 0,008
TP1706 -3,105
TP1707 0,004
TP1708 -3,112
1µs
TP1705 0,255
TP1706 0,253
TP1707 0,246
TP1708 0,245
Es ist wie bereits geschrieben , dass bis einige hundert Nanosekunden pausibel ist, danach weicht logarithmisch ab.
Grüss
Matt
chronos42 hat geschrieben:
Ok, hier sind meine Werte (dahinter geschrieben)
2ns
TP1705 -10,34 -8,117
TP1706 -5,42 -5,454
TP1707 -5,80 -5,139
TP1708 -5,44 -5,441
10ns
TP1705 -1,109 -0,9943
TP1706 -5,42 -5,456
TP1707 -0,982 -0,8578
TP1708 -5,44 -5,441
100ns
TP1705 0,008 0,0037
TP1706 -3,105 - 3,3888
TP1707 0,004 0,0041
TP1708 -3,112 -3,2705
1µs
TP1705 0,255 0,0042
TP1706 0,253 -0,3410
TP1707 0,246 0,0045
TP1708 0,245 -0,3218
Bei 1µS gibt es deutliche Abweichungen. Aber ob das innerhalb der Adjustment Toleranzen liegt oder ein fehler ist weiß ich auch nicht. Aber es ist mal ein Anhaltspunkt.
Matt hat geschrieben:
OK, ich stelle diese Werte so ein, dass 1µs Puls noch getriggert /bzw. untergedrückt wird.
Ergebnisse: es stimmt fast mit deine Messwerte drüber.
auf "1µs" eingestellt
TP1705 0,007 0,0042
TP1706 -0,309 -0,3410
TP1707 0,004 0,0045
TP1708 -0,392 -0,3218
Alles klar, Neuabgleich braucht der.
Grüss
Matt
chronos42 hat geschrieben:
Jepp, das ist nun eindeutig, ich sage auch: Komplett neu abgleichen.
Vielleicht wurde der mal kalibriert als er schon durch ausgelaufenes Elektrolyt beschädigt war.
Dann stimmt jetzt natürlich nichts mehr.
Gruß
Karlheinz
Matt hat geschrieben:
Heute ist alle benötigte für Abgleich über GPIB da und zusammengestellt.
Ich habe orginale NI PCIIA ( alte mit µpD7210 Controller) und PCII -Klon (CEC PC-488) bekommen, ebenso GPIB-Kabeln.
Einstellen von Ressource an PCII-Klon ist sehr haarig, denn ich stösse an "87". Was möchte Tek Installer "87" als E/A Adresse für ISA genauer sagen?. Ich dachte, dass Adresse-Bit 8 und 7 gesetzt werden sollen (= 0x180) Stimmt nicht, müsste 0x2B8 sein. Was hat da Software-Entwickler geraucht ? Adresse 0x2B8 habe ich nur aus Zufall herausgefundet, denn das ist Standard-Einstellung für orginale NI PCII.
Egal ob es mit moderne Board (IBASE-IB930H) oder uralte PIA-460 SBC läuft (Pentium-S 133MHz mit brachichale 128MB RAM)
Keiner möchte mit Tek TDS520 verbinden, ebenso nicht mit TDS540. Software findet in alle Fall Karte, falscheingestellte Adresse oder Interrupt ergibt, dass Software meldet, dass Karte nicht ansteuerbar ist.
2x verschiedene GPIB Kabeln wurde ausprobiert, in alle Fall ist Betriebsystem WiN98SE.
Danach habe ich keine Lust mehr und stehen lassen. Irgendwie müsste ich falsch gemacht habe.
Nur aus Not installierte ich halt MS-DOS 6.22 oder 5.0 auf 64MB grosse CF-Karte, denn Diskettelaufwerk liegt bereits bei mir.
Grüss
Matt
chronos42 hat geschrieben:
Hallo Matt,
blöde Frage, aber ist der Tek richtig konfiguriert?
Die GPIB Schnittstelle muss auf Talk/Listen stehen, nicht auf off oder hardcopy.
Ansonsten kann die Software nicht mit dem Tek kommunizieren.
Den Schalter für die Programmiersperre erst dann betätigen, wenn die Software dazu auffordert.
Gruß
KL
Matt hat geschrieben:
Hallo
Heute habe ich geschafft, hab gestern und heute ziemlich geflucht, denn PCI Karte von NI ist Absturzkanditat, denn ich wollte mit PCI Karte Kommunikation über GPIB BUS testen.
Tek ist bereits richtig konfigiert, "talk/listen" und Adresse zwischen 0-29. ich habe da 29 bzw. 1 genohmen.
Der Kisten verweigert trotzdem es mit Tek zu kommunizeren.
Dass es auf "talk/listen Adresse x" gedrückt werden sollen, ist mir nicht sofort ersichtlich und ich habe mehrmals auf "hardcopy" gedrückt , um den auf "talk/listen" umzustellen. So richtig bin ich mit Tek TDS5xx nicht warm.
Erst als ich Adresse auf 0 gesetzt habe, dann ging es aufeinmal. (Komisch, ich hatte anfangs auch ausprobiert)
Pulse-Trigger-Ablgeich ist am Ende mit Fehlermeldung (dass es mit Timer nicht stimmt) abgebrochen.
Foto wird es nachträglich hochgeladet. Erstmal habe ich Schnauze voll von GPIB Geschichte.
Grüss
Matt
Matt hat geschrieben:
Nachtrag mit Foto.
![IMG-20180106-WA0005(1).jpg](./download/file.php?id=393&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG-20180106-WA0005(1).jpg (161.68 KiB) 13314 mal betrachtet
So schaut mit Chaos aus. Tek ist offen, da ich Kalibierungsdaten vermurkst habe. Da spielte ich NVSRAM mit alte Daten zurück.
Daher ist Karlheinz's Hinweis, dass NVSRAM vorher gesichert werden sollen, mit höchste WICHTIGKEIT bewertet.
![IMG_20180203_122154.jpg](./download/file.php?id=394&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180203_122154.jpg (203.38 KiB) 13314 mal betrachtet
In Tek Manual empfohlene Signalgenerator.
![IMG_20180203_122652.jpg](./download/file.php?id=395&sid=020dd6a19b82b33dde166161b3c100e5)
- IMG_20180203_122652.jpg (167.24 KiB) 13314 mal betrachtet
Das ist Grund, dass Software Ablgeich abbricht.
Grüss
matt