Finale: hp 5342a 18GHz Zähler mit mehreren Baustellen
Re: Update 2 hp 5342a 18GHz Zähler mit mehreren Baustellen
Gratulation und Respekt! Das hätte wahrscheinlich nicht jeder Reparateur bis zum guten Ende durchgehalten. Tolle Leistung
Re: Update 2 hp 5342a 18GHz Zähler mit mehreren Baustellen
So, nun zum Finale, der Zähler läuft wieder zu 100%. 
Was bisher geschah:
Der Zähler funktionierte im 18GHz Bereich immer wieder sporadisch für ein paar Minuten, danach zeigt er nur noch 0 000 0000 0000 0000 an. Wie schon beschrieben, war zunächst ein defekter 5GHz Verstärker IC von hp dafür verantwortlich, dass ein Ausgangssignal des Offset-VCOs fehlte. Danach lief das Gerät einige Zeit, nach einem 24 Stunden Dauertest fiel es wieder aus. Dann kam das Netzteilproblem dazwischen.
Jetzt stand ich wieder vor der Aufgabe irgendeinen Ansatz zu finden, was da nicht funktioniert. Ich habe sehr viel Zeit investiert die beteiligten Baugruppen zu überprüfen, alles ohne Ergebnis. Ich will da nicht weiter drauf eingehen, das würde sonst ein riesiger Reparaturbericht werden.
Folgende Erkenntnis hatte ich bisher:
HF-Teil einschließlich Sampler und Kammgenerator ok, denn im manuellen Modus funktionierte der Zähler einwandfrei.
Ablaufsteuerung des Zählers: ok.
Beide Oszillatoren: ok.
Digitale Erkennung ob die ZF im korrekten Bereich liegt und ausreichenden Pegel hat: ok.
PLL für den Main-Oszillator incl. programmierbarem Teiler: ok.
PLL und Steuerung um den Offset-Oszillator immer 500kHz unter dem Main-VCO zu halten: ok.
CPU : ok
Baugruppe mit den Zählern für die ZF-Frequenz und der Oszillatoren: ok
Jetzt muss ich doch etwas tiefer auf die Schaltungsbeschreibung des HF-Teils eingehen.
Ein vom Main-Oszillator angesteuerter Kammgenerator (sampler driver) erzeugt ein extrem hochfrequentes Signal, dessen Harmonische den Abstand der Oszillatorfrequenz haben und dessen Frequenzbereich weit in den GHz Bereich geht. Im automatischen Modus muss der Zähler ermitteln, über welche Harmonische das ZF-Signal erzeugt wird. Wie das funktioniert ist im Servicemanual beschrieben, Seite 8-36 bis 8.42.
Es ist zu sehen, dass der Zähler im Fehlerfall die Nummer der Harmonischen nicht ermitteln kann, das sieht man im Servicemode 1, der zeigt nichts an. Während der Main-Oszillator im Servicemode 2 dieselben Werte anzeigt wie im funktionierenden Zustand, lag die des Offset-Oszillators komplett daneben. Bei 990 MHz Eingangsfrequenz zeigt Servicemode 2 10 085 5XX als heruntergeteilte Zwischenfrequenz. Der Offset-Oszillator im Testmode 3 zeigte eine um ein paar kHz geringere Frequenz an. Im Fehlerfall zeigte Testmode 3 irgendwas zwischen 6 xxxxx und 7 xxxxxx.
Inzwischen weiß ich, dass das einer der entscheidende Hinweise auf den Fehler war. Da ich das Gerät aber noch nicht kannte und so viele Spuren zu verfolgen waren, ging das leider unter. Beim nächsten Mal weiß ich es besser.
Warum funktionierte die Erkennung der Harmonischen nicht?
Die Erkennung läuft folgendermaßen ab:
Die CPU verändert solange die Frequenz des Main-Oszillators, bis eine Zwischenfrequenz detektiert wird anhand einer Pegelerkennung. Dann setzt die Software ein Flag auf der Baugruppe A12, IF Detector Assembly. Der Schaltungsteil dafür mit den Registern und Bustreibern findet man im Schaltplan rechts unten.
Liegt die ZF im richtigen Frequenzbereich, dann setzt eine digitale Frequenzerkennung auf der Karte das Flag nicht zurück, es bleibt gültig. Meldet der Detektor eine Frequenz außerhalb des vorgegebenen Bereiches wird das Flag zurückgesetzt. Die Software wiederholt dann die automatische Bestimmung der Harmonischen mit einer anderen Startfrequenz des Main-Oszillators. Bleibt das Flag gesetzt, wird auf den Offset-Oszillator umgeschaltet, dann wird wieder das Flag abgefragt. Bleibt es weiterhin gesetzt dann weiß die Software, dass sie die richtige Harmonische ermittelt hat. Wenn nicht, wird weitergesucht. Es wird zudem kontinuierlich der Pegel der ZF überwacht. Ist er zu klein, wird das Flag ebenfalls zurückgesetzt über die beiden Reseteingänge von U13. Dann beginnt der Suchvorgang wieder von vorne.
Mein Gerät zeigte folgendes Verhalten:
Nach erkennen des ZF-Pegels stoppte die Suchfunktion zuerst. Pegel stimmte, Frequenz stimmte. Eigentlich hätte jetzt die Frequenz berechnet und angezeigt werden müssen. Stattdessen startete die Suchfunktion aber wieder neu. Das konnte nur bedeuten, dass das Flag immer wieder zurückgesetzt wurde, auch wenn alle Parameter stimmten. Mit dem Oszilloskop konnte man sehen, dass die Ausgänge 5 und 9 von U13 tatsächlich immer wieder zurückgesetzt wurden.
Der Grund war dieses Signal hier an den beiden R Eingängen von U13:
Was passiert hier?
Man sieht wie der Pegel der ZF Erkennung zuerst auf high geht, weil eine passende Harmonische gefunden wurde. Im nächsten Schritt wird vom Main auf den Offset-Oszillator umgeschaltet um die Harmonische zu bestimmen. (Habe ich schon erwähnt dass die Details dazu im Servicemanual stehen?..) Eigentlich sollte die Levelanzeige auf high bleiben, stattdessen kommt dieser Burst. Was ist das? Mit anderer Zeitauflösung sieht man sofort das es sich um ein Zufallsmuster handelt. (Habe ich mal wieder vergessen abzuspeichern) Dieses erzeugt der Zähler selbst, damit wird zwischen den beiden Oszillatoren geschaltet.
Zwischen den beiden Oszillatoren wird nicht mit einer festen Frequenz umgeschaltet, sondern mit einer Zufallsfrequenz. Damit wird verhindert, dass es eine zufällige Korrelation mit einer FM-Modulation des Signals geben kann, was zu falschen Messergebnissen führen würde. Hier gab es nur eine Erklärung: Sobald vom Main-Oszillator auf den Offset-Oszillator umgeschaltet wurde, kommt keine ZF mehr. Das wiederum bedeutet, dass der sampler driver nur vom Main-Oszillator angesteuert wird, aber nicht vom Offset-Oszillator. Das war eigentlich wieder genau derselbe Fehler wie ganz am Anfang, auch da fehlte die Frequenz des Offset-Oszillators. Das konnte man aber recht einfach finden, weil zu sehen war, dass einer der beiden Ausgänge des Oszillatormoduls tot war. Genau der, der den Sampler Driver ansteuert. Und genau das funktionierte jetzt schon wieder nicht mehr, nach Umschalten auf den Offset-Oszillator ist keine ZF mehr vorhanden. Es musste aber nun eine andere Ursache haben, denn der Offset-Oszillator ist nicht wieder ausgefallen. Es ist nun auch klar warum der Suchalgorithmus zu keinem Ergebnis kommen konnte und sich zu Tode gesucht hat.
Es kam nur noch die Baugruppe A5 Offset Multiplexer in Frage.
Hier sind wieder meine speziellen Freunde im Einsatz, die Begrenzer-Verstärker ICs von hp, U1 und U4. Ich habe die Karte auf einen Extender gesteckt und bei beiden an Pin 5 das Signal überprüft. An U4 war alles ok, an U1 war nur ein winziges Signal an Pin 5 zu sehen. Zudem liegen an Pin 5 4,5V DC an statt 3V, wie am anderen IC. Also ist somit der zweite Chip dieses Typs verreckt mit genau demselben Fehlerbild. Erst funktionierte er einige Stunden einwandfrei, dann nur noch sporadisch, dann gar nicht mehr.
Zum Glück habe ich eine 10er-Packung von diesen ICs gekauft.
Hier die Baugruppe mit neuem IC, links oben.
Seit über einen Tag läuft er nun wieder im Dauertest
Zum Abschluss noch was zu dem hp Schaltkreis. Das ist im Prinzip ein MMIC, nur ist er universeller verwendbar. Im Schaltplan A5 sieht man die typische Außenbeschaltung und den überschaubaren Inhalt des ICs. Es sind nur zwei Transistoren und drei Widerstände. Beim linken Transistor ist die B-E und die B-C Strecke in Ordnung, gemessen mit einem Multimeter. Ca. 0.7V Durchgang, kein Durchgang in Sperrichtung. An der Strecke C-E misst man 0,28V Durchgangsspannung in beide Richtungen. Der linke Transistor hat zudem keinerlei Verstärkung mehr. Beide ICs haben genau denselben Fehler. Ebenfalls kurios: Dieses IC ist genau mit dem Ausgang des ICs auf dem Offset-Oszillator verbunden, welches ebenfalls ausgefallen war.
Ich werde jetzt noch ein paar kleine Abgleicharbeiten machen, dann kommt noch ein ausführlicher Dauertest bei geschlossenem Gehäuse. Hoffentlich war es das dann endlich. Obwohl, ich habe ja noch acht Ersatz-ICs
Was bisher geschah:
Der Zähler funktionierte im 18GHz Bereich immer wieder sporadisch für ein paar Minuten, danach zeigt er nur noch 0 000 0000 0000 0000 an. Wie schon beschrieben, war zunächst ein defekter 5GHz Verstärker IC von hp dafür verantwortlich, dass ein Ausgangssignal des Offset-VCOs fehlte. Danach lief das Gerät einige Zeit, nach einem 24 Stunden Dauertest fiel es wieder aus. Dann kam das Netzteilproblem dazwischen.
Jetzt stand ich wieder vor der Aufgabe irgendeinen Ansatz zu finden, was da nicht funktioniert. Ich habe sehr viel Zeit investiert die beteiligten Baugruppen zu überprüfen, alles ohne Ergebnis. Ich will da nicht weiter drauf eingehen, das würde sonst ein riesiger Reparaturbericht werden.
Folgende Erkenntnis hatte ich bisher:
HF-Teil einschließlich Sampler und Kammgenerator ok, denn im manuellen Modus funktionierte der Zähler einwandfrei.
Ablaufsteuerung des Zählers: ok.
Beide Oszillatoren: ok.
Digitale Erkennung ob die ZF im korrekten Bereich liegt und ausreichenden Pegel hat: ok.
PLL für den Main-Oszillator incl. programmierbarem Teiler: ok.
PLL und Steuerung um den Offset-Oszillator immer 500kHz unter dem Main-VCO zu halten: ok.
CPU : ok
Baugruppe mit den Zählern für die ZF-Frequenz und der Oszillatoren: ok
Jetzt muss ich doch etwas tiefer auf die Schaltungsbeschreibung des HF-Teils eingehen.
- 1.jpg (245.15 KiB) 1586 mal betrachtet
Es ist zu sehen, dass der Zähler im Fehlerfall die Nummer der Harmonischen nicht ermitteln kann, das sieht man im Servicemode 1, der zeigt nichts an. Während der Main-Oszillator im Servicemode 2 dieselben Werte anzeigt wie im funktionierenden Zustand, lag die des Offset-Oszillators komplett daneben. Bei 990 MHz Eingangsfrequenz zeigt Servicemode 2 10 085 5XX als heruntergeteilte Zwischenfrequenz. Der Offset-Oszillator im Testmode 3 zeigte eine um ein paar kHz geringere Frequenz an. Im Fehlerfall zeigte Testmode 3 irgendwas zwischen 6 xxxxx und 7 xxxxxx.
Inzwischen weiß ich, dass das einer der entscheidende Hinweise auf den Fehler war. Da ich das Gerät aber noch nicht kannte und so viele Spuren zu verfolgen waren, ging das leider unter. Beim nächsten Mal weiß ich es besser.
Warum funktionierte die Erkennung der Harmonischen nicht?
Die Erkennung läuft folgendermaßen ab:
Die CPU verändert solange die Frequenz des Main-Oszillators, bis eine Zwischenfrequenz detektiert wird anhand einer Pegelerkennung. Dann setzt die Software ein Flag auf der Baugruppe A12, IF Detector Assembly. Der Schaltungsteil dafür mit den Registern und Bustreibern findet man im Schaltplan rechts unten.
- 2.jpg (341.54 KiB) 1586 mal betrachtet
Mein Gerät zeigte folgendes Verhalten:
Nach erkennen des ZF-Pegels stoppte die Suchfunktion zuerst. Pegel stimmte, Frequenz stimmte. Eigentlich hätte jetzt die Frequenz berechnet und angezeigt werden müssen. Stattdessen startete die Suchfunktion aber wieder neu. Das konnte nur bedeuten, dass das Flag immer wieder zurückgesetzt wurde, auch wenn alle Parameter stimmten. Mit dem Oszilloskop konnte man sehen, dass die Ausgänge 5 und 9 von U13 tatsächlich immer wieder zurückgesetzt wurden.
Der Grund war dieses Signal hier an den beiden R Eingängen von U13:
- 3.jpg (190.91 KiB) 1586 mal betrachtet
Man sieht wie der Pegel der ZF Erkennung zuerst auf high geht, weil eine passende Harmonische gefunden wurde. Im nächsten Schritt wird vom Main auf den Offset-Oszillator umgeschaltet um die Harmonische zu bestimmen. (Habe ich schon erwähnt dass die Details dazu im Servicemanual stehen?..) Eigentlich sollte die Levelanzeige auf high bleiben, stattdessen kommt dieser Burst. Was ist das? Mit anderer Zeitauflösung sieht man sofort das es sich um ein Zufallsmuster handelt. (Habe ich mal wieder vergessen abzuspeichern) Dieses erzeugt der Zähler selbst, damit wird zwischen den beiden Oszillatoren geschaltet.
Zwischen den beiden Oszillatoren wird nicht mit einer festen Frequenz umgeschaltet, sondern mit einer Zufallsfrequenz. Damit wird verhindert, dass es eine zufällige Korrelation mit einer FM-Modulation des Signals geben kann, was zu falschen Messergebnissen führen würde. Hier gab es nur eine Erklärung: Sobald vom Main-Oszillator auf den Offset-Oszillator umgeschaltet wurde, kommt keine ZF mehr. Das wiederum bedeutet, dass der sampler driver nur vom Main-Oszillator angesteuert wird, aber nicht vom Offset-Oszillator. Das war eigentlich wieder genau derselbe Fehler wie ganz am Anfang, auch da fehlte die Frequenz des Offset-Oszillators. Das konnte man aber recht einfach finden, weil zu sehen war, dass einer der beiden Ausgänge des Oszillatormoduls tot war. Genau der, der den Sampler Driver ansteuert. Und genau das funktionierte jetzt schon wieder nicht mehr, nach Umschalten auf den Offset-Oszillator ist keine ZF mehr vorhanden. Es musste aber nun eine andere Ursache haben, denn der Offset-Oszillator ist nicht wieder ausgefallen. Es ist nun auch klar warum der Suchalgorithmus zu keinem Ergebnis kommen konnte und sich zu Tode gesucht hat.
Es kam nur noch die Baugruppe A5 Offset Multiplexer in Frage.
- 4.jpg (298.86 KiB) 1586 mal betrachtet
Zum Glück habe ich eine 10er-Packung von diesen ICs gekauft.
Hier die Baugruppe mit neuem IC, links oben.
- 5.jpg (497.55 KiB) 1586 mal betrachtet
- 6.jpg (583 KiB) 1586 mal betrachtet
Ich werde jetzt noch ein paar kleine Abgleicharbeiten machen, dann kommt noch ein ausführlicher Dauertest bei geschlossenem Gehäuse. Hoffentlich war es das dann endlich. Obwohl, ich habe ja noch acht Ersatz-ICs
Zuletzt geändert von chronos42 am 16 Mär 2024, 10:01, insgesamt 3-mal geändert.
Re: Finale: hp 5342a 18GHz Zähler mit mehreren Baustellen
Spannende Beschreibung!
Könnte das eventuell ein systematisches Elektromigrations-Problem in diesen Chips sein ...?
Könnte das eventuell ein systematisches Elektromigrations-Problem in diesen Chips sein ...?
liebe Grüße
Peter
Peter
Re: Finale: hp 5342a 18GHz Zähler mit mehreren Baustellen
Hallo Peter,
das kann schon ein Elektromigrations-Problem sein, aber auch Korrosion oder sonstige Materialveränderungen im Silizium sind möglich. Ich weiß es nicht. Vielleicht ist auch der verwendete Fertigungsprozess die Ursache. Halbleiter aus dieser Zeit (Ende der 70er Jahre) waren viel unzuverlässiger als heutige Bauelemente. Es ist jedenfalls eine durchaus bekannte Tatsache, dass speziell alte HF Halbleiter, egal ob Transistoren oder bipolare ICs, mit dem Alter überdurchschnittlich oft ausfallen. Das betrifft auch andere Halbleiter von hp (und anderen Firmen) aus dieser Zeit, z.B. die Asics in den hp 8116A oder 8112A Generatoren.
Aber davon abgesehen haben diese ICs über 40 Jahre funktioniert, da kann man sich jetzt nicht wirklich beklagen. Zum Glück gibt es für dieses IC noch zwei amerikanische Quellen mit original hp NOS ICs, welche ein wesentlich späteres Fertigungsdatum haben. Wo immer die das auch her haben. In dem Zähler sind 14 Stück davon verbaut, mal sehen ob weitere ausfallen.
Gruß
Karlheinz
das kann schon ein Elektromigrations-Problem sein, aber auch Korrosion oder sonstige Materialveränderungen im Silizium sind möglich. Ich weiß es nicht. Vielleicht ist auch der verwendete Fertigungsprozess die Ursache. Halbleiter aus dieser Zeit (Ende der 70er Jahre) waren viel unzuverlässiger als heutige Bauelemente. Es ist jedenfalls eine durchaus bekannte Tatsache, dass speziell alte HF Halbleiter, egal ob Transistoren oder bipolare ICs, mit dem Alter überdurchschnittlich oft ausfallen. Das betrifft auch andere Halbleiter von hp (und anderen Firmen) aus dieser Zeit, z.B. die Asics in den hp 8116A oder 8112A Generatoren.
Aber davon abgesehen haben diese ICs über 40 Jahre funktioniert, da kann man sich jetzt nicht wirklich beklagen. Zum Glück gibt es für dieses IC noch zwei amerikanische Quellen mit original hp NOS ICs, welche ein wesentlich späteres Fertigungsdatum haben. Wo immer die das auch her haben. In dem Zähler sind 14 Stück davon verbaut, mal sehen ob weitere ausfallen.
Gruß
Karlheinz
Zuletzt geändert von chronos42 am 09 Jul 2023, 18:23, insgesamt 2-mal geändert.
-
ProgBernie
- Beiträge: 533
- Registriert: 19 Dez 2018, 22:49
- Wohnort: Labenz
Re: Finale: hp 5342a 18GHz Zähler mit mehreren Baustellen
Glückwunsch zur erfolgreichen Reparatur, ich drück die Daumen daß der Eimer nicht wieder ausfällt. Und Danke für den Bericht.
Gruß Bernd