Telexforum.de

Marco,

mach doch einfach mal, zeig uns dann dein i-Telex-3.1475

damarco hat geschrieben: ↑So 17. Mär 2024, 16:48 Ob der Hauptrechner nun mit oder ohne OS funktioniert muss man noch mal diskutieren. Ich bin ja für ein OS wie Linux, ohne OS ist der Code nur auf dem Prozessor lauffähig. ARM verkauf ja nur die Lizenz und die Hersteller bauen die Hardware herum und was den RPI betrifft dessen Dokumentation vom Prozessor steht unter NDA.

Es gibt ja inzwischen einige Raspi Bare-Metal-Projekte (also ohne Linux) mit fertigen Libraries für die wichtigsten Funktionen. Dafür braucht man keine Registerbeschreibung. Was da genau alles geht, das weiß ich nicht. Dass der Raspi wegen der mangelnden Echtzeitfähigkeit von Linux nochmal einen Coprozessor benötigt, mit dessen Rechenleistung alleine man schon die gesamte Netzwerkkarte realisieren könnte, finde ich heftig. Das bläht das Projekt sehr stark auf. Der Pico (oder was auch immer) muss programmiert werden und dann noch das Projekt auf dem Raspi. Eigentlich zeigt das, dass der Raspi für diesen Zweck ungeeignet ist.

In welcher Sprache würdest du das Projekt eigentlich programmieren? C++?

Weiterhin ist man von der Lieferbarkeit zweier Prozessorsysteme abhängig. Dabei behagt es mir nicht, dass der Raspi drei Jahre lang quasi überhaupt nicht lieberbar war, während es mit dem Atmel immerhin möglich war, eine adäquate Ersatzlösung zu schaffen. Das begeistert mich immer noch, wie relativ zügig die Ethernet-Light-Karte da war.

Mein Favorit ist nach wie vor der ESP32. Den gibt es in zig Varianten, ist einfach über die Arduino-IDE zu programmieren und müsste meiner Meinung nach auch das TWI-Protokoll nebenbei erledigen können.

Wenn ich das Projekt angehen würde, dann würde ich zunächst prüfen, ob der ESP32 erstens das TWI-Protokoll im Hintergrund schafft (und zwar mehrere Verbindungen gleichzeitig) und ob man zweitens problemlos ein externes Ethernet-Interface dran bekommt.

Eines der größten Probleme ist, wie du schon gesagt hast, die Stromaufnahme des Raspi. Eine Raspi-basierte Netzwerkkarte kann man in kein Standard-i-Telex-System reinstecken. Das ganze aktuelle Busboard/Netzteil-Konzept würde nicht mehr funktionieren. Mit einem ESP32 wäre das problemlos möglich.

Dann der Preis. Der Raspi 3B kostet bei Berrybase aktuell knapp 40 Euro. Wenn der nicht lieberbar ist, muss man den Raspi 4 für 60 Euro nehmen (das ist nur der Raspi, dazu kommt nach einiges aussenrum - da ist man ganz schnell bei 100 Euro für eine Netzwerkkarte nur für das Material). Und bei den Daten des Netzteils wird mir schwindelig. Viele betreiben den 4er mit Lüfter.

Deswegen würde ich, bevor irgendwelche Arbeiten in Detaillösungen investiert werden, gerne erstmal sehen, wie denn das Gesamtkonzept für ein zukünftiges i-Telex-System aussehen würde. Ich würde eine Lösung favorisieren, wo nur die Netzwerkkarte ausgetauscht werden muss.

Interesting discussion,

A line I work to on a daily basis is "the only stupid question is the one that is not asked", so forgive me for asking the stupid questions now:

What is the main motivation behind the change of processor/operating system?

Has there been an announcement that the ATMEL is at end of life and no longer produced?

Is there a situation where the current Ethernet connection we are used to will cease to function in the next 10 years?

Develpoment of new ideas is of course excellent, but backwards compatibility with the original system has to be a design priority - many users have invested considerable time and money in building a working system - It would be catastrophic if I-Telex was to take the route of Microsoft, where a new Operating System makes all your existing hardware either redundant, or worse only working through a series of patches in software.....

Although I do not understand the depth of discussion taking place here, I do still follow with interest, having a new generation of hardware developers is a great way of extending the life of a project, but only if there is a real need for change surely?

Appreciate all that everyone does to make I-Telex work - there still is no other working alternative

Die bestehende Ethernet-Karte erfüllt aktuell alle wichtigen Anforderungen. Die Software ist robust, die Karte ist verhältnismäßig günstig und sie ist leicht einzurichten. Von daher sehe ich aktuell keine zwingende Notwendigkeit, daran irgendetwas zu ändern.

Wenn es mal mit der Verbindung zu einem Gigabit-Router nicht hinhaut, hängt man noch einen 100 MBit-Switch dazwischen. damit kann man leben.

Es gibt eigentlich nur zwei Features, die ich persönlich wirklich vermisse.

Erstens die fehlende WLAN-Schnittstelle, die uns hier bei unseren Museumsprojekten das Leben sehr viel leichter gemacht hätte. Der Einsatz von WLAN-Clients ist sehr umständlich. Die Dinger sind kompliziert einzurichten und die Auswahl ist sehr eingeschränkt, wenn man einen braucht, der keinen eigene WLAN-Accesspoint aufmacht (die meisten tun das). Wir hatten genau dieses Problem im MfK in Frankfurt. piTelex hilft hier nicht weiter (das war vorher installiert), weil es Centralex nicht unterstützt.

Und zweitens vermisse ich die Möglichkeit, über eine Ethernet-Karte mehrere Verbindungen gleichzeitig aufzubauen

Und dann kommt irgendwann noch das Thema IPv6 auf uns zu. Das sehe ich aber aktuell noch nicht.

Trotzdem finde ich die Diskussion, was technisch machbar wäre, sehr interessant. Es muss sich dann eben jemand finden, der es umsetzt - entwickelt, baut und langfristig auch supportet und weiterentwickelt. Und es geht ja nicht darum, die bestehende Ethernetkarte abzulösen. Eine neue Karte muss eben soweit kompatibel sein, dass man sie einfach alternativ einsetzen kann. Da wo sie wirklich Vorteile bringt.

detlef hat geschrieben: ↑Mo 18. Mär 2024, 10:25

Wenn es mal mit der Verbindung zu einem Gigabit-Router nicht hinhaut, hängt man noch einen 100 MBit-Switch dazwischen. damit kann man leben.

Es gibt eigentlich nur zwei Features, die ich persönlich wirklich vermisse.

Erstens die fehlende WLAN-Schnittstelle, die uns hier bei unseren Museumsprojekten das Leben sehr viel leichter gemacht hätte. Der Einsatz von WLAN-Clients ist sehr umständlich. Die Dinger sind kompliziert einzurichten und die Auswahl ist sehr eingeschränkt, wenn man einen braucht, der keinen eigene WLAN-Accesspoint aufmacht (die meisten tun das). Wir hatten genau dieses Problem im MfK in Frankfurt. piTelex hilft hier nicht weiter (das war vorher installiert), weil es Centralex nicht unterstützt.

Und zweitens vermisse ich die Möglichkeit, über eine Ethernet-Karte mehrere Verbindungen gleichzeitig aufzubauen

With apologies for not posting replies in German

The Gigabit router issue is annoying - Here there are a system of various switches thanks to the modern fibre connections - this probably is not worthy of a redesign on it's own....

WLAN - this is more challenging I guess - TP link make a nice little WLAN adaptor - I use them at work frequently, but I admit not so elegant as an on board solution. However, other than initial configuration, to link to the best access point, I have to do no other configuration - in this respect, a simple task that would be little different to a couple of entries in a configuration page of a new I-Telex system.

Multiple connections to one Ethernet card.... Yes, this would be a good feature - At present the one connection per Ethernet card is a limiting factor, but seriously, how many Telex machines can one person operate Granted, in a museum environment, or perhaps even a public display several lines would be more useful. I guess this is the limitation of the "Simple" ethernet card - one IP address is one line currently?

It's certainly not going to be a simple solution, and many months of development work would be required - Well out of my area of expertise!

M1ECY hat geschrieben: ↑Mo 18. Mär 2024, 12:09 WLAN - this is more challenging I guess - TP link make a nice little WLAN adaptor - I use them at work frequently, but I admit not so elegant as an on board solution.

We used this TP-Link module in the museum in Frankfurt.
https://www.tp-link.com/de/home-network ... l-wr902ac/

M1ECY hat geschrieben: ↑Mo 18. Mär 2024, 12:09 Multiple connections to one Ethernet card.... Yes, this would be a good feature - At present the one connection per Ethernet card is a limiting factor, but seriously, how many Telex machines can one person operate Granted, in a museum environment, or perhaps even a public display several lines would be more useful. I guess this is the limitation of the "Simple" ethernet card - one IP address is one line currently?

On the TCP side you could have as many concurrent connections as there are IP ports. The limitation is in the internal serial bus and memory in the Atmel controller on the Ethernet card. As far as I know.

There are 3 Ethernet cards in the i-Telex system of the Heinz Nixdorf Forum.
If we offer Telegram service, we need a free line just for that. Two additional lines for simultaneous presentation on two teleprinters or incoming traffic.

Mein unmaßgeblicher Senf... aber immerhin Senf :

Mit dem originalen i-telex kenne ich mich nicht aus.
Nur ein wenig mit piTelex. Aus dieser Sicht finde ich,
ein hardwareplattformunabhängiger Ansatz erschlägt viele der Anforderungen:
Jeder nicht eben steinalte MiniPC oder Laptop oder SBC ( viele Raspberry,...)... hat eine GBit kompatible Ethernetanbindung, außerdem WLAN. Über die Systemleistungsfähigkeit braucht man nicht nachzudenken, die reicht immer. Solch ein System kann man für weniger Euros überall im Netz kaufen. Auf diesem Rechner, egal ob Linux oder Windows oder MAC, dann die Telex Steuersoftware in einer für alle Betriebssysteme vorhandenen Sprache z.B. Python.
Ansteuerung der FS über USB Port mit CH340 chip, an dessen TTL Anschlüssen eine standardisierte Hardware aus ein bisschen Logik mit ein paar Waldwiesenbausteinen und einer Linienstromversorgung mit Waldwiesenbauteilen. Und schon kann man auf einem host über eine Ethernetanbindung soviele FS steuern, wie der Rechner USB Ports hat. Nimmt man bei den SBCs noch die GPIO dazu, kann man Sonderwünsche erfüllen wie Stromsparschaltung, Emulation eines kompletten FSG, Statussignalisierung per LED usw.

Im Prinzip kann piTelex das alles.

Was es (noch) nicht kann, ist Centralex. Aber Centralex ist eigentlich ja nur eine Krücke wegen fehlender IPV6 Fähigkeit des i-telex selbst. Das ist m.E. ein wesentlicher Punkt, der (mit Rückwärtskompatibilität!) angegangen werden müsste.

Und was piTelex auch nicht hat, ist eine benutzerfreundliche Konfiguration. Da ist noch viel Luft nach oben (kein Webinterface etc).

Und bei Fehlfunktion oder Fehlkonfiguration muss man meist schon tiefer graben, um den Fehler zu finden. Das ist nicht optimal und hat Ergänzungspotenzial

Dafür hat piTelex eine schöne modulare Struktur, die das "Dazubasteln" neuer Funktionen erleichtert.

Ich will auch gar nicht das existierende piTelex hier auf den Schild heben, denn auch hier ist die Software mit guten Ideen gestartet und im Laufe der Zeit ist vieles dazugebastelt, dran korrigiert worden, wie das nun mal so ist. Und erst Recht möchte ich das nicht kritisieren, denn ich selber bin schon mal gleich zu blöd um es besser zu machen und deshalb dankbar für alles was es im Kontext piTelex und i-telex gibt.

Ich möchte am Beispiel piTelex nur anregen, bei einer Neukonzeption möglichst wenig spezielle Hardware- und Softwareabhängigkeiten einzugehen, das sind m.E. die besten Voraussetzungen für ein langes Projektleben. Ich denke da an das Textsatzsystem TeX von Donald Knut, in den 70ern auf für heutige Verhältnisse lächerlichen Rechnern entwickelt, durch kluge Modularisierung insbesondere bei der Anbindung immer smarterer Ausgabegeräte bis heute anpassungsfähig und weiterentwickelt. Es wird immer noch aktiv genutzt, sogar bspw von führenden Fachbuchverlagen wie Addison Wesley

Just my 2 Cents...

obrecht hat geschrieben: ↑Mo 18. Mär 2024, 14:05 Was es (noch) nicht kann, ist Centralex. Aber Centralex ist eigentlich ja nur eine Krücke wegen fehlender IPV6 Fähigkeit des i-telex selbst. Das ist m.E. ein wesentlicher Punkt, der (mit Rückwärtskompatibilität!) angegangen werden müsste.

Ich kenne mich mit IPv6 gar nicht aus, aber soweit ich weiß, hat man bei Mobilfunkverbindungen/LTE keine öffentliche IP-Adesse. Nicht mal eine IPv6-Adresse. Oder hat sich das inzwischen geändert? Wenn das noch so ist, dann würde die IPv6-Fähigkeit des i-Telex nicht helfen.

Auch bei den Museumanwendungen geht es oft nicht ohne Centralex, weil die einem in der Regel keinen Port in der Firewall aufmachen.

Das Problem ist das bei einigen ISP Anbietern ist nicht mehr möglich ist Dienste hinter den Router zu betreiben. Diese machen eine IPv4 <-> IPv6 Umwandlung und sind nach Außen IPv6 nach Innen aber IPv4. Man kann zwar mit dem i-Telex nach draußen Anschlüsse erreichen aber keinen Anschluss der sich hinter solch einen Provider verbirgt. Kunden mit solch einen Anschluss sind nicht gerade begeistert

Dein Router mit der IPv4 Adresse müsste dann dem Router vom ISP mit einer IPv6 die Route nach innen konfigurieren. Oder der ISP muss an den Kunden IPv6 Adressen verteilen und du kann das dann wieder in deinem Router einrichten.

Also ich wäre so schlau gewesen die Konfiguration von einer SD-Karte zu lesen wenn es um den ESP32 gehen würde. Also ich kann nur C und deswegen hätte ich es in C gebaut.

Eine Python oder insbesondere MicroPython -> das neue Basic wäre auch denkbar.

Einen Broadcom ARM möchte ich nicht Programmieren ohne Dokumentation und in das Thema brauchen wir glaube ich nicht erst einsteigen. Was ist wenn der abgelieferte Code nicht funktioniert? Außerdem gibt es dann nicht einmal Quellen, da diese unter NDA stehen.

detlef hat geschrieben: ↑Mo 18. Mär 2024, 14:42 Auch bei den Museumanwendungen geht es oft nicht ohne Centralex, weil die einem in der Regel keinen Port in der Firewall aufmachen.

Punkt für dich