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 habe für einen Interessenten aus dem Classic-Computing-Forum mal nach der aktuellen TW39-Hardware für piTelex geschaut. Also außerhalb vom Ö-AGT. ich bin etwas verwirrt.
Ich kannte nur diese Platine. Die hatte Jochen mir mal testweise zur Verfügung gestellt:
RPiTW39.JPG
Jetzt habe ich auf Github nach den Design- und Gerberdaten geschaut. Dort finde ich aber unter den Gerberdaten nur diese Variante:
Die sieht völlig anders. Es gibt kein Umschaltrelais mehr sondern eine H-Brücke. Zu dieser Hardware habe ich nie irgendwo eine Foto einer fertigen Platine gesehen. Also ist das jemals aufgebaut und getestet worden? Oder sogar irgendwo im Einsatz?
Welches ist denn neben dem Ö-AGT die aktuell getestete Hardware, zu der es auch Gerberdaten gibt?
ich habe ja mit der piTelex Platine ein wenig Schiffbruch erlitten.
Die Idee war, meinem LO-15 Empfänger einen Sender und damit auch gleich einen Anschluss in die piTelex Welt zu ermöglichen.
i-Telex läuft ja soweit, nur kann ich dort nicht senden.
Eines vorweg : Die Gehäuse stammen aus Bundeswehrbeständen und wurden teilweise als Leergehäuse, oder als außer Betrieb genommen und daher defekt angeboten. Einige waren vollständig intakt, die sind dann weitergegeben worden, aber einige waren wirklich zerstört (Kabelbäume durchtrennt, oder schlichtweg mit dem Hammer hineingeschlagen). Immer hin waren einige Taster und Nummernschalter intakt.
Solche habe ich hier weiter genutzt.
Für das Projekt, habe ich zwei Geräte gebaut:
1. ein Gerät mit einem sehr simplen Interface. (unten)
Interface neu.png
Hier wird das DTR Signal genutzt, um den FS einzuschalten (SSR, M1 M2).
Das TX Signal der RS232 Schnittstelle wird in ein Stromsignal gewandelt.
Die...
Hallo zusammen.
Tolle Sache, beides i- und piTelex, grossen Respekt! :grovel:
Ich habe noch ein paar Unklarheiten bezüglich Konfiguration:
Im piTelex-Wiki steht, dass man für die Aktivierung von Centralex einen Eintrag im Teilnehmerserver haben und die IP-Adresse dort als dynamisch gesetzt sein muss. Dazu muss ich nach meinem Verständnis den Wert von tns_dynip_number durch meine durch die Admins zugewiesene i-Telex-Nummer ersetzten, also 820028. Gemäss Warnung in telex.json soll man dies aber erst tun, wenn man die TNS PIN gesetzt hat. Ich wollte mich dazu mit den TNS verbinden wie im Wiki beschrieben , die Verbindung wird jedoch abgebrochen. Verstehe ich etwas falsch, oder was müsste ich als nächstes tun?
Vielen Dank für eure Klärung und Hilfe!
Aktuell verwende ich diesen Eintrag im telex.json für das i-Telex-Modul:
# Module type i-Telex
i-Telex : {
type : i-Telex ,
enable : true,
centralex : true,
port : 2342,
# WARNING
# Setting tns-dynip-number to anything except 0...
Ausgangslage
piTelex ist ein vielversprechendes, flexibles System zur Anbindung klassischer Fernschreiber an das i-Telex-Netz oder vergleichbare Kommunikationsplattformen. Es bietet günstige Einstiegsmöglichkeiten, hohe Funktionalität und aktive Weiterentwicklung.
Allerdings ist die Einrichtung des Systems für technisch interessierte Laien eine unnötig hohe Hürde:
Die Konfiguration erfolgt manuell über eine config.json
Der Benutzer muss das Linux-System selbst einrichten, Netzwerkverbindungen konfigurieren, Software installieren
Kenntnisse in Kommandozeile, Dateirechten, systemd und Konfigurationssyntax werden vorausgesetzt
Dokumentation ist zwar vorhanden, aber fragmentiert und technisch geschrieben
Konsequenz
Viele Interessierte mit ausreichendem technischem Grundverständnis – oft aus dem Amateurfunk-, Maschinenbau- oder museal-technischen Bereich – steigen trotz vorhandener Motivation nicht ein, weil ihnen die initiale Einstiegshürde zu hoch erscheint.
Die SEU-M-Karte funktioniert auch in einem Siemens T1000!
Die Konfiguration entspricht der vom Lo2000 (siehe
Durch die Kartenlänge von 100mm (statt160mm) steckt sie tiefer im Kartenslot. Die Buchsen für USB und Ethernet sind aber gut erreichbar. Ein HDMI-Kabel ist nicht möglich.
Es sind Baudraten von 50 bis 100 Baud möglich. Die 200 Baud werden korrekt dekodiert aber der T1000 hat nicht genügend Speicher zum Zwischenbuffern - deshalb gehen Zeichen beim Empfang verloren.
Gestern hat Detlef den bisherigen Testing-Zweig zum Master migriert. Der aktuelle Softwarestand wurde eingefroren in derm neuen
Release 2025-06
und kann heruntergeladen werden unter
Natürlich kann auch weiterhin der Masterzweig per git geklont werden.
Gegenüber dem bisherigen Master-Zweig mit Software-Stand Juli 2023 hat sich einiges an der Funktionalität verbessert.
Neben kleineren bug fixes sind die wichtigsten Neuerungen:
Endlich: Unterstützung des Centralex Protokolls !
Wichtig für alle Teilnehmer, die über keine echte IPv4-Adresse verfügen (DS-Lite)
Standardmäßiges Blockieren von Nicht- itelex-Verbindungen
Spam- und Portscan-Schutz können damit realisiert werden,
TNS Server sind konfigurierbar
Dabei kann jedem Server eine Priorität zugewiesen werden.
E-Mail-Benachrichtigung
Eine frei konfigurierbare Mail-Adresse über eingegangene Telexe informieren; Interessant besonders für Mehrmaschinennutzer
Gadget: Simulieren von handgetipptem Text
mit zufälligen...
Raspberry Pi auf SEU-M Karte bootet nicht zuverlässig – Ursache & Abhilfe
In manchen OE-AGT-Geräten zeigt sich das Problem, dass der Raspberry Pi auf der SEU-M Karte den Bootvorgang nicht zuverlässig abschließt. Typisches Symptom: ein wiederkehrender Greyout-Effekt – der Bildschirm wird grau, der Pi startet neu, und das Spiel beginnt von vorn, im Abstand von etwa drei Sekunden.
Die Analyse mit dem Oszilloskop zeigt: Die 5V-Versorgung des Raspberry bricht an einer bestimmten Stelle im Bootvorgang massiv ein. Besonders dann, wenn der Pi kurzzeitig hohe Ströme zieht – etwa beim Initialisieren von USB oder Netzwerk. Die Stromversorgung des OE-AGT ist in diesem Moment offenbar nicht in der Lage, diesen plötzlichen Leistungsbedarf abzufangen. Bemerkenswert: Das Problem tritt auch dann auf, wenn der zusätzliche +20V-Draht verbaut ist – es liegt also nicht allein an einem zu schwachen Trafo oder zu dünner Zuleitung.
Abhilfe:
Ich habe testweise einen 2200 µF / 60 V Elko direkt von Masse...
Wir stellen fest, dass etwa 20% der OeAGT zumindestens nicht ohne weiteres einsatzfähig sind.
Ich habe eines mit nem massiven Fehler in der -60V und eins was die Impulse nicht sauber formt. Am Dritten ist die Platine von Hand nachverdrahtet, man könnte meinen, da ist jede Leiterbahn einzeln repariert...
Das Design ist wohl von 1978 und inzwischen eher ... nuja.
Auch die 12-V-Versorgung ist eher schwach. Der Betrieb manches RPi ist kaum möglich weil der Trafo einfach zu schwach ist (Spannungseinbrüche bis runter auf 3 Volt messbar wenn RPi hochfährt).
Ich denke, auch hier kann man mal eine neue Hauptplatine entwerfen, die Netzversorgung, +/-60Volt und 12V (Evtl. auch +/-12V) zeitgemäß herstellt und auch die Stromsignale gescheit macht.
Eine H-Brücke ein paar Meanwell oder RECOM-Netzteile usw. dürften hier gute Dienste leisten.
Dazu könnte man ein paar zusätzliche Drähte vorsehen um die SEU-M weitergehend zu nutzen. Sei es um i2c (Echtzeituhr?) oder Schalteinrichtungen für die...
Wikipedia schreibt: Der Babelfisch (englisch Babel Fish) ist ein fiktives Lebewesen aus dem Roman Per Anhalter durch die Galaxis von Douglas Adams, das inzwischen zu einem bekannten Symbol für maschinenbasierte Übersetzungssysteme geworden ist. Der Babelfisch wird in dem Roman als kleines Wesen beschrieben, das sich ins Ohr einführen lässt und dem Träger ein Verständnis aller gesprochenen Sprachen ermöglicht. Dieses Konzept erklärt Adams, indem er den Babelfisch als Symbionten schildert, der sich von externen Gehirnwellen ernährt und deren Bedeutung er in Form von telepathischer Energie direkt ins Gehirn des Trägers ausscheidet. Den Namen Babelfisch lehnte Douglas Adams an die biblische Geschichte des Turmbaus zu Babel und der darauf folgenden babylonischen Sprachverwirrung aus dem Buch Genesis an.
piTelex wird bald auch so etwas können.
Du brauchst dazu einen OpenAI-API-Key und die entsprechende Version von piTelex
In telex,json wird eingefügt:
babelfish : {
type : babelfish...
Wie unter piTelex-Development schon geschrieben, habe ich mich mal dem Thema Centralex in piTelex angenommen.
Weil piTelex wirklich gut strukturiert ist, war die Funktionalität schneller eingebaut, als gedacht. Rolf und ich haben die neue Version heute morgen mit seinem piTelex getestet, und bis jetzt funktioniert alles bestens.
Es wäre schön, wenn noch mehr Leute mittesten würden, die wissen, wie man die piTelex-Software vom Server aktualisiert.
Die Version mit Centralex basiert auf dem aktuellen Testing-Branch.
Wenn man Centralex in der telex.json nicht aktiviert, sollte alles funktionieren wie bisher.
Wenn man einen Centralex-Server einträgt, dann laufen die eingehenden Verbindungen über Centralex ohne dass dafür eine öffentliche IPv4-Adresse oder eine Portweiterleitung im Router notwendig ist.
Es gibt im Projektverzeichnis eine Beispielkonfiguration unter dem Namen telex_centralex.json .
im aktuellen piTelex TESTING gibt es nun die Möglichkeit, einen Mailmelder für eingehende Telexe zu aktivieren.
Wie üblich ist das ganz einfach.
Der Mailmelder ist derzeit ein Teil des archive -Moduls. Dieses Modul speichert eigentlich alle ein- und ausgehenden Fernschreiben in einem Ordner. Damit der Mailmelder funktioniert, muss das archive zunächst aktiviert werden.
In der Konfigurationsdatei telex.json findet sich der Abschnitt archive . Hier ein Beispiel:
archive : {
type : archive ,
enable : true, # Nachrichten archivieren?
path : ./archive/ , # Verzeichnis für archivierte Nachrichten
send_email : true, # E-Mail-Benachrichtigung bei eingehendem Telex?
recipient : recipient@targetdomain.domain , # E-Mail-Adresse des Empfängers
# Mailserver-Daten:
email_sender : sendername@mailprovider.de , # Absenderadresse
smtp_server : smtp.mailserver.de , # SMTP-Mailserver (FQDN oder IP)
smtp_port : 587, # Port des SMTP-Servers (25, 465 oder 587)
smtp_user :...
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...
Wenn Euer Raspberry PI unter neuerem Linux-Image zicken macht und nicht auf ner SEU-M durchbootet, das aber tut, wenn er am Originalnetzteil angeschlossen ist...
Fehler: Raspi erkennt Unterspannung (Eingabe journalctl -f ergibt alle paar Augenblicke undervoltage... ) und bricht ohne Zusatzstrom das Booten ab.
Mit Zusatznetzteil läuft er hoch.
Lösung: In /boot/firmware/config.txt suche arm_boost=1 und ändere das in arm_boost=0
Ursache: arm_boost=1 weist das System an, so schnell zu laufen, wie es kann. Das führt zu höherem Stromverbrauch und dazu, dass z.B. beim Booten eine Unterspannung erkannt wird. Das trifft besonders dann zu, wenn die Eingangsspannung unter 5,2 Volt liegt.
Auf der SEU-M werden 5 Volt bereitgestellt. Der PI kann da nicht mehr booten.
Dadurch, dass arm_boost auf 0 gesetzt wird, wird er nicht zum Rennen gezwungen. Das vermindert den Strombedarf deutlich und schafft Abhilfe.
Tip: Ich habe ihn mit Zusatzstrom hochgefahren, mc (Midnight Commander) installiert...
Hallo zusammen,
ich habe spaßeshalber mal die bei mir seit langem erprobte Schaltung für den Betrieb eines TW39-Fernschreibers an piTelex samt einem Vorschlag für die Stromversorgung für Linienstrom und 5V in KiCad umgesetzt und auf github hochgeladen:
Vielleicht kann der Vorschlag ja zumindest als Anregung für eigene Varianten dienen, vielleicht aber auch einfach so wie er ist schon irgendwem helfen.
ich baue gerade ein weiteres piTelex und dabei sind mit wieder die LED Pins auf die Füße gefallen.
Einige der Status sind mir ja klar. einige erschließen sich mir leider nicht.
Bevor ich anfange eine Frontplatte zu entwerfen,wüsste ich gern, was die LED anzeigen.
U.A. auch, um sie in passender Reihenfolge anzuordnen.
Also los:
pin_LED_A
GPIO# of LED indicating status „A“ ; LED connects to GND (1kOhm in series!)
Frage: Was ist Status A ?
pin_LED_WB
GPIO# of LED indicating status „WB“ ; LED connects to GND
Das ist relativ klar >> Wahlbereitschaft, bedeutet: Es kann gewählt werden. Korrekt?
pin_LED_WB_A
GPIO# of LED indicating status „WB or status „A“ ; LED connects to GND (1kOhm in series!)
Würde sich aus Status A ergeben
pin_LED_LT
Das ist ebenfalls klar >> Maschine befindet sich im Lokalbetrieb
RPiCtrl pin_LED_status_R 0 number GPIO# of RED status LED ; LED connects to GND (1kOhm in series!)
RPiCtrl pin_LED_status_G 0 number GPIO# of GREEN status LED...
Hi,
ich hab hier irgendwo mal was von Anrufbeantworter-Funktion gelesen, es schien aber so als ginge das nur beim klassischen i-Telex und nicht beim piTelex. Oder lieg ich da falsch?
Gibt's bei Nutzung von piTelex
1) eine AB-Funktion?
2) einstellbare Sperrzeiten, in der keine FS angenommen werden?
zur Zeit stelle ich meine Ausstellungsmaschinen von Windows nach Linux um, Hier verwende ich Debian.
Die Maschinen haben eine RS232 Schnittstelle on Board , an der auch schon Fernschreiber mit TW39 (Software Heavy Metal und mini Interface) und V.10 (Hardware von der piTelex Seite) einwandfrei liefen.
um die Maschinen lokal, aus dem lokalen i-Telex Netz anschreiben zu können, habe ich piTelex unter Debian installiert.
Das funktionierte ohne Probleme (Pfadanpassungen notwendig).
Nun möchte ich lediglich die FS200 mit V.10 Schnittstelle betreiben.
Dazu habe ich folgendes Interface gebaut und folgende Anpassungen in telex.json vor genommen:
V10AdapterEcho.png
Die DTR - Leitung steuert ein Solid State Relais, das den FS200 einschaltet.
2024-08-22 18_51_50-C__Users_JoE_AppData_Local_Temp_BvSshSftp-JENLV36A_FFAEE16K_VRQRFP9Y_telex.json .png
Wenn ich keine Maschine anschließe (ich darf die zur Zeit nicht heben :schwitz: und ein Zeichen tippe, wird dieses Zeichen unendlich...
Moin ,
Ich möchte piTelex zum Test wie ein T56 Fernschaltgerät als Teilnehmer in der TW39 Vermittlung einsetzen. Gibt es dafür schon eine Konfiguration, wenn nicht wäre ich für Tipps dankbar. Ich würde den RPi ähnlich der SEU-M anschließen, später soll die Software als Ausgang zum itelex und als Eingang vom itelex eingesetzt werden.
Gibt es jemanden von euch der mir ein pitelex zusammenbauen kann, denn ich z.b. mit auf Arbeit oder anderen Standorten nemen kann.
Ich stelle es mir so vor:
Der pi hat ein Display und eine kleine Tastatur.
So das kein FS. Benötigt wird. Da ich keinen FS. Mit auf Arbeit oder zu Freunden oder zu anderen Standorten nehmen kann.
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...
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
•...
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....
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.
