Da einige es schon gar nicht erwarten können :crack: ein paar Bröckchen zu den Hostingkosten beizutragen, darf dies jetzt gerne gemacht werden.
Die Kosten für 2020-2021 belaufen sich auf 84€ für die Webseite (Jimdo Pro) und 107,46€ für Domains, Webspace, FTP, etc (all-inkl Premium)
Fällig wird's im März respektive Mai, es ist also ein bisschen früh, aber man kann ja schon mal anfangen zu sammeln :D
Hier ist der Link zur PayPal-Spende und im besten Fall taucht man dann hier mit seinem Beitrag auf.
Manchmal klappt die automatische Erfassung nicht - das trage ich dann händisch nach.
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.
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.
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
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?
es ist vollbracht.
Der ASCII klkl 881188 Dienst ist nun ebenfalls auf ita2 umgezogen.
Ab sofort könnt Ihr für den klkl Dienst entweder die 881188 oder die 881199 anwählen.
Beide Dienste sind nun ita2 konform. Der Inhalt auf beiden Systemen ist identisch, von daher ist es egal welche Nummer ihr nehmt.
881188 meldet sich mit 881188 tln d
881199 meldet sich mit 881199 tln d
Zur Bedienung:
1. Nummer wählen
2. KG wird automatisch abgefragt
3. Kurze Pause
4. Nach dem Text: Auswahl.... 15s
Entweder wartet Ihr an dieser Stelle 15 Sekunden, oder Ihr wählt den entsprechenden Menupunkt (wie beim alten klkl Server) aus.
5. Nach Ausgabe weiteren Menupunkt auswählen oder mit xx beenden
An dieser Stelle noch mal einen riesen Dank an Willi (Fernschreiber) ohne ihn wäre dieses Projekt so nicht entstanden. :beer:
Auch für seine Mühe in den letzten Tagen immer wieder die Version anzupassen, wenn ich ihn genervt habe (da geht was noch nicht richtig). :mentor:
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.
Das i-Telex arbeitet beim Senden der eingetippten Daten wie folgt:
Es werden alle in der eingenen Station eingegebenen Zeichen (5-Bit-Codes) zunächst gespeichert und bei bestimmten Bedingungen dann als ein Datenblock ausgesendet.
Die Anzahl der gesendeten Zeichen wird summiert.
Ein Datenblock wird ausgesendet, wenn eine der folgenden Bedingungen erfüllt ist:
a) seit dem letzten eingegebenen Zeichen sind 0,8 Sekunden vergangen
oder b) es sind mehr als 20 Zeichen gepuffert
oder c) die Anzahl per Ack-Telegramm als gedruckt bestätigten Zeichen ist gleich der Summe der gesendeten Zeichen.
Somit sind Ack-Telegramme tatsächlich optional und dienen nicht der Verhinderung des Überlaufens des Puffers beim Empfänger, sondern dem optimierten Senden der 5-Bit-Daten durch den Sender.
Der Empfänger sendet die Ack-Telegramme mindestens alle 1,5 sekunden, jedoch auch sofort wenn der Empfangspuffer leer ist.
Ich wollte insgesamt vermeiden, dass sinnlos Übertragungs-Overhead verursacht wird (und der...
ich beschäftige mich gerade zwangsläufig wieder mit SQL.
Die Datenbank SQLlite ist ja zukünftig Bestandteil des Teilnehmerserver und soll ebenfalls zukünftig in meinem
Abo Dienst eine Rolle spielen. Ich habe hier mal ein nettes PDF zum Thema SQLlite und Syntax verlinkt.
One of the biggest problems with getting I-Telex to take off in the UK is the lack of an interface that works with British machines.
I know there was some development work carried out for a double current interface - I have seen the schematics on Sourceforge.
I see some problems with the concept - I-Telex should be a one box solution, at present there is no dual rail power supply for the machine interface.
I think it would be possible to modify the existing power supply board to give two voltage multiplier chains - this should then allow for maybe 60-0-60 for the signalling supply (the people I have spoken to so far regarding possible new subscribers always come back to British Teleprinters use 80-0-80v - I think that this is not really needed, we are not running long distance lines for our purposes, but I do appreciate that the higher voltage is needed to allow for a quick and positive operation of the receive magnets.
Da es mir im Sommer in meiner Werkstatt (wo das i-Telex steht) häufig zu warm war und ich deshalb meistens im Homeoffice-Büro gesessen habe, habe ich nie mitbekommen, was das i-Telex so treibt.
Deswegen habe ich mir ein Tool geschrieben, das die Ausgaben der seriellen Schnittstelle der i-Telex-Karte (Ethernet-Karte) protokolliert, anzeigt und auch die übertragenen Daten analysiert und im Klartext anzeigt. Man kann also auf dem PC alles mitlesen, was das i-Telex sendet oder empfängt.
Da ich neben dem i-Telex keinen PC stehen habe, habe ich die serielle Schnittstelle über einen USB-Server mit Seriell-USB-Wandler mit meinem PC im Büro verbunden und kann mich dann sozusagen über Remote-USB verbinden.
Eine andere Alternative wäre ein Seriell/Telnet-Wandler (z.B. mit einem Arduino). Aber dafür muss ich in dem Tool noch Telnet implementieren. Das funktioniert im Moment noch nicht.
Das Programm läuft nur unter Windows (Linux- und Mac-User, sorry! :D )
Das EXE-File liegt im...
Da ich bisher nur einen Fernschreiber am i-Telex hatte, ist mir das nicht aufgefallen, aber wenn ich jetzt ein zweites öffentliches Gerät am gleichen i-Telex betreiben will, braucht ich ja eine öffentliche Extension-Nummer. Dabei ist mir aufgefallen, dass die sich über die Funktion Client-Update gar nicht aktualisieren lässt. Also wenn ich an der lokalen Konfiguration irgendetwas ändere, dann muss ich jedesmal um eine manuelle Korrektur des Server-Eintrags bitten.
Könnte man das nicht erweitern, so dass beim Client_Update optional die Extension-Nummer mit gesendet werden kann? Auch wenn die aktuelle Client-Software das vielleicht noch nicht nutzt.
In WinTlx könnte ich das jetzt schon gebraucht, um damit meine Arduino-Implementierung zu testen.
Oder spricht da technisch was dagegen, was ich übersehen habe?
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...
Ich habe mir mal Gedanken gemacht, wie man eine sichere Authentifizierung beim jedem i-Telex-Anruf realisieren könnte.
Nachdem ich einige selbstausgedachte Verfahren durchgespielt habe, bin ich eigentlich immer wieder beim Private/Public-Key-Verfahren gelandet.
Damit die i-Telex-Karte nicht mit RSA/DNS-Verschlüsselung belastet wird (das schafft die nicht), könnte man den Teilnehmer-Server für die Key-Berechnungen nutzen.
Praktisch könnte das folgendermaßen aussehen:
Wenn der Server die Verschlüsselung übernimmt, braucht man eigentlich nur einen Key, der auf dem Server gespeichert wird. Das ist dann ein Zwischending aus Public und Private Key.
Bei einem Anruf lässt sich der Anrufer vom Server ein mit seinem Key verschlüsseltes Anmeldetoken erzeugen, mit dem er sich beim angerufenen System authentifiziert. Das Token bleibt auf dem Server gespeichert.
Das angerufene System schickt den verschlüsselten Token zum Server, dieser entschlüsselt das Token mit dem Key des Teilnehmers,...
ich habe jetzt mal über Telnet die Protokollausgabe der i-Telex-Karte auf meinem Arbeitsrechner dauerhaft mitlaufen lassen. Um zu schauen, was da so passiert.
Dabei fällt mir auch, dass die Software alle 10 Minuten einen Neustart macht. Ist das normal?
Da ich es unpraktisch finde, dass ich die i-Telex-Debug-Ausgaben nur am seriellen Port der i-Telex-Karte abgreifen kann, habe ich mir jetzt einer Arduino Wemos D1 angeschlossen. Das ist ein Arduino mit integriertem WLAN.
Damit kann man mit ein paar Zeilen Code die serielle Schnittstelle über Telnet weiterleiten und sich dann z.B. mit Tera Term oder Windows TELNET draufschalten.
Auf die Schnelle hat es eben noch nicht am seriellen Port der TW39-Spez-Karte funktioniert, aber vielleicht habe ich da noch den Hardware-Handshake aktiviert. Das sollte eigentlich genauso funktionieren.
Also nochmal, das ist keine i-Telex WLAN-Anbindung. Es geht nur um den Zugriff auf die seriellen Schnittstellen.
Die Kosten für die Elektronik sind minimal. Beim Chinamann bezahlt man ca. 6 Euro für den Wemos D1 und noch mal 2-3 Euro für den TTL/Seriell-Wandler. Im Prinzip könnte man das auch in das i-Telex-Gehäuse einbauen, aber dann braucht man einen Wemos mit Antennenanschluss um die WLAN-Antenne...
ich möchte gerne die 40 mA zum FSG mit einem Atmel-Controller (ADC-Eingang 0..5V) messen.
Mit möglichst wenig Schaltungsaufwand. Das muss ja nicht auf's Zehntelmilliampere genau sein.
Ich bräuchte möglichst eine fertige Schaltung, die ich nachbauen kann. Keine Hinweise, wie man das prinzipiell machen würde. ;)
Man könnte ja direkt am Lastwiderstand messen, aber dann hat man das Problem mit der Spannungumkehr.
Also wäre es wohl ein einfachsten vor dem Relais einen Messwiderstand einzuschleifen und dort zu messen.
Oder wie macht man das am sinnvollsten?
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...
eine DSL Anbieter, wie z.B, Deutsche Glasfaser bieten DSL mit reinen IP6 stack an.
Also kein dual stack mit IP4 und IP6 .... sondern nur IP6.
Welche Konsequenzen hätte dies für das iTELEX Netzwerk via Internet.
Können die iTELEX Anschlusse noch auf den Teilnehmerservern eingetragen, bzw. die DNSNamen aufgelöst werden ?
Ich habe da ein Problem die Limitierung zu verstehen.
Ich benötige manchmal eine Einrichtung, mit dr man sich zu Testzwecken selber anrufen kann. Mmomentan muss ich das umständlich über Telnet vom seriellen Teil afu den Hauptanschluss tun. Das it jeoch keine echte Simulation eines von aussen kommenden Anrufs. Irgendwie habe ich in Erinnerung, dass es ein solches Interface irgendwo geben soll, aber meine Suche im Forum und meinen Telex blieb leider erfolglos. Vielleicht nahm ich nicht die richtigen Suchbegriffe.
Da bereits mehrere Anwender mit der Abfrage der Daten einzelner Teilnehmer nicht auf Anhieb klar gekommen sind, gibt es ab heute was neues:
Die Daten (IP-Adresse, Hostname, Port, Durchwahl) zu jeder registrierten Nummer kann auch im Ascii-Format abgefragt werden.
Dazu folgendes tun:
A) bei sonnibs.no-ip.org den Port 11811 öffnen (eigentlich bei allen Teilnehmerservern, sobald Version 722 installiert ist).
B) den Text q781272 senden (auf das q achten, Nummern sind mindestens 5 stellig)
C) Folgende Zeilen empfangen (Beispiel)
ok
781272
Fred, Braunschweig T100
1
sonnibs.no-ip.org
134
33
+++
Alle Zeilen sind mir CR+LF getrennt.
Bedeutung der Zeilen:
ok <-- Datensatz gefunden
781272 <-- sicherheitshalber nochmal die gefundene Nummer
Fred, Braunschweig T100 <-- Name (rein informativ)
1 <-- Typ (siehe unten)
sonnibs.no-ip.org <-- Adresse, hier kann auch eine IP in der Form 95.90.186.198 stehen
134 <-- Port-Nummer
33 <-- Durchwahl
+++ <-- Ende-Kennzeichnung
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.
