Das neue Jahr nähert sich mit großen Schritten, und die Hostingkosten werden wieder fällig. Diesmal muss aber nichts gesammelt werden, da über das Jahr so viele spontane PayPal-Spenden zusammengekommen sind, dass die Kosten für das kommende Jahr schon gedeckt sind.
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...
SEU-M_close.JPEG SEU-M_open.JPEG
Ö-AGT
Ein Ö-AGT bietet alles was man zum Berieb eines WT39-FS braucht:
• Netzteil
◦ Geregelte 120V für Linienstrom (galvanisch getrennt)
◦ Geregelte 12V (bzw. ungeregelte 20V) für Versorgung der SEU-*-Karte
• H-Brücke im Linienstrom für Daten, Umpolung und Pulse
• Einschubrahmen für SES-B-Karte (bzw. jetzt SEU-M-Karte)
• ADo8-Dose
• Schuko-Dose (ungeschaltet, ohne Sicherung) und Schuko-Stecker
• Gehäuse für Wandmontage
• (Platz für weiter Gadgets: z.B. Stromspar-SSR)
• ADo8-Stecker (nach dem Umbau übrig)
Beim Reengineering des Ö-AGT hat sich ergeben, dass man ‚nur‘ noch einen Pegelumsetzer vom Microcontroller (3,3V) auf 0…12V benötigt, um sich mit einem FSG zu unterhalten – einschließlich Umpolung, Datenverkehr, Wahlbereitschafts-Puls, Nummernschalter-Impulse und Erkennung der Stromabsenkung. Das alles erfolgt über 2 Leitungen (TX, RX).
Weitere Nachforschungen haben ergeben, dass die SEU-B- und SES-B-Karten eigentlich mit RS232-Pegel...
SEU-M_LO_1.JPEG SEU-M_LO_2.JPEG SEU-M_LO_3.JPEG
Nachforschungen haben ergeben, dass die SEU-B-Karten (ED1000) als auch die SES-B-Karten (V.21, Österreich) mit RS232-Pegel (+/-12V) kommunizieren. So auch implementiert im LO2000/1, LO3000, T1000S.
So liegt es Nahe, ohne den Umweg einer SEU- oder SES-Karte sich direkt mit dem FS zu unterhalten. Dies war auch erfolgreich mit einem USB-Seriell-Adapter möglich.
Das verwendete Protokoll entspricht dem des ED1000-Standards:
• TXD High mit Pulsen: Schreibmodus / Kommunikation
• TXD dauer Low: Ruhemodus, Motor aus
• RXD dauer LOW: FS im Ruhemodus
• RXD High: FS möchte wählen
(Genauer Ablauf siehe i-Telex-Wiki – ED1000)
Wenn man eh dabei ist eine Platine zu layouten, liegt es nahe gleich die Treiber für RS232 vorzusehen. So kann die SEU-M-Karte mit einer Alternativbestückung direkt anstelle einer klassischen SEU-Karte in den LO2000 eingesteckt werden.
Je nach verwendetem Raspberry erfolgt die Netzwerkanbindung mit WLAN oder Ethernet....
Das Projekt SEU-M ist entstanden um die noch zahlreich verfügbaren österreichischen AGTs (Ö-AGT) als einfaches und preisgünstiges Interface zu TW39-FS zu nutzen. Der Name ‚SEU‘ (Sende-Empfangs-Umsetzer) ist angelehnt an die SEU-B-Katen, die in die modernen FS (ED1000) eingebaut ist. Das ‚M‘ steht für MicroController.
SEU-M ist eine Platine, die einfach in ein Ö-AGT eingesteckt werden kann – und schon hat man ein vollständiges Interface zwischen seinem FS und dem i-Telex-Netz. Ebenso kann die Karte eine SEU-B-Karte in einem ED1000-FS ersetzen und alle Aufgaben der VSt erfüllen. Die Platine ist vorgesehen verschiedene MicroController bis hin zum Raspberry Pi aufzunehmen.
Software und Hardware zu diesem Projekt sind OpenSource bzw. OpenHardware.
SEU-M_uC_base.JPEG SEU-M_uC_Zero.JPEG
SEU-M-Karte
Auf der Karte sind viele Alternativ-Bestückungen und einige Option vorgesehen.
Entsprechend dem Einsatzort sind 2 alternative Pegelwandler vorgesehen:
• ULN2003 mit 0…12V für Ö-AGT
•...
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?
vor ein paar Tagen hatte ich im Chat meinen BONTelex-Umbau erwähnt, welcher wohl doch auf Interesse stieß - aus diesem Grunde möchte ich hierzu einen Thread eröffnen.
Um Alle abzuholen um was es geht:
piTelex bietet die Möglicheit, mit unzähligen Geräten via RS232 bzw. RX/TX zu kommunizieren. Da mein Lo2001 nachts normalerweise abgeschaltet wird, wollte ich einen Nachtempfänger/Flüstertelex haben - da kam Jochen mit der Idee des BONTelex gerade recht.
Das BONTelex ist ein zum Telex-Empfänger umgewandelter Bondrucker - in meinem Falle ein EPSON TM88II Thermodrucker.
Der Drucker wird via TX vom Pi angesteuert (es gab den obig genannten Drucker jedoch ebenso mit anderen Schnittstellen (Ethernet usw.) ) in unserem Falle wird also die Version mit RS232 Schnittstellenkarte benötigt.
Um Bauteile einzusparen wird direkt das 3,3V-Signal des PI-Ausgangs hinter den MAX232 der Schnittstellenkarte eingespeist - hierfür muss leider auf der Platine gelötet werden...
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...
...so, ich hab noch n bisschen rumgemessen...
Mein momentanes Netzteil liefert 61 Volt (und bis zu 2 Ampere, was aber hier egal ist) (I-Telex: 88V)
Ruhestrom 0mA (I-Telex identisch)
Anruf kommt an: 0,7 mA (huh, deutlich zuwenig! Nichts reagiert!) (I-Telex 1,9 mA, intern zieht ein Relais an)
Anruftaste drücken, Maschine läuft an: Linienstrom einstellbar bis ca. 55 mA.
Ergebnis: gehn wir mit der Spannung höher... oder schaun wir mal unser Anschaltgerät genauer an. Laut Plan sollen das doch 5 mA sein...
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?
Ich habe mal wieder ein wenig Software gebastelt und ein kleines E-Mail / i-Telex Gateway gebaut.
E-Mails, die an die Adresse telex@telexgate.de gesendet werden, werden an die im Betreff aufgeführten i-Telex-Nummern weitergeleitet.
Die i-Telex-Nummer müssen mit Komma getrennt werden und jede Nummer beginnt mit '#' (also z.B.: #211230,#211231,#7822222)
Das ganz soll dann auch in die andere Richtung funktionieren, also Telexe an die i-Telex-Nummer des Gateway sollen an die in der Nachricht angegebenen E-Mail-Adressen weitergeleitet werden.
Gibt es Vorschläge für eine sinnvolle i-Telex-Nummer für den Dienst?
Parallel dazu habe ich auch ein alternatives Twitter-Gateway in Arbeit. Das ist aber etwas komplexer, deswegen wird das noch einen Moment länger dauern, bis das in den Testbetrieb geht.
Auch hier bitte ich um Vorschläge für eine i-Telex-Nummer.
es kann mal passieren, dass ein System unvorhersagbar arbeitet (z.B. ein Rundsendedienst), es könnte aber auch mal passieren, dass jemand einen i-Telex-Anwender ärgern oder schaden möchte. Um diese Unannehmlichkeiten zu beherrschen, habe ich folgende Idee und stelle die zur Diskussion.
Der Algorithmus wirkt nur bei kommenden Verbindungen. Er basiert auf einem Punktesystem. Punkte werden addiert, folgende Punktzahlen werden gewertet:
Jedes druckbare Zeichen hat 1 Punkt
Jedes nicht-druckbare Zeichen (Leerzeichen, Bu, Zi, NUL, WR) hat 0,25 Punkte
Jedes druckbare Zeichen hinter Position 69 hat 10 Punkte (Drucken auf dem Zeilenende ist böse)
Jedes druckbare Zeichen, das auf ein WR ohne ZL folgt (also auf der selben Zeile wie die vorherige gedruckt wird) hat 20 Punkte (gehört sich auch nicht)
Jedes ZV hat 30 Punkte (hohe Punktzahl um Papierverschwendung zu ahnden, ist aber in der Gesamtsumme für normale Telexe berücksichtigt).
I have the news service enabled,
This was a bit of a challenge.
My question:
How do I change the frequency of checking the news feed? To check either more often or less often.
I do not see anything for frequency in telex.json and not sure which module I would need to change??
Also.....
I would also like to change the ending of the stored NEWS telex messages from ++++ to NNNN (USTTY Standard)
And also eliminate the additional Line Feeds . When it stores the message it adds 2 extra line feeds before and
after the message this uses a lot of paper. <-Help save a tree! LOL!
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,...
Vorab erst mal: der Bildlocher ist spitze! Vielen Dank dafür.
Ich führe häufiger mal Kindern (im Kindergarten- und Grundschulalter) einen Fernscheiber vor.
Die Kleinen sind immer fasziniert von den sich bewegenden Teilen, dem Klappern und der Möglichkeit auch selber auf der Tastatur herumzutippen.
Als Highlight bekommen alle auf Lochstreifen ihrem eigenen Namen - einmal in Geheimschrift (Baudot-Code) und einmal lesbar per Bildlocher gestanzt.
Daraus basteln wir dann mit verschiedenfarbigen Lochstreifen Armbänder. Das ist immer DER Renner und die Kinder sind mächtig stolz!
20220902_102107_2.jpg
20220902_102429_2.jpg
Momentan muss ich die Eingabe des Namens aber selbst übernehmen, da die Kinder nicht schnell genug sind. Der Stanzvorgang beginnt ein paar Sekunden (3 Sekunden?) nach der letzten Eingabe. Da aber jeder Buchstabe zum Teil mehrere Sekunden lang gesucht werden muss, funktioniert das nicht gut. Auch ein Stanzen in mehreren Etappen geht nicht, da zu Beginn immer...
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...
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.
Einige werden es schon bemerkt haben, ich habe unter der Nummer 11162 einen weiteren Rundsender in Betrieb genommen.
Die Version mit englischer Menüführung unter der Nummer 11163 ist noch nicht eingerichtet bzw. liefert ebenfalls noch deutsche Menüs.
Warum noch ein Rundsender? Naja, eigentlich hatte ich den schon vor 2 Jahren geschrieben, bin aber nie so richtig dazu gekommen, ihn auszutesten.
Und eigentlich habe ich den jetzt nur fertiggestellt, um mit meinen alten Softwareroutinen wieder klar zu kommen und mit dem ganzen Thema wieder warm zu werden. Für ein etwas komplexeres Projekt: den Nachrichtendienst (siehe nächster Beitrag).
Was macht dieser Rundsender anders oder besser als die anderen? Naja, besser ist geschmacksache. Er macht halt einiges anderes. Er hat keinerlei historischen Anspruch und soll möglichst einfach und intuitiv bedienbar sein. Das war zumindest das Ziel. Für mich gibt es auch nicht den historisch korrekten Rundsender. Es gab in der frühen Zeit (genau...
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.
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...
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.
