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...
mich haben die beiden Beiträge zur ehemaligen Washington-Moskau Fernschreibverbindung inspiriert (rotes Telefon genannt):
Bei der Verschlüsselung wird jedes Zeiche mit einem weiteren Zeichen eines Schlüsselstreifens XOR verknüpft. Die Gegenstelle
hat den selben Schlüsselstreifen und kann entschlüsseln. Im militärischen Umfeld wird jeder Schlüsselstreifen nur einmal
genutzt (OTT one time tape). Könnte man diese Funktion nicht auch in die TW39 Schnittstellen Firmware einbauen ?
Fred hättest Du Lust sowas zu programmieren .. geht das überhaupt ?
Die Verschlüssellung läßt sich bei Bedarf zuschalten.
Man hinterlegt überall den gleichen Schlüssel aus Buchstaben und nach dem Senden einer Startsequenz über den Fernschreiber (z.B. +crypt+)
meldet sich die Schlüsselnummer des gespeicherten Schlüssels (z.B. key070612) , danach geschieht der Verkehr XOR kodiert ... auf den Fernschreibern kommt weiter Klartext raus.
ich weiss nicht in wie weit die I-Telex SW den Verkehr mitliest, aber ich würde mir wünschen
dass die Nebenstelle (optional) auf WER-DA? reagieren könnte.
Hintergrund ist dass nicht alle FS einen vernünftige Namengeber haben.
Im angehängten Dokument einige Erweiterungen für das I-Telex Client-Server Protokoll, mit denen Folgendes möglich wird:
ASCII Clients ohne feste Ip-Addresse Änderung der Durchwahl Teilnehmerserver Abfrage nach Name für ASCII Clients
Hallo Fred,
auch wenn es nur ein Scherz war, aber die Idee finde ich nicht mal so doof.
Ein i-Telex das nicht mehr über den TWI-Bus funktioniert, sondern komplett via Ethernet.
Ich stelle mir das so vor:
Backplane mit nur Versorgungsspannungen. Jeder Fernschreiber hat eine komplett eigene Ethernetkarte auf der die Schnittstellenkarte gleich integriert ist.
Also Eingang Ethernet
Betriebsspannung
Ausgang 1 X TW 39 oder ED1000/vergleichbare
Dann gäbe es halt keine interne Verbindung mittels Kurzwahl, sondern man müsste die Nummer im Kennungsgeber wählen.
Vorteil, jeder FS ist von außen gleichzeitig erreichbar. Dann bräuchte ich halt für das i-Telex einen 12er Switch.
Features wie Rundsenden, Speichertexte und AB könnten dann gleich drin sein.
Vielleicht eine Idee für das Jahr 2025. Ich bin ja sehr zufriedener Anwender, aber so in etwa stelle ich mir die Zukunft vor wenn z. B. Hardware nicht mehr lieferbar ist und eine Neuentwicklung nötig macht. Wie gesagt, nur eine mögliche...
Wie wird eigentlich das Ende der gewälten Nummer erkannt?
Gibt es da einen timeout?(Die Nummern können ja auch beliebig kurz oder lang sein) Wenn ja, wie lange wartet er bei itelex nach dem Wählen auf eine weitere Ziffer - oder fragt er nach 5 Ziffern bei jeder weiteren im Teilnehmerserver an?
Mir kam gerade in den Sinn, ob man mit 2x dem Ding und 2 Bluetoth-Modulen sowas wie eine TW39 Funkbrücke
zwischen der Dose und Fernschreiber hinbekommen könnte. Dann könnte ich auf mein cable on demand ,
also das Ausrollen meines Kabels diagonal durch das Wohnzimmer, verzichten.
ich hätte gern einen Logik-Ausgang auf dem ED1000 Board, der einen belegten FS anzeigt (analog der Funktion des Umpolrelais auf
der TW39).
Der Ausgang soll aktiv sein, wenn der Port belegt ist, egal ob gehend oder kommend.
Chat-Snip:
likes this message schade. einen freien Ausgang des Atmel könnte ich problemlos beschalten aber die Treiberschaltung musst du dazu bauen Das ist eine Idee danke!
Für alle die, die auch bei der Projekt-Weiterentwicklung mitmachen möchten,
sind her ein paar Worte über die Teilprojekte enthalten.
Leider bin ich nicht in der Lage, hier eine komplette Einführung
zu schreiben. Hier stehen nur die Informationen, die ein erfahrener
Anwender braucht, um alles notwendige zusammen zu kratzen.
Einführung in die Programme Eagle und AvrStudio (und ggf. TortoiseSVN)
gibt es denke ich genug. Mit etwas Vorwissen sind die Programme aber
auch m.E. leicht bedienbar.
Projekt - Ablage im Netz (neudeutsch Hosting)
Alles was für dieses Projekt benötigt wird, ist auf einem offenen
Subversion -Server namens Sourceforge abgelegt.
Die Links zu den konkreten Speicherorten folgen unten, zum Herunterladen
entweder das komplette Packet mit Download snapshot als zip-Datei herunterladen
oder einzelne Dateien zuerst normal (!) anklicken und dann download wählen.
Noch besser ist es natürlich mit Subversion-Clients (z.B. TortoiseSVN)
zu arbeiten, aber das...
Nach der angeregten Diskussion im Chat beschreibe ich mal was ich mir so vorstelle....
Relaiskarte mit zwei potentialfreien Wechslerkontakten und Klemmen auf der Karte, z. B. mit einen Stecksystem wie bei der Ethernethkarte. (Trennbare Klemmen statt festen Anschlüssen an der Vorderseite.
Eine RJ-45 Schnittstelle zur Programmierung (Idealzustand) oder Kodierschalter.
Prinzipiell sollte die Karte folgendes können.
Erkennen von Zuständen auf den einzelnen Karten, z. B. Anruf von Extern, oder Allgemein belegt und dann die Ausgabe auf das Relais.
Die Relais sollten programmierbar als Wischer- oder Dauerrelais sein.
Grundsätzlich denke ich an folgendes:
Ersatz des Fernschaltgerätes für diejenigen die keines haben, dann sollte eben die Busadresse der Endstelle ausgewertet werden, oder eben Anrufsignalsierung - egal welche Endstelle angesprochen wird, hier sollte eben die Etherneth- oder falls vorhanden Modemkarte gelesen werden.
Hallo Fred,
kann es sinnvoll sein, im iTELEX die maximale Zeilenlänge vor Zeilenumbruch umkonfigurieren zu können ?
Mein Fernschreiber verkraftet 72 Zeichen pro Zeile.
Momentan scheint die Länge bei 67 oder 68 zu liegen?
enum { Druckzeilenlaenge = 68 } ;
Macht es Sinn sowas parametrierbar im Webinterface der iTEELX Karte einzubauen ?
Für alle, die es genauer wissen wollen und für alle, die irgendwas Kompatibles zum i-Telex-System entwickeln wollen:
Hier LINK gibt es eine Beschreibung, wie die Kommunikation zwischen zwei i-Telex-Stationen sowie zwischen i-Telex-Station und i-Telex-Teilnehmerserver abläuft.
Auch diese Beschreibung ist in Englischer Sprache.
Wer hineinschaut wird erkennen, dass ein gewisser Diskussionsstand vorhanden ist. Dabei geht es darum, noch genauer zu beschreiben welche Abläufe erlaubt / vorgegeben sind.
Dieser Thread dient also dazu, Fragen und Anregungen diskutieren zu können.
Eine kleine Bitte für alle Mitleser: Kommentare zu Rechtschreibfehlern oder Grammatikfehlern nehme ich gerne an, aber bitte als PN.
Dies wird auch noch nicht der letzte Thread zu Weiterentwicklungs-Ideen sein.
Hallo Fred,
mir kam in den den Sinn, ob es nützlich sei könnte, die DEBUG Informationen ebenfalls verbergen zu können,
wie es mit dem Telefonbuch zu machen ist. Die DEBUG Infos enthalten ja doch einige Informationen, die eventuell
nicht jeder sehen sollte.
Was denkst Du, sind dort sicherheitsrelevante Infos dabei .... man kann Puffferinhalte und IP/Portinformationen mitlesen...
Hallo Fred,
ich habe auf SOURCEFORGE die Rubrik UniversalInterface gefunden. Es macht mich schon etwas neugierig. Magst Du verraten, was da von Dir geplant ist ? Ist das ein Software-Interface im TxP2 System oder wird das eine eigene Karte werden ? Die schreibst, daß damit die TWI Kommunikation abgewickelt (?) werden soll.
Für alle, die es genauer wissen wollen und für alle, die eigene Module für das i-Telex-System mitentwickeln wollen.
Hier LINK gibt es eine Beschreibung, wie die Kommunikation auf dem i²c-Bus (oder auch TWI-Bus, absolut das selbe) zwischen den Platinen abläuft.
Ich hab lange überlegt, ob ich diese Beschreibung auf Deutsch oder Englisch schreibe. Für die in D gängigen Geräte alles da ist und Entwickler, die sich mit Bussystemen und Programmierung auskennen eh (technisches) Englisch beherrschen können sollten, habe ich mich für Englisch entschieden.
Dieser Thread dient also dazu, Fragen und Anregungen diskutieren zu können.
Eine kleine Bitte für alle Mitleser: Kommentare zu Rechtschreibfehlern oder Grammatikfehlern nehme ich gerne an, aber bitte als PN.
Ich werde hier weitere Fred's eröffnen zu ähnlichen Themen...
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.
