Nachdem die Probleme der durchrutschenden Druckwerkskupplung behoben waren, konnte der Kommunikationsfähigkeit des Fernschreibers mit anderen Fernschreibgeräten alle Aufmerksamkeit geschenkt werden.
Im Grunde steht hierfür nach Abschaltung des deutschen Telex-Netzes im Jahre 2007¹ nur die Möglichkeit des Anschlusses an das von Hobbyisten betriebene I-Telex-Netz bereit. Um daran teilnehmen zu können, wird eine simulierte Vermittlungsstelle benötigt, an welche der (oder die) lokalen Fernschreibgeräte angeschlossen werden. Hierfür gibt es neben der direkt auf der I-Telex- Webseite beziehbaren Lösung die Lösung des Anschlusses mittels RaspberryPi Microcomputer (oder eines Derivats) - das PiTelex.
Aufgrund der einfachen Verfügbarkeit sowie des geringen Kostenaufwands entschied ich mich für die Anbindung via PiTelex.
Hierfür wird beim vorliegenden Fernschreiber, welcher mittels "modernem" ED1000-Potokoll² mit der Welt spricht, neben dem Pi nur eine USB-Soundkarte und ein paar passive Bauteile³ benötigt.
Anmerkung: Seit kurzem gibt es eine weitere Möglichkeit, den Fernschreiber via Pi an das I-Telex-Netz zu koppeln - Infos hierzu in den Anmerkungen zu diesem Beitrag.
Nachdem die benötigte Schaltung aufgebaut, PiTelex installiert und der Fernschreiber mit dem Pi verbunden war, setzte schnell Ernüchterung ein: Nichts geht! Der Fernschreiber und der Pi reden nicht miteinander.
Nach Studieren der mir vorliegenden Serviceunterlagen stellte sich heraus, dass in der Eingangsfilterplatine nicht der Norm enstsprechende Leistungswiderstände4 verbaut waren - also wurden diese umgehend ausgetauscht.
Nach Tausch der Widerstände konnte endlich hin- und hergeschrieben werden, die Nummer der Originalkennung "27161 wogro d" wurde sodann im I-Telex-Netz registriert und der Fernschreiber scharfgestellt.
Nach kurzer Betriebszeit zeigten sich jedoch wieder Probleme - der Fernschreiber fing sporadisch an, während laufender Verbindungen nur noch Mist zu schreiben. Eine Kontrolle im PiTelex-Log offenbarte: Die Zeichen werden nur lokal im Fernschreiber erzeugt, nicht von PiTelex versandt, auch trat der Fehler im Lokalbetrieb nicht auf - das Problem musste also tiefer in der Fernschreiberelektronik verborgen liegen!
Nach erneutem Studium der Serviceunterlagen wurde kurzerhand ein Messadapter gebaut, um die SEU-B-Karte (Sende-Empfangs-Umsetzer) - also die Karte, welche den Fernschreiber mit der Außenwelt verbindet - auf dem Labortisch prüfen zu können.
Zur Spannungsversorgung dient ein ausgedientes ATX-PC-Netzteil - das liefert alle Spannungen 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 im Servicehandbuch aufgeführt sind diverse Prüfspannungen, welche nach Herstellen der Betriebsbereitschaft des SEUs kontrolliert werden können (...und natürlich wurden...):
Wie aus der Tabelle zu erfahren ist, kann an Pin 15 geprüft werden, ob der SEU korrekt auf die Empfangsfrequenzen reagiert.
Ein kurzer Blick in den Schaltplan5 verrät uns, dass Pin 15 "Dab" (Rechte Seite, obere Hälfte) den Datenstrom, welcher FSK-moduliert auf das SEU trifft, als "normalen, seriellen Bitstream" an die Elektronik des Fernschreibers weiterreicht - das Äquivalent in Gegenrichtung wäre Pin 12 (Dan):
Um ansehen zu können, was an Dab an die Fernschreiber-Elektronik weitergereicht wird, habe ich also an Pin 15 das Oszi angehängt:
Bei 500Hz Empfangsfrequenz sieht die Sache wie folgt aus:
Trace 1 ist der Kontrollstream 500Hz, am Frequenzgenerator abgegriffen.
Trace 2 ist Dab
Sind 700Hz angelegt, ergibt sich folgendes Bild:
Trace 1 ist der Kontrollstream 700Hz, am Frequenzgenerator abgegriffen.
Trace 2 ist Dab
So weit so korrekt - nach kurzer Zeit zeigt sich jedoch folgendes Bild:
Trace 1 ist der Kontrollstream 700Hz, am Frequenzgenerator abgegriffen.
Trace 2 ist Dab
Trotz gleichbleibender Eingangsfrequenz von 700Hz fängt das SEU aus heiterem Himmel an, an Dab 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 - dass da während einer aktiven Verbindung nur Käse herauskommt, dürfte klar sein.
Auf die Aufarbeitung des Fehlers und der zugrundeliegenden Funktionsweise des SEU-B möchte ich im Folgeartikel näher eingehen - das sprengt sonst den Rahmen...
Fußnoten:
¹ Siehe Wikipediaartikel zum Thema Telex: https://de.wikipedia.org/wiki/Telex#Telex_in_Deutschland
² Beschreibung des ED1000-Standarts im I-Telex-Wiki: https://wiki.telexforum.de/index.php?title=ED1000_Verfahren_(Teil_2)
³ Siehe: https://github.com/fablab-wue/piTelex/wiki/HW_ED1000
4 Korrekt sind 33Ohm/3W
5 Der Schaltplan liegt im Downloadereich als *.PDF bereit: Schaltplan SEU-B
Der obige Beitrag, sowie die gesamte Lo2001-Serie überschneidet sich in Teilen mit den Beiträgen im I-Telex-Forum oder wurde Abschnittsweise daraus übernommen
Anmerkung Kommunikation zwischen Pi und Lo200X:
Seit kurzem gibt es neben der beschriebenen Möglichkeit den Fernschreiber über das originale ED1000-Verfahren anzusprechen auch die Möglichkeit, die Umsetzerelektronik (SEU-B) gegen ein Adapterboard mit darauf aufgesetztem Pi zu eretzen und den Fernschreiber via RS232 bei bis zu 100 Baud zu betreiben - siehe: SEU-M
Simons Technikblog
Im vorigen Beitrag wurde das Fehlerbild des Sende-Empfangs-Umsetzers betrachtet - nun will ich die grundsätzliche Funktionsweise des SEU-B umreißen, sowie die eigentliche Fehlerursache darstellen. Für diejenigen Leser, die nur an der Ur ...