Da die alte Mitgliederkarte schon lange nicht mehr vom Entwickler gepflegt wird und mit der kommenden Umstellung auf php 8.x überhaupt nicht mehr funktionieren wird, habe ich mich für eine andere Lösung über Geonames.com entschieden. Die Karte bietet mehr Features, einen integrierten Event-Kalender und POI-Marker, ist also um einiges komfortabler und flexibler. Leider lassen sich die Daten aus der alten Karte nicht in die Neue übernehmen, wobei dort aber auch fast 50 falsche Einträge (mitten im Meer, der Wüste und sonstwo, wo sicherlich keiner wohnt) gesetzt worden sind. Daher würde ich gerne alle bitten, die weiterhin auf der Benutzerkarte verzeichnet sein wollen, in UCP (User Control Panel) den eigenen Standort durch Eingabe des Landes und der Postleitzahl neu zu setzen.
Die Karte kann über diesen Link oder über einen Klick auf das Icon in der Navbar des Forums aufgerufen werden.
---
As the user map has not been maintained by the developer for a long time and will no longer work...
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.
Hallo zusammen,
ich stehe vor einem kleinen Rätsel und hoffe, jemand aus der Runde kann mir helfen.
Ich habe für die Linienstromversorgung von piTelex ein einfaches ungeregeltes Netzteil, bestehend aus
- einem Trafo 230V/2x30V 80mA
- Einem Brückengleichrichter DF08M (800V 1A) (ja, zu groß, aber in der Bastelkiste vorhanden...)
- einem Siebelko 330 µF 200V=.
Einfacher geht nicht.
Der Trafo hat eine Leerlaufspannung von knapp 40V~ je Wicklung, das ergibt bei in Reihe geschalteten Sekundärwicklungen 80V~ und damit ergibt sich die Leerlaufgleichspannung des Netzteils zu 80V~ * 1,41 = 113V, wenn man von idealen Dioden ausgeht.
Tatsächlich liefert das Teil auch knapp 112V --> passt.
jetzt kommt die Magie:
Lasse ich das Netzteil ohne Last laufen, so schaukelt sich die Leerlaufgleichspannung langsam und gemütlich, aber unaufhaltsam über die oben berechnete und gemessene Leerlaufspannung hoch, teilweise bis auf 180V=.
Ein parallel geschaltetes Voltmeter mit einem Innenwiderstand von...
hier nun mal etwas ganz spezielles. 2016 habe ich angefangen einen i-telex-Adapter für meine mechanische Telex-Vst zu bauen. Damals war der Raspberry gerade in aller Munde und das ideale Bindeglied zwischen Netzwerk und GPIO- Aus/-Eingängen. Wie das verlaufen ist, schildert das anliegende Dokument aus 2017, etwas überholt 2019. Bitte legt nicht jedes Wort auf die Goldwaage, in der Zwischenzeit haben sich manche Dinge verändert. Da diese Entwicklung nur durch tiefe Einarbeitung in das i-telex-Protokoll möglich war, entstand natürlich ein reger Schriftverkehr mit Fred.
Ihm habe ich auch damals schon einige Bilder geschickt. Er meinte, ich soll das Thema mal im Forum einbringen. Ich habe es dann halt bis heute nicht gemacht, da so eine Doku oft mehr verwirrt denn intensiv gelesen wird. Es ist halt sehr fachspezifisch und dürfte Nichtfernmeldern (also fast allen) kryptisch vorkommen. In der Zwischenzeit habe ich noch zwei EMD-Vst'n dazubekommen, die ebenfalls so angeschaltet...
ich weiss nicht, ob sie es schon wussten... aber mein i-Telex läuft nun seit etwas über 24 Stunden problemlos. Danke and Fred und Henning für die unendliche Geduld und die Entwicklungsarbeit und die Doppelstrom-Schnittstelle.
Nun habe ich in meinem I-Telex eine TW-39 und Serielle Karte. Da die serielle Karte ja, nebst der tollen Anrufbeantworter-Funktion auch sonst recht praktisch ist, und ich Johannes' tolles Terminal schon kannte, dachte ich mir... Gut, das benutze ich jetzt.
Leider stehen mein I-Telex und der PC an entgegengesetzten Seiten des Büros. Noch ein Kabel? Nö, sagte ich mir. Das geht bestimmt auch anders.
Der Raspberry PI der mir mit PiTelex für meine ersten Gehversuche im I-Telex-Natz gedient hat, lag nun untätig und bequem neben dem I-Telex. Natuerlich kann ich den seriellen Anschluss des I-Telex mit dem PI verbinde, klar, dazu hat man ja genug USB auf SER kabel im Hause rumliegen. Dann konnte ich per ssh au den raspberry, und dan mit minicom lokal die...
Probably something for Fred, but posted here for general interest as well.
In the UK there are a lot of T1000 machines, all of these have a 6-0-6 interface as standard.
I have been repairing some of these machines over the past couple of weeks - I have been able to identify the connections to the Line Card from the special Cannon Connector, and have been feeding the RO machines with RS232 levels from my telegraph tester.
To interface to I-Telex, there will need to be a special interface card for RS232 - I think nothing more complicated than using a MAX232 to be driven and drive the opto that is a standard across the interfaces.
Software should allow for keyboard dialling, so I guess FSG-o-FSG will work for this application.
Also it would be very nice to be able to have the motor control feature if there are enough IO left on the interface - perhaps the on board relay of the TW 39 card could be repurposed to act as a motor contactor or SSR drive line?
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 hatte mal ein Java-Skript an Hand einer Dokumenmtation gebastelt, die ich jetzt nicht mehr finde. Aktuell komme ich nur auf:
. Es gab aber mal eine Seite, die etwas ausführlicher und die Kommunikation mit dem Teilnehmerserver besser beschrieben war - wo könnte ich die denn nochmal finden?
Wo jetzt die Abende wieder etwas länger werden und ich mit Python noch nicht klar gekommen bin, wollte ich die Testschaltung vom PiTelex nehmen und das ganze mal in Java probieren - es soll ja bald wieder bezahlbare Raspis geben.
Was mich auch auf die zweite Frage bringt.... gibt es ev. Teilnehmerserver für den Testbetrieb, die man maltretieren könnte?
Habe die Angewohnheit meine Fernschreiben gerne mal mit dem Editor zu schreiben, dann mit JTerm zu meinem EL35 zu schicken (Paste/Send) und den Streifen dann mit einer Maschine zu versenden. Das Zeuch will ja alles mal bewegt und verwendet werden und man hat im Normalfall fehlerfreie Texte versendet. Bei den neueren Versionen fehlen vor allem bei längeren Texten gerne mal Zeichen im hinteren Bereich. Da kommt dann teilweise ziemlicher Quark raus.
Der Fehler titt bei der aktuellen 10er Version auf aber auch bei der Vorgängerversion 6.0.9 mit Rundsenden, wo die Lampen so schön mitflackern (alles Steampunk :D ) .
Bei einer älteren Version aus 2019, die sich als 6.1.5 Steampunk ausweist tritt das Problem nachweislich nicht auf. Der Fehler ist intern reproduzierbar und auch die Felerfreiheit der 6.1.5.
Habe nämlich gerade einen Streifen mit den Fehlern versendet. Die identischen Fehler sind auch schon im Fenster vom Terminal zu sehen (aber nur wenn man es sich anguckt,...
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...
Im i-Telex werden ja üblicherweise die Original-Rufnummern der Fernschreiber möglichst beibehalten.
Inzwischen sind mehrere Maschinen aus dem Telegramm-Netz am i-Telex angeschlossen. Die Original-Nummern sind meist nur vierstellig, das geht im i-Telex nicht, da die Nummern mindestens fünfstellig sein müssen.
Ich würde nun vorschlagen, einen zweistelligen Präfix für diese original Telegrammmaschinen zu bestimmen.
Aber welche?
Am besten eine Kombination, die im alten Telex-Netz nicht vorkam.
Da ja Streifen von Kennungsgebern (je nach Typ) Mangelware sind und selbst wenn dies nicht der Fall sein sollte man es ja dazu nicht kommen lassen muss, habe ich mir mal eine Tabelle gebaut, die Zeigt was man aus den jeweiligen Streifen noch so machen kann.
In der Tabelle sind kein Makros nur normale Exel-Formeln.
In Zeile 2 trägt man einfach ein, welcher Buchstabe bereits geknipst ist. (Nur Buchstaben ... Zahlen bitte wie Buchstaben betrachten!)
In den Zeilen darunter erscheinen dann die Zeichen, die man aus dem Streifen noch machen kann.
In den grünen Feldern sieht man welche Buchstaben, Zahlen und Sonderzeichen noch möglich sind (mit entsprechender Knipsung aus Spalte G).
In der Blauen Feldern sind die möglichen Buchstaben, Zahlen und Sonderzeichen gelistet, die Möglich sind, wenn man außer Knipsen die Streifen auch umdrehen kann (nicht bei jedem KG möglich).
Es gibt 20 Blöcke, so das man auch KG ohne herausnehmbare Streife abbilden kann.
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.
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.
Hat irgendjemand das MicroTelex von im richtigen Einsatz, also am I-Telex-Netz und Fernschreiber angeschlossen. Ich haette da naemlich gerne mal ein paar Problemchen. :ent:
Ich bin ganz neu hier im Forum und habe erst seit kurzem einen LO15 mit iTelex laufen. Ich traue mich jetzt aber doch mal aus der Deckung.
Wenn man einen Fernschreiber hat, will man den auch mal zeigen. Nun kann ich ja nicht ständig einen von Euch nerven und anschreiben. Das DWD Wetter ist aber schon mal eine gute Sache.
Da ich nebenbei auch noch hobbymäßig fliege und gehört habe, dass es noch einige andere Piloten hier gibt, habe ich mal versucht, die standardisierten Infos zum aktuellen Wetter (METAR) und zu Kurzfristvorhersagen (TAF) an Flugplätzen per Fernschreiber abrufbar zu machen.
Im Moment lasse ich dazu ein Pythonprogramm dafür auf einem Notebook an der seriellen Schnittstelle der TW39 plus-Karte laufen. Das könnte auch auf einem Raspberry laufen. Ich habe aber mit Willi gesprochen. Denn es wäre natürlich wesentlich besser, wenn so ein Dienst auf seinem Super-Diensteserver laufen könnte. Willi will mal versuchen, das zum Laufen zu bringen. Wäre natürlich toll.
ich stelle hier mal mein i-Telex mit ESP32 für einen einzelnen TW39-Fernschreiber vor.
Das Gerät habe ich bereits im Frühjahr letzten Jahres gebaut und auch das Programm erstellt. Dies ist das zweite Gerät, gebaut im August 2020, mit leicht veränderter Hardware für das Museum Telekom-Historik (telekom-historik.de). Wir brauchen dort ein Interface für nur einen Fernschreiber. Das Original i-Telex wäre zu aufwendig gewesen.
Realisiert wurde dieses Gerät mit einem Mikrocontroller vom Typ ESP32, mit dem eine WLAN-Anbindung sehr leicht möglich ist. Ich verzichte hier aber auf den WIFI-Manager. Die WLAN-Zugangsdaten sind fest im Programm gespeichert.
Die Stromversorgung erfolgt mit 3 Schaltnetzteilen. Für die 60V-Versorgung wurden zwei 24V-Netzteile auf jeweils 30V gebracht und in Reihe geschaltet. Wegen möglicher Störfrequenzen wurden die Netzteile mit einer Metallhaube versehen.
Die Hauptplatine enthält neben dem Mikrocontroller-Modul weitere Module und die Ansteuerung des...
Ich bin gerade dabei, meine i-Telex-Routinen zu optimieren und brüte gerade über diesem Absatz aus der Protokollbeschreibung:
Note: Nomally the called i-Telex station prints out the current date and time after starting the local printer. To indicate that there is some data to print the first acknowledge data packet sent by the called station doesn't start with data byte of 0. But as soon as this locally generated text is completely printed the called station sends the acknowledge data packet with value 0 (so 06 01 00).
If the calling station started to transmitting data before the locally generated text was printed, the acknowledge packet with data byte 0 may be omitted.
Fred, kannst du das nochmal erklären? Ich verstehe es einfach nicht. ;)
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.
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...
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?
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...
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.
