(Leidens-)Geschichte eines Neuzugangs: SEL Lo2001

[Baderbahn]

Hallo liebe Telexgemeinde,

nach einiger Zeit der Nicht-Telexerei habe ich mich wieder meinem Lorenz zugewandt.

Mein aktuelles Grundproblem ist wie folgt:
Vorinfo: Aktuelle Grundkonfiguration: "piTelex" Testbetrieb unter Windows 10 (ARM-Tablet)

Sobald ich eine Verbindung zwischen Tablet und Fernschreiber aufbaue (piTelex {lt} oder {at}) läuft der Fernschreiber korrekterweise an, die Verbindung zwischen "Außenwelt" und Fernschreiber wird aufgebaut und Zeichen korrekt hin- und her übertragen - soweit, so gut.
Nach kurzer Zeit (meist unter 60s) fängt der FS jedoch an, auf wundersame Weise wahllos Zeichen zu drucken, die gedruckten Zeichen werden allesamt als empfangene Zeichen (also rot) gedruckt. Die Verbindung wird dann irgendwann von selbst abgebrochen.
Das piTelex-Protokoll zeigt die am FS auftauchenden Zeichen nie an. Um zu überprüfen, daß das so stimmt, habe ich nun den Tonverkehr mittels Speicheroszilloskop an der Lo200X-Filterplatine mitgehört - und siehe da: Dort taucht auch nichts auf!
Die Zeichen werden also im FS "erzeugt"...
Zum Test habe ich den FS einige Zeit im FS-eigenen Lokalbetrieb, sowie per SEU-B-Jumperzieherei laufen lassen - jweils mit dem selben Ergebnis: keine ominösen Zeichen!

Langer rede kurzer Sinn: Sobald der FS mit einem anderen Gerät spricht, druckt er "mit Geisterhand" seltsame Dinge.

Ich werde wohl schauen müßen, was das SEU-B ausspuckt und an die FS-Elektronik weitergibt...
Bevor ich da wild herum messe, werde ich schauen, was ich in der Wartungsanleitung hierzu finden kann.

Vielleicht habt Ihr schon ähnliches gesehen und das Problem ist bekannt ?

Viele Grüße,
Simon

P.S. ich bin nach wie vor auf der Suche nach einer defekten Lo200X-Kupplung

[WolfgangH]

Hallo Simon,

viel kann ich dazu leider nicht sagen. Ich weiß nicht, was Du mit Jumperzieherei genau meinst.
Hast schon mal versucht den FS im Lokalbetrieb mit und ohne SEU-Karte laufen zu lassen?
Im besten Fall läßt sich der Fehler auf die Karte eingrenzen. Auf meiner SES-Karte (ähnlich SEU, aber andere Frequenzen) hatte ich mehrere Tantal-Kondensatoren mit Kurzschluß. Solche Kurzschlüsse können auch intermittierend sein. Das nur so als Hinweis, nicht als systematischer Tipp.

[Baderbahn]

Hallo Wolfgang,

viele Dank für Deine Info!
Mit "Jumperzieherei" meine ich die Sache aus Beitrag #18

Werde versuchen, ED1000 OHNE piTelex bzw. iTelex zu simulieren und den Signalweg durchzumessen.

Ich halte Euch auf dem Laufenden!

[Baderbahn]

Hallo miteinander,

Kurzupdate:
Mittlerweile ist mir ein RaspberryPi zero 2 W zugelaufen. Der würde zwar in die ADO-8 Aufputzdose, welche ich habe, mit Ach und Krach hineinpassen, wirklich Gefallen finde ich daran noch nicht. Ich bin am überlegen, dem Raspi ein kleines 3,5" Touchdisplay und ein kleines Gehäuse zu verpassen - mal sehen, was sich ergibt.
Was für die Gehäuselösung nett wäre: Eine ADO-8 Unterputzdose! Vielleicht hat jemand eine über ?

PiTelex (main branch) konnte ich ohne große Probleme auf dem Pi aufsetzen, die Kommunikation zwischen Pi und FS klappt auch wunderbar.
Leider habe ich am FS weiterhin das Problem, daß willkürlich Zeichen gedruckt werden oder die Verbindung seitens FS wieder abgebrochen wird.
Das Problem tritt nach wie vor nur bei "externer Verbindung", d.h. bei Verbindung zwischen FS und Außenwelt auf - im FS-Eigenen Lokalmodus oder bei gezogenem SEU-B läuft der FS ohne die selbstständige Druckerei .

Die Unterlagen mit Prüfplan der Arbeitspunktspannungen zum SEU-B liegen vor, da werde ich mich wohl mal daran machen, einen Prüfstand zu bauen

Alternativ wäre ein (probeweiser) Einbau eines sicher guten SEU-Bs von Interesse. Wenn jemand eines (zumindest leihweise) entbehren kann, bitte melden

Soweit der Stand...

Viele Grüße,
Simon

[Baderbahn]

Hallo liebe Telexfreunde,

wie es scheint, habe ich meinem SEU-B wieder ein korrektes Verhalten anerziehen können - der Test via Wetterdienst, Wetterprosa und @tasto lief vielversprechend - hierfür nochmal "Danke" an tasto

"Aber wo lag denn nun das Problem?"

Hierzu möchte ich zuvorderst die Symptome noch einmal darlegen:

• FS läuft im Lokalbetrieb hervorragend

• Im "Gegenstellenbetrieb" werden "von Geisterhand" eingehende Zeichen abgedruckt, die Verbindung von selbst abgebrochen

• Bei gezogenem SEU schaltet der FS in den Lokalbetrieb und funktioniert wie gewünscht

Um der Thematik auf den Grund gehen zu können, habe ich mir einen Prüfadapter gebaut - die zu Grunde liegenden Informationen habe ich aus dem Wartungshandbuch (Teil 2, PDF-Seite 22):

SEU_Belegung.png

Als Spannungsquelle dient mir ein altes ATX-PC-Netzteil - das liefert die verlangten +/- 12V von Haus aus sauber geregelt.
An den Pins 2 und 3 wird die von einem Frequenzgenerator erzeugte Ruhefrequenz von 500Hz angelegt, zur Kontrolle habe ich die Frequenz mit dem Frequenzzähler sowie Oszilloskop abgegriffen.

Ebenfalls auf Seite 22 des PDFs aufgeführt sind diverse Prüfspannungen, welche nach Herstellen der Betriebsbereitschaft des SEUs kontrolliert werden können (...und natürlich wurden...):

Prüfspannungen.png

Wie aus der Tabelle zu erfahren ist, kann an Pin 15 geprüft werden, ob das SEU korrekt auf die Empfangsfrequenzen reagiert.

Ein kurzer Blick in den Schaltplan verrät uns, daß Pin 15 "D_ab" (Rechte Seite, obere Hälfte) den Datenstrom, welcher moduliert auf das SEU trifft, als "normalen, seriellen Bitstream" an die Elektronik des Fernschreibers weiterreicht - das Äquivalent in Gegenrichtung wäre Pin 12 (D_an):

Schaltplan_kpl.png

Um ansehen zu können, was an D_ab an die FS-Elektronik weitergereicht wird, habe ich das Oszi angehängt.
Bei 500Hz Empfangsfrequenz sieht die Sache wie folgt aus:

500Hz_an_def.png

Trace 1 ist der Kontrollstream 500Hz, am Frequenzgenerator abgegriffen.
Trace 2 ist D_ab

Sind 700Hz angelegt, ergibt sich folgendes Bild:

700Hz_an_def1.png

Trace 1 ist der Kontrollstream 700Hz, am Frequenzgenerator abgegriffen.
Trace 2 ist D_ab

Nach kurzer Zeit zeigt sich jedoch folgendes Bild:

700Hz_an_def2.png

Trace 1 ist der Kontrollstream 700Hz, am Frequenzgenerator abgegriffen.
Trace 2 ist D_ab

Trotz gleichbleibender Eingangsfrequenz von 700Hz fängt das SEU an, an D_ab einen Random-Bitstream auszugeben. Dieser wird natürlich vom Fernschreiber als gewollt interpretiert, in "eingehende Zeichen" umgesetzt und somit abgedruckt. Dummerweise wird dieser Bitstream auch erzeugt, wenn eine "vom Nutzer gewünschte" Verbindung besteht und mit dieser überlagert - daß da nur Käse herauskommt, dürfte klar sein.

"Also wunderbar - Der Fehler ist eingegrenzt, nur woher kommt das Ganze?"
Das gibt's im nächsten Post - dort machen wir aber erst noch einen Ausflug in die Funktionsweise des SEUs

[Baderbahn]

"Also wunderbar - Der Fehler ist eingegrenzt, nur woher kommt das Ganze? ... Und überhaupt, was macht das SEU denn eigentlich genau?"

Naja, ganz plump gesagt ist das SEU ein "Modem", welches die auf eine Grundfrequenz per FSK aufmodulierten Signale in einen von der Fernschreibelektronik lesbaren Bitstream umwandelt - und in Gegenrichtung den zu sendenden Bitstream auf die Sende-Grundfrequenz aufmoduliert - schauen wir uns das doch mal an:
(Disclaimer: Die Beschreibungen und Abbildungen dienen dazu, das grundlegende Funktionsprinzip des SEUs zu verdeutlichen - Fehler können und werden durchaus vorhanden sein, bitte korrigiert mich! Eine exakte Beschreibung des SEU ist im Reparaturhandbuch Teil 2, ab PDF-Seite 15 zu finden)

Am Signaleingang (Pin 2 und 3) wird mittels Gabelübertrager und angehängter Leitungsnachbildung der Pegel eingestellt, sowie der Sende- vom Empfangsstream separiert.

Gabeluebertrager.png

Nachgeschaltet ist ein aktiver Tiefpaß mit oberer Grenzfrequenz von 800Hz - hier werden die empfangenen Signale von etwaigen "Unreinheiten" "gesäubert"

Tiefpass.png

Weiter geht die Reise der Signale zum "Begrenzer-Verstärker" mit IC2 (Op-Amp LM709C) als Kernstück.
Der hier zum Einsatz kommende LM709C wandelt die eingehenden, sinusförmig ankommenden Signale in Rechtecksignale um.

Begr_Verst.png

Die nun als Rechtecksignal vorliegenden Daten sind so noch nicht für den Fernschreiber lesbar. Deshalb werden durch diverse Logikschaltungen die Nulldurchgänge ermittelt, und im Anschluss die Amplitunden frequenzunabhängig und gleichwertig ausgegeben, abgeglichen und dem nachfolgenden Integrationstiefpaß zugeführt. Hierfür sind hauptsächlich div. Transistoren sowie die Op-Amps (MC1458C) IC 3 und 4 zuständig.

Nulldurchgangsdiskriminator.png

Die sich hieraus ergebenden Signale werden nun mittels Impulsformer/Schwellwertschaltung in grundsätzlich fernschreiberlesbare Bitstreams umgesetzt und verlassen durch einen Ausgangsverstärker das SEU in fernschreiberlesbarem Pegel und Datenformat.

Ausgangsstufe.png

Nun haben wir empfangene Signale in für unseren Fernschreiber lesbare Bitstreams gewandelt - schauen wir uns noch die andere Richtung an...

Mittels ein paar Widerständen ist die Sendeseitige Eingangsschaltung relaisiert:

Eingangsschaltung.png

Die eigentliche Umsetzung von Rechtecksignalen zu sinusförmigen Signalen erfolgt mittels Frequenzumtastung und Oszillator.

Frequenzumtastung.png

Im Anschluß an den Oszillator finden wir noch einen aktiven Hochpaßfilter samt Entkopplungsstufe, der Hochpaßfilter dämpft die bei der Frequenzumtastung zwangsläufig entstehenden tiefen Anteile, die Entkopplungsstufe dient der Potentialtrennung.

Hochpass.png

Somit sind wir wieder beim Gabelübertrager angelangt, über welchen das generierte Signal in die Anschlußleitung eingespeißt wird.

"Puh... und das auf der Platine... Aber was war denn jetzt eigentlich defekt ?!"

Das geht kurz und knackig, passt aber nicht mehr in diesen Post

[Baderbahn]

"So, was war es denn nun?"

Nachdem mir das Funktionsprinzip klar war, habe ich den Signalweg mit Oszis Hilfe nachverfolgt und konnte als Fehlerquelle IC2 (LM709C) ausmachen. Das Verhalten deutet auf anfangende Korrosion im Innern hin. Ersetzen des Op-Amps mit anschließendem Testlauf auf dem Labortisch konnte das Problem beheben.
Da durch IC2 alle eingehenden Signale laufen, hat er die nachfolgende Logik, welche den Bitstream erzeugt "ausgetrickst".

Links der alte, rechts der neue IC:

LM709C.png

Die Meßergebnisse:

1658747621009.jpg

HANTEK Trace 2: D_ab bei 500Hz
HP Trace 1: D_ab bei 500Hz vor Ausgangsverstärkung
HP Trace 2: 500Hz Kontrolle

1658747621023.jpg

HANTEK Trace 2: D_ab bei 700Hz
HP Trace 1: D_ab bei 700Hz vor Ausgangsverstärkung
HP Trace 2: 500Hz Kontrolle


Zu guter Letzt noch der Meßaufbau an der Platine:

1658747620995.jpg

Ich hoffe, Euch nicht gelangweilt und ein Wenig Einblick in das "Schalten und Walten" des SEU gegeben zu haben!
Mit dem nun reparierten SEU funktioniert mein LO2000 wieder wunderbar - der Teilnahme am i-Telex steht somit nichts mehr im Wege.
Gerne kann ich versuchen zu helfen, sollte jemand ein defektes SEU-B haben. Der Meßadapter ist da und einsatzbereit.

Ich werde ersteinmal wohl nur am Abend erreichbar sein, aktuell möchte ich den Lorenz nicht unbeaufsichtigt laufen lassen. Weiter werde ich mir noch eine Stromsparschaltung bauen, um nur den RaspberryPi dauerhaft mit Strom versorgen zu müßen.

Viele Grüße und vielen Dank für's Lesen,
Simon

P.S. Wie funktioniert das mit der Eintragung ins Verzeichnis?

[Franz]

Hallo Simon, einfach mit den gewünschten Daten sich an Fred wenden, der trägt dann alles ein....


siehe auch hier :

http://tlnserv.teleprinter.net/

VG
Franz

[WolfgangH]

Hallo Simon,

saubere Arbeit und schöne Ausrüstung. Respekt! Von mir aus bekommst Du den Titel Dr. SEU.

Bei der Fülle an Fehlern muß der Fernschreiber wohl mal einen Blitzschlag abbekommen haben.

Nun freue ich mich, wenn Du bald am Netz bist.

[MCMLXXV]

Oha - alle Achtung! Also da hätte ich weder das Knoff-hoff noch die Ausrüstung um so tief ins Detail zu gehen. Alle Achtung!

Naja - aus dem Lehrberuf bin ich halt lange genug raus.... :-(