unter der 881199 läuft nun schon seit geraumer Zeit, der klkl Server auf ita2/Baudot Basis.
Bis dato bestand der Nachteil darin, dass dieser Server nur einen Abruf verarbeiten konnte.
Wenn ein zweiter Anrufer den Dienst benutzen wollte, erhielt er ein OCC.
Dank Willi (Fernschreiber) ist dieses Problem nun gelöst.
Es wurde ein Portrouter vorgeschaltet, der die Anfragen auf die entsprechenden Python Prozesse (kann beliebig skaliert werden) weiterleitet.
Ich möchte Euch bitten diesen Dienst, unter 881199 einmal zu testen.
An der Benutzung hat sich nichts geändert.
Sollten diese Tests erfolgreich sein, würde ich gerne langfristig gesehen, den klkl Dienst unter 881188 ASCII ebenfalls auf ita2 umstellen,
da der Aufwand für die Pflege von 2 Systemen doch recht hoch ist.
Der Baudot/ASCII Art Dienst wird ebenfalls auf ita2 umgestellt werden, ich werde zu gegebener Zeit eine entsprechende Info im Forum hinterlegen.
da nun doch so einige Implementierungen vorhanden sind, die das i-Telex-Protokoll verwenden, möchte ich hier einen entsprechenden Diskussions-Faden aufmachen.
Generell ist unter den folgenden Links stets eine aktuelle Protokoll-Beschreibung aufzufinden:
Gleich zur Abgrenzung: Das Protokoll zur Teilnehmer-Server-Kommunikation ist dort zwar auch beschrieben, sollte aber bei Bedarf an anderer Stelle diskutiert werden.
Alle Entwürfe zu Diskussion von Neuerungen werden hier eingestellt:
Angeregt durch diesen Beitrag schreibe ich gleich mal die erste Erläuterung zum Versions-Paket:
Bisher ist tatsächlich nur Version 1 genutzt, wobei gerade eine Erweiterung auf Version 2 in Arbeit ist. Entwarnung vorweg: Version 2 ist nur für Spezialisten sinnvoll und wird voraussichtlich in das original i-Telex nicht integriert werden.
Das Versions-Paket hat den Zweck, dass Erweiterungen machbar sind, ohne dass alle Anwender des i-Telex wegen Inkompatibilität ausgeschlossen...
der Verein Telekom-Historik e.V. betreibt in Bochum ein Telefonmuseum (www.telekom-historik.de). Wir besitzen eine funktionsfähige Telex-Vermittlungsstelle vom Fernmeldenotdienst, mit der wir unseren Besuchern die TW39-Fernschreiber vorführen können. Leider können ED1000-Fernschreiber nur in Festverbindungen präsentiert werden. TW39-Baugruppen z.B. für den Siemens T1000 scheint es leider nicht mehr zu geben.
Ich beabsichtige nun einen Konverter von ED1000 auf TW39 zu bauen. Dafür benötige ich eure Hilfe.
Es müssen ein TW39-Fernschreiber und eine ED1000-VST simuliert und gekoppelt werden. Die Kopplung kann softwaremäßig mit einem Arduino erfolgen. Für die Anpassung an die Schnittstellen muss natürlich entsprechende Hardware gebaut werden. Hier mal mein erster Entwurf.
Probably a question for Fred, but very happy for anyone to comment.
Attached is a small section that describes how the UK telex system interprets the various states of the S and R wires on telex lines - this I think is important for UK FSG to work with I-Telex.
Sadly programming is well beyond my grasp - I am still developing a single to double current converter with Jeff, but would also still like to see a direct implementation within I-Telex.
What other areas of development are a problem from making this easy to solve?
wie von Fred angeregt habe ich in einem ersten Schritt die i-Telex-Gesamtbeschreibung aufs Wiki portiert. Fertig sind Gliederung und Formatierung, es fehlen noch die Bilder -- gibt es die irgendwo als Datei oder soll ich die einfach aus dem letzten Word-Dokument herausziehen?
Die Maßgabe dieser Version war erstmal, alles möglichst unverändert ins Wiki zu übernehmen, so dass man danach gemeinsam daran feilen kann. Gerade bei der Formatierung der Drucktexte musste ich Kompromisse eingehen (ohne Anspruch der Absolutheit). Ich bilde mir ein, gerade z.B. die Tabellendaten hinreichend sorgfältig übertragen zu haben, bin aber für Gegenprüfungen dankbar. Ansonsten bin ich offen für Kritik beider Vorzeichen.
Nächster Schritt wäre die Anleitung der Ethernetkarte, die ja aus der Gesamtbeschreibung ausgegliedert wurde.
Ich wollte hier auch mal ein kleines, nicht ganz unproblematisches Programm vorstellen und um eure Meinung bitten.
Zum Testen meiner i-telex-Verbindung und um das Protokoll zu verstehen, habe ich ein i-Telex-Terminal für Windows geschrieben.
Das funktioniert ganz ähnlich wie Johannes JTerm, braucht aber kein i-Telex. Es verbindet sich direkt über Netzwerk mit einem anderen i-Telex-System.
Natürlich ist es nicht so schick wie JTerm, es ist ja auch eher als technisches Tool gedacht.
Normalerweise veröffentliche ich meine Quellen auf GitHub. Bei diesem Programm habe ich nun Bedenken.
WinTelex holt sich nämlich automatisch die Teilnehmerdaten vom Server und deshalb kann damit jeder auf Knopfdruck eine Verbindung
zu einem beliebigen i-Telex-Teilnehmer aufnehmen und diesen zuspammen (das Senden von Ascii-Files ist natürlich auch implementiert :devil: ).
Andererseits finde ich gerade die schnelle Anwahl des eigenen Systems sehr praktisch.
Keine PANIK! Das Projekt soll NICHT das i-Telex-System ablösen! ;)
- piTelex
Ziel des Projekts piTelex ist die Anbindung eines FS an einen Raspberry Pi (RPi) oder PC (Windows oder Linux) und die Kommunikation weiter zu i-Telex oder anderen Internet-Diensten. Vorwiegend für einen einzelnen FS und zu Test-/Reparatur-Zwecken. Auch gut für Anfänger geeignet, da nur ein geringen und somit kostengünstiger Hardware-Aufwand.
Das Projekt hat sowohl einen Hardware-Part für die Ansteuerung eines FS als auch einen Software-Part für das Interface zur Hardware, die Kodierung der Zeichen und das Routen ins Netzwerk.
Ein Gemeinschaftsprojekt des FabLab Würzburg .
Software
Das Programm ist in Python3 (ab Version 3.5) geschrieben und läuft auf folgenden Plattformen:
Raspberry Pi (Zero bis 3B+) mit Raspian
Windows-PC
Linux-PC
Mac (noch nicht getestet)
Die Software ist in einzelne Module/Plugins unterteilt, die nur geladen werden, wenn sie benötigt werden. Es stehen folgende Module...
Nachdem ich letztes Jahr an einem Kennungsgeber für meinen T68 fast verzweifelt bin und ich unkreative Arbeiten wie das manuelle analysieren von Kennungsgebern und Kämmen hasse, hatte ich mir gleich ein Programm geschrieben, um das Analysieren zu vereinfachen und dabei gleich noch eine neue Wunschkennung aus den vorhanden Kämmen zu erzeugen. Das Programm war aber zunächst noch sehr fehleranfällig.
Beim Erzeugen der Wunschkennung versucht das Programm die Lösung zu finden, bei der am wenigsten Zähne ausgebrochen werden müssen. Dass wirklich immer die optimalste Lösung gefunden wird, kann ich aber nicht garantieren.
Ich habe das Programm jetzt nochmal überarbeitet und auf GitHub gestellt (wie üblich ein Windows-Tool):
Hinweise und Warnungen zur Verwendung hier:
Bitte seid vorsichtig mit dem Tool. Ich habe mir schon einige T68-Kämme ruiniert, weil das Programm anfangs noch einen gravierenden Fehler enthielt. Der ist jetzt zwar behoben, aber man weiß nie. Also bitte prüft nochmal...
Bei Tests ist mir aufgefallen, daß iTelex einen clientseitigen Verbindungsabbruch nicht korrekt ausführt. Die Verbindung wird seitens iTelex als verbunden gehalten und läuft dann auf einen Timeout.
SYN ->
ACK
-> RST
...
Zwischenzeitliche erneute Verbindungsanfragen werden zwar angenommen, aber sofort mit einem iTelex-Baudot-Paket OCC beantwortet und dann geschlossen.
Letzteres Verhalten ist gewollt, aber ersteres nicht. Erste Sichtung des IP-Stacks zeigt, daß offenbar ein RST-Paketflag eingehend überhaupt nicht behandelt wird. :wat:
nachdem ich den Bufferoverflow in i-Telex offenbar gefunden und behoben habe, will ich mir die defekte Implementierung des TCP-Handshakes beim Verbindungsabbau ansehen. Der Fehler tritt nur dann auf, wenn i-Telex die Verbindung schliesst, nicht im umgekehrten Fall.
Das ist auch der Grund warum die Webseiten der Karte so lahm sind, hier kommen nach meiner Analyse 2 Themen zusammen:
1. Der Webserver sendet connection: close im HTTP-Header mit, damit wird angezeigt daß nach diesem Element die Verbindung geschlossen wird und nicht über den gleichen socket weitere Daten ausgetauscht werden.
2. Der Webserver beendet dann nach Auslieferung eines Elementes die Verbindung durch senden von FIN, ACK (schliessen des sockets). Der Browser bestätigt mit ACK, beendet seinerseits die Verbindung durch schliesssen seines sockets und sendet damit seinerseits FIN, ACK, was der IP-Stack im i-Telex mit ACK zu bestätigen hat. Diese Bestätigung fehlt, sodaß clientseitig mehrere Retransmissions...
bin dieses Wochenende wieder einmal am Testen von piTelex (das alte Thema Acknowledge, Heartbeat etc.).
Mit meinem letzten Versuch ging soweit alles (auch der Rundsendedienst) -- bis auf den 1188xx-Diensteserver, die nach einigen Sekunden (nach KG-Abfrage, vor Hauptmenü) einfach kommentarlos die Verbindung auf TCP-Ebene trennt. Es kommt nichtmal ein End-Kommando.
So weit so gut, Übergang zur Fehlersuche mit Wireshark. Jetzt sind die Dienste aber plötzlich nicht mehr erreichbar (TCP-Verbindung wird abgelehnt) ...
:wat:
Habe ich mich zu oft verbunden und wurde gesperrt?
Bin ich in eine Wartung reingeplatzt?
Habe ich die Dienste abgeschossen?
Bin für jeden sachdienlichen Hinweis dankbar -- falls verfügbar, gerne ein Logauszug meiner Verbindung (Trennungsgrund?).
vorweg: Ich bin mir nicht sicher, ob meine Fragen hier richtig aufgehoben sind, da sich Entwickler- und Anwenderperspektive überschneiden, bei Bedarf bitte verschieben.
Heute kam ein Rundschreiben vom Rundsendedienst bei mir an, mit zwei Besonderheiten:
Die für den Kennungsgeberablauf vorgesehene Zeit war sehr kurz, mein FS kam nicht mit und so gab es Zeichensalat
Die Sendegeschwindigkeit des Rundsendedienstes ist recht hoch, durchschnittlich ca. 80 Zeichen/s (gegenüber 6,7 Zeichen bei 50 Bd)
Zum Verständnis muss ich noch kurz etwas ausholen (eigentlich wollte ich das erst gesammelt vorstellen sobald es gut funktioniert). Meine T1000 am piTelex ist im Moment im Offline -Probebetrieb, d.h. sie ist aufgrund des hohen Standby-Verbrauchs normalerweise ausgeschaltet und bei eingehendem FS wird die Netzspannung per Relais zugeschaltet. Die Reaktionszeit des FS auf A=>Z-Wechsel verlängert sich dadurch von ca. 240 ms auf 2,4 s. Sobald die eingehende Verbindung...
Hallo,
wir entwicklen gerade ein einfaches Interface zur Kommunikation mit bzw. Emulation von TW-39 Geräten.
Bei den Bauteilen habe wir uns z.T. an der bestehenden TW-39 Karte orientiert.
Allerdings besteht die Platine im Grunde aus 3 getrennten Einheiten, die nach Bedarf bestückt und verschaltet werden können.
- Umpoler
- Unterbrecher
- Stromsensor (zwei Richtungen)
Netzteil, Stromberenzung des Schleifenstroms und ggf. weiter Enstörung muss getrennt zugeschaltet werden.
Auf die andere Seite kommt zunächst mal ein Arduino, später dann eventuell ein esp2866.
Oder ein Raspberry.
Oder der Arduino bekommt ein Ethernetshield.
Oder was ganz anderes ...
Anbei mal ein erster Entwurf.
Grüße,
Klaus + Paul
TW39-IF_sce.png
TW39-IF_cu.png
Bearbeitet von Moderator - Text angepasst/ergänzt nach Wünschen vom Autor
ich schraube gerade an meinem T1000 mit piTelex herum, an der Tastaturwahllogik. Wenn man z.B. mit Tastaturwahl eine nicht existierende Nummer wählt oder der angewählte besetzt ist, schaltet der FS bei piTelex einfach ab. Wie macht das i-Telex? In der Gesamtbeschreibung steht nur
Wenn die gerufene Stelle frei ist, läuft diese an und die Verbindung ist hergestellt. Wenn die gerufene Stelle besetzt ist, schaltet sich der eigene Fernschreiber wieder ab.
Ich weiß aber, dass es diverse Fehlercodes gibt und i-Telex auch einige davon umsetzt. Über den i-Telex-Quellcode bin ich zu folgenden Vermutungen gelangt. Das Ganze habe ich mit der Anleitung der T1000 abgeglichen, dort stehen kurze Beschreibungen einiger Fehler drin.
Fehlermeldung | Funktion i-Telex | Beschreibung in Anleitung T1000
-|-
occ | Gehende TCP-Verbindung zu Teilnehmer kann nicht hergestellt werden | Teilnehmer besetzt
nc | ModRuhe ( Nicht mehr über den Remoteserver verbunden ) | Leitung bzw. Vermittlung...
habe gerade softwaremäßig ein kleines Problemchen, das möglicherweise aus einem Missverständnis meinerseits der i-Telex-Spezifikation resultiert. Dort steht zum Acknowledge-Paket ja, dass damit grundsätzlich die Zahl der empfangenen Zeichen dem Anderen mitgeteilt werden soll, damit dieser einschätzen kann, wie viel noch auszudrucken ist.
Das interpretiere ich erstmal so, dass ich meine aktuelle Druck-Pufferlänge übermittle. Wenn sich also jemand zu mir verbindet und das erste Baudot Data oder Direct Dial sendet, drucke ich Datum/Uhrzeit und sende das erste Acknowledge-Paket mit einem Wert von 24, da Datum/Uhrzeit ja noch zu drucken sind.
Jetzt steht in der Spezifikation bei Acknowledge ganz unten noch folgendes (frei übersetzt):
Anmerkung: Normalerweise druckt die gerufene i-Telex-Station nach dem Einschalten des Fernschreibers das aktuelle Datum und die aktuelle Uhrzeit. Um anzuzeigen, dass es Daten zum Ausdrucken gibt, beginnt das erste Acknowledge-Paket nicht...
I like the lock feature but I think it is not working in the manner that I am attempting to use it.
I have three ports set up. Port 31 is the main port for my station. Calls to 80003, which is my teletype model 32, normally go to port 31. Port 33 is my Lorenz 15c. Port 34 is the serial port.
I am away from home. I did not want the teletypes pulling current while I am away, so I unplugged them from the I-Telex ports, pressed the lock button for ports 31 and 33 and headed out of the house. I set up forwarding order so when locked they would call 34, which is my serial port. I also set up the main 80003 number to call 34 instead of 31. This way I can check message when I am away! It is a very nice feature.
Some of it working. But there are problems:
1. One user tried calling me and reported that he is getting “OCC Occupied”. I will find out what number he tries calling. Also I do not know this message, so I have asked for more information.
Schon mehrfach wurden Wünsche geäußert, dass ankommende Anrufe auf Klingeln, Meldelampen etc. angezeigt werden sollen.
Mancher hat vielleicht schon selbst was ähnliches gebaut (LED abgegriffen oder mein Tipp: Bei der TW39-Karte die Relais-Spule anzapfen), aber alle diese Lösungen sind mit Nachteilen verbunden (beim Relais beispielsweise die Auslösung auch bei abgehenden Anrufen).
Folgende bessere Lösungen sind für mich für die Signalisierung vorstellbar:
a) Einer der Anschlüsse des Programmier-Steckverbinders der TW39- sowie ED1000-Karte (gg. auch Seriell) wird als Ausgang geschaltet und bei ankommenden Anrufen getriggert.
Vorteil: Individuelle Signalisierung je Endgerät möglich.
Nachteil: Selbstbau der Hardware erforderlich (ist aber nur ein Schalttransistor und ein Relais, ggf. reicht auch ein Halbleiterrelais).
Nachteil: Signalisierung wird auch bei internen Verbindungen ausgelöst.
b) Einer der Anschlüsse des Programmier-Steckverbinder der Ethernet-Karte wird als Ausgang...
Um die Motordrehzahl von mechanischen FS einzustellen wurde früher eine spezielle Stimmgabel mit 125Hz verwendet.
Mit einem kleinen Arduino-Projekt kann man für weniger als 5€ ein Stroboskop mit einem Arduino Nano, einer ultrahellen LED und einem Widerstand bauen.
Einfach die LED wie eine Taschenlampe auf die Stroboskop-Scheibe richten und Drehzahl einstellen - wie früher.
wie ist denn im originalen i-Telex die Logik hinter der Datumsmeldung im ASCII-Modus? Mit Datumsmeldung meine ich das Banner mit Datum und Uhrzeit, das vom Angewählten gedruckt wird.
Bei piTelex ist es aktuell so, dass das Banner generell dann gedruckt wird, wenn der Modus feststeht (Baudot oder ASCII) und ein Empfangstimeout passiert (wenige 100 ms).
Bei normalen Baudot-Telex-Verbindungen gibt es keine Probleme, weil der Angewählte i.d.R. das Banner abwartet.
Bei den automatischen ASCII-Meldungen, die man über den Teilnehmerserver abonnieren kann, schreibt die Gegenstelle ja sofort los. Mit der aktuellen piTelex-Implementierung gibt es meist kein Problem. Geht aber mal ein IP-Paket verloren, vergeht einige Zeit bis zur Retransmission, und die reicht um den Bannerdruck anzustoßen. Die weiteren Sendedaten vermischen sich dann schön damit.
Jetzt könnte man ja den Timeout einfach erhöhen. Andererseits sagt die i-Telex-Spezifikation, dass das Ganze so falsch läuft,...
Bei dem neumodischen Übertragungsverfahren ED1000 werden Tonpaare verwendet um die seriellen Daten auf die Leitung zu bringen. Früher wurden aufwendige elektronische Schaltungen gebaut um die Sendefrequenzen zu generieren und die Empfangsfrequenzen zu filtern und zu detektieren.
Wenn man heute mit einem Frequency-Shift-Keying ( FSK ) arbeiten will, ist der einfachste Weg eine Computer-Sound-Karte zu verwenden und die Kodierung/Dekodierung per Software zu lösen. Das einfachste InInterface zu einem FS ist eine USB-Sound-Karte, die man schon zwischen 5€ und 15€ bei Online-Händlern bekommt (wenn nicht Alle wegen Home-Office ausverkauft sind...). Die USB-Geräte gibt es in vielen Varanten - mit und ohne Kabel, Plastik- und Metallgehäuse - aber technisch/elektronisch sind alle gleich!
Für eine Pegel- und Leitungsanpassung genügen schon ein paar passive elektronische Bauteile:
Für die Auswerung von Frequenzen gibt es eine umfangreiche Python-Library SciPy , die zusammen mit NumPy...
der neue Dienste Server ist nun schon ein wenig in Betrieb.
Hier noch einmal, die Dienste die zur Zeit bereitgestellt werden:
881188 und 881199 ist der klkl Listenabruf. Der Content auf beiden Systemen ist identisch.
881166 ist der Baudot / ASCII Art Dienst.
881177 ist der Dienst, der Testtexte für den FS bereitstellt.
Alle Dienste verfügen über ein Menü, d.h, nach Austausch des KG 15 Sekunden warten, dann wird das Menu gedruckt.
Oder, nach KG Austausch direkt m für Menü gefolgt von WR oder ZL eingeben, oder wenn der Menüpunkt bekannt ist diesen direkt auswählen und mit WR oder ZL bestätigen.
Nach dem Druck des Menu könnt Ihr bei Auswahl entweder m für Menu oder einen weiteren Punkt auswählen.
Ich habe da so eine Idee, die mir im Hirn herumspukt. Da ich nun einen Lochstreifenstanzer mit RS232 Anschluß habe, kann ich demnächst viele schöne ASCII-Art Bilder nach BAUDOT -Art konvertieren.
Ich fände einen Dienst der, ähnlich wie der DWD Wetter Server, angerufen werden kann und ein Menu präsentiert, wo man die Bilder auswählen und lokal ausdrucken kann, toll.
Wäre sowas technisch machbar?
Ich hätte Lust, sowas mittelfristig technisch umzusetzen, könnte mir jemand der Spur nach erklären, ob und wie ich sowas machen muss?
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.
