Läck, hast Du ein Tempo drauf
Ja, Roger, das kannst du halt nicht verstehen: Wenn es mich einmal gepackt hat, mache ich halt nichts mehr anderes 😀.
muss ich noch das Anschlusskabel reparieren. Irgendwo wurde es durch einen scharfkantigen Gegenstand halb durchtrennt
Ich kann dir ein neues Netzteil schicken. Ich habe noch vörige.
Der erste, bereits eingebaute IR-Lichtschranken-Decoder hat einen Bruder erhalten.
Das ist natürlich nicht sein Platz, sondern hier steht er nur für die Photo-Session
Das ist sein richtiger Platz, auf der K-Seite der Anlage. Erst ein Teil der Lichtschranken ist angeschlossen. Morgen kommen die anderen dran.
Hinweis von Sturzi: Bei deinen Preis-Vorstellungen wird es eine gebrauchte Lok, wahrscheinlich im Analog-Zustand sein. Digitalisieren müsstest du sie dann selber. Aber das dürfte für dich eine Kleinigkeit sein, besonders bei einer HAG-Lok wo man jede Menge Platz zur Verfügung hat. Auch Decoder sind unter der Hand erhältlich (z.B. ESU-Decoder bei mir, neu aber nicht mehr das neueste Modell).
Zuverlässigkeit der kabellosen Kommunikation mit ESP-NOW und allfällige Konsequenzen
Die Kommunikation zwischen zwei ESP32 Controllern, wie ich sie zwischen der DIGI-NOW Zentrale und den DIGI-NOW Decodern einsetze, garantiert gemäss Espressif-Dokumentation nicht, dass die Daten jeweils korrekt und lückenlos übertragen werden. Das ist zwar ein Nachteil, dafür (oder gerade deswegen) hat diese Kommunikation auch sehr wertvolle Vorteile: Sie ist schnell, einfach anzuwenden und verbindet sich immer automatisch und problemlos nach dem Ab- und wieder Zuschalten einer Komponente.
Gemäss Espressif-Dokumentation muss der Anwender, falls er absolute Zuverlässigkeit bei der Daten-Übermittlung möchte, selber (auf Anwender-Ebene) Prüf- und Korrektur-Mechanismen einbauen. Bei diesem Punkt muss ich mir schon überlegen, ob das bei meiner Anwendung nötig und sinnvoll ist. Vor Allem weiss ich bis jetzt ja nicht, ob die ESP-NOW Kommunikation in meinem Umfeld und bei meiner Anwendung gelegentlich Übertragungsfehler macht oder nicht.
Ich habe mich für folgendes Vorgehen entschieden:
Da die ESP-NOW Kommunikation bei allen meinen bisherigen Versuchen einen äusserst zuverlässigen Eindruck hinterlassen hat, versuche ich es erstmal ohne Korrektur-Mechanismen. Hingegen Prüf-Mechanismen werde ich einsetzen, um sicher zu erfahren, wie zuverlässig die Kommunikation überhaupt ist.
Um allfällige Übermittlungs-Fehler festzustellen, berechne ich auf der Sender-Seite eine Prüfsumme über alle zu übermittelnden Daten-Elemente und sende diese auch mit. Auf der Empfänger-Seite mache ich dieselbe Berechnung über alle empfangenen Daten-Elemente und kontrolliere, ob die Prüfsumme stimmt. Sollte sie einmal nicht stimmen, erhöhe ich einen Fehler-Zähler um 1 und ignoriere die übermittelten Daten (*).
Um allfälliges Verlorengehen einer Übermittlung festzustellen, verwende ich eine Sequenz-Nummer bei der Übermittlung. Diese Nummer wird vor jeder Übermittlung um 1 erhöht und mitgesendet. Auf der Empfänger-Seite kontrolliere ich, ob diese Nummer auch wirklich fortlaufend und lückenlos ist. Ist sie es einmal nicht, erhöhe ich einen anderen Fehler-Zähler und ignoriere die übermittelten Daten (*).
Diese Fehler-Zähler (sollten sie einmal nicht mehr auf 0 stehen), übermittelt die DIGI-NOW-Zentrale ans Amorocos und dieses protokolliert dies dann auf der Meldungs-Konsole. Auf diese Art erfahre ich, ob überhaupt Übermittlungs-Fehler passieren. Kommen diese tatsächlich vor, werde ich nicht darum herum kommen, nachträglich einen Korrektur-Mechanismus in die Kommunikations-Software auf Anwender-Ebene einzubauen.
(*) Ich habe geschrieben, dass ich im Fehler-Fall die Daten ignoriere. Sollte das vorkommen, ist das noch nicht das Ende der Welt, denn es handelt sich um Daten, die immer wieder übermittelt werden. Die Übermittlungen sind Ereignis-gesteuert und erfolgen zusätzlich periodisch. Das heisst, wenn z.B. der Decoder feststellt, dass eine IR-Lichtschranke angesprochen hat, wird dies sofort übermittelt. Sollte diese Information verloren gehen, wird sie bei der periodischen Übermittlung (voraussichtlich ein Mal pro Sekunde) wieder übertragen. Das bedeutet, dass in einem solchen Fall eine IR-Lichtschranken-Rückmeldung um bis zu einer Sekunde verspätet ankommen kann. Deswegen funktioniert die Steuerung immer noch, wenn auch mal ein Zug um 20 oder 30 mm zu weit fährt. Aber eben: Ob dies überhaupt vorkommt, muss erst festgestellt werden. Mein Bauchgefühl mit den bisherigen Erfahrungen der ESP-NOW Kommunikation sagt mir, dass es in meinem Umfeld nicht vorkommen wird.
Heute habe ich die restlichen IR-Lichtschranken, die gegen die H-Seite hin verkabelt sind, angeschlossen. Das sind jetzt 38 Lichtschranken. Da beim Decoder 0 die Port-Module 48 Ports haben, bleiben 10 Ports als Reserve (siehe oberste Reihe der Klemmen-Blöcke).
Bei den übrigen (jetzt noch nicht angeschlossenen) 37 Lichtschranken gehen die Kabel Richtung K-Seite. Sie werden dann an die Port-Module des Decoders 1 angeschlossen, aber den muss ich erst herstellen.
Alle 38 angeschlossenen IR-Lichtschranken sind getestet und deren Status-Erkennung durch den Decoder funktioniert.
Wenn ich das USB-Kabel am Decoder entferne (so wie es im späteren Bahnbetrieb sein wird), werden an der 5V DC Speisung (links unter dem Decoder) 0.6 A gezogen. Das sind 3 Watt und das ist für mich überraschend wenig. Ohne die angeschlossenen Lichtschranken waren es etwa 0.15 A, also 0.75 W. Das bedeutet, dass die 38 Lichtschranken zusammen etwa 2.25 W konsumieren (0.06 W pro Lichtschranke). Mit diesen Werten muss ich nicht befürchten, dass der ESP32-C6 an die Grenzen seiner 3.3V DC Versorgungs-Kapazität für die Lichtschranken gelangt.
Hier leuchtet bei allen angeschlossenen IR-Lichtschranken die rote LED. Das bedeutet, dass sie im Moment kein Objekt erkennen. Wenn man etwas davor hält, leuchtet zusätzlich noch die grüne LED und eine entsprechende Meldung geht an den Mac. Vorerst geht diese Meldung noch nicht über die DIGI-NOW Zentrale, sondern direkt über das USB-Kabel. Bis es auf dem endgültigen Weg über die Zentrale läuft, muss noch etwas Software entwickelt werden.
Erster IR-Lichtschranken-Rückmelde-Decoder fertig und auf der Anlage platziert
Die interne Verkabelung des IR-Lichtschranken-Rückmelde-Decoders ist jetzt auch fertig und das Gerät hat auf dem Anlagen-Tisch seinen Platz zugeteilt bekommen.
Die ersten beiden IR-Lichtschranken sind an den Ports mit den Adressen 000 und 001 angeschlossen und funktionieren bereits.
Die beiden Drähte links sind erst provisorisch verlegt und dienen der Speisung mit 5V DC.
Das schwarze USB-C-Kabel, das oben am ESP32-C6 eingesteckt ist und herausschaut, braucht es hier nur für Inbetriebnahme-Zwecke, damit ich jeweils ein neues Programm flashen (auf den ESP32-C6 laden) kann. Auch für die Anzeige von Zustands-Daten auf dem Serial Monitor (auf dem Bildschirm des Mac) braucht es dieses Kabel. Später im Betrieb sendet dieser Decoder seine Daten kabellos via ESP-NOW an die DIGI-NOW-Zentrale. Dann kann das USB-Kabel entfernt werden und ist nur noch nötig, wenn ich eine neue Software-Version flashen will.
Hier schätze ich wieder einmal meine beschriftungsfreie Verkabelungs-Methode. Die jeweils drei Kabel für eine Lichtschranke sind (und bleiben) beisammen, weil sie miteinander verzöpfelt sind. Angeschrieben sind sie aber nicht. Beim Anschluss an den Decoder verwende ich irgend ein freies Port.
Jedes Gerät bei der ChRB, also IR-Lichtschranken, Weichen-Antriebe, Signal-Lämpchen und Besetztmelde-Strecken, hat eine eindeutige Identifikation.
Im Falle dieser IR-Lichtschranke ist es die Identifikation (ich nenne sie nur Id) 450. Mit dieser Id "arbeite" ich auch in der Software. Sie wird z.B. verwendet, um eine Status- oder Fehler-Meldung anzuzeigen oder zu protokollieren.
Bei der Inbetriebnahme (also jetzt) lasse ich die IR-Lichtschranke ansprechen, indem ich die Hand davor halte. Der Computer zeigt mir die Adresse der Lichtschranke, die angesprochen hat, an. Diese Zuordnung Id 450 --> Adresse 000 nennt man ein Mapping und dieses Mapping schreibe ich in die Datenbank des Steuerungs-Systems Amorocos. Ab dann sorgt das Programm dafür, dass beim Ansprechen der Lichtschranke an der Adresse 000 immer die Id 450 verwendet wird. Ich brauche mich nachher (und das gilt auch für das Programmieren) nicht mehr um die Adressen zu kümmern, sondern kann alles über die jeweilige Id bewerkstelligen.
Ich werde nun nach und nach alle Lichtschranken, deren Kabel ich auf die Anlagenseite H gezogen habe, anschliessen und testen.
Hallo Carlo
Vielen Dank für dein Kompliment. Ja, es hat mich komplett "gepackt" mit diesem Projekt.
aber Deine Berufsbezeichnung müsste eigentlich ergänzt werden zu Softi + Hardi
Kaum. Ich habe zwar die elektrotechnischen und digitaltechnischen Grundlagen einmal gelernt, aber während meiner ganzen Berufs-Laufbahn nie angewendet. Während fast 40 Jahren habe ich mich beruflich nur mit Software auseinander gesetzt.
Selbst Ende der 70er war ein Teil der Strasse des Umbrail Passes noch eine Naturstrasse.
Viel länger. Noch in diesem Jahrhundert (wenn nicht jetzt immer noch) war ein Teil des Umbrail eine Naturstrasse.
IR-Lichtschranken-Rückmelde-Decoder mit drei Port-Modulen
Gestern habe ich das zugehörige Gehäuse konstruiert und auch gleich gedruckt. Die Ports sind nun bestückt, aber es fehlt noch die interne Verkabelung.
Im linken Teil ist der Decoder mit dem zwei-poligen Klemmenblock für die Speisung mit Masse und 5 V DC.
Rechts sind drei Port-Module à 16 Ports. Hier werden die IR-Lichtschranken der einen Anlagen-Hälfte angeschlossen. Für die andere Seite wird es nochmals ein solches Gerät geben.
Dieser IR-Lichtschranken-Decoder bekommt die DIGI-NOW-Adresse 0 und der für die andere Anlagen-Hälfte bekommt die Adresse 1. Die Port-Module haben die Adressen 0, 1 und 2 (von rechts nach links). Ich adressiere beim DIGI-NOW ja durch Aneinanderreihen von drei Hexadezimal-Adressen: Decoder-Adresse, dann Port-Modul-Adresse und zuletzt Port-Adresse. Auf diesem Bild hat somit das unterste Port ganz rechts die Adresse 000 und das Port ganz links oben bekommt die Adresse 02F.
Von hinten erkennt man in jedem Port-Modul einen Port-Expander MCP23017. Pro Port-Modul hat es ja 16 Ports und pro Port-Expander hat es 16 Pins für die digitalen Ein-, bzw. Ausgänge. Für jedes Port braucht es also eine Kabel-Verbindung zum Port-Expander. Zusätzlich müssen die Ports mit Masse und 3.3 V DC (Speisung für die IR-Lichtschranken) verbunden werden. Das braucht aber nicht für jedes Port eine einzelne Kabel-Verbindung zum Port-Expander, weil ich diese jeweils zusammenfassen kann.
Die rechteckigen Löcher zwischen den einzelnen Kammern für die Port-Module dienen der Verkabelung von Port-Modul zu Port-Modul. Das sind jeweils 4 Adern (Masse und 3.3 V DC für die Speisung, sowie SDA und SCL für den I2C-Daten-Bus). Diese 4 Verbindungen beginnen beim Decoder und werden als Kaskaden-Schaltung von Port-Modul zu Port-Modul geführt.
Hier werden alle Ports in den Port-Modulen als digitale Eingänge konfiguriert. Bei den Weichen-Decodern und Weichen-Port-Modulen (die noch zu entwickeln sind) sieht es dann anders aus. Dort werden die Pins der (selben) Port-Expander als digitale Ausgänge konfiguriert werden.
Bei der ChRB haben wir insgesamt 75 IR-Lichtschranken im Schattenbahnhof. Ausserhalb des Schattenbahnhofs wird es keine IR-Lichtschranken geben. Theoretisch würden wir also mit 5 Port-Modulen (5 x 16 = 60 Ports), also zum jetzt bestehenden nochmals eines mit nur 2 Port-Modulen, auskommen. Dann müsste ich aber von einigen IR-Lichtschranken die Kabel verlängern und zudem wäre die Reserve an Ports eher knapp. Wenn ich wie vorgesehen nochmals eine Gruppe mit 3 Port-Modulen fertige, haben wir Kapazität für 96 Lichtschranken und damit eine komfortable Reserve.
Ich mache mich jetzt an die interne Verkabelung, damit die erste Decoder- und Port-Modul-Gruppe fertig ist. Die Software (das gilt für den Kommunikations-Teil im Amorocos, die DIGI-NOW-Zentrale und den DIGI-NOW-Decoder) werde ich erst mal provisorisch (in abgekürztem Verfahren) erstellen, weil ich das DIGI-NOW möglichst bald im praktischen Betrieb beobachten und beurteilen will.
Christoph, ich gratuliere dir und deinen Begleitern zum neuen Rekord.
Ich war ab Biel bis Landquart auch dabei. In Luzern hätte ich Beihilfe zum Erwischen des Anschlusses leisten sollen. Der Zug nach Bellinzona ist aber durch Zug-Personal begleitet und der Zugchef wartete ungeduldig beim hintersten Wagen bis es endlich Zeit war zum Abfahren. Man kann dort nicht einfach das Tür-Öffnungs-Knöpfchen gedrückt halten und auf dem Trittbrett stehen, um die Abfahrt zu verzögern.
Ich glaub ich muss mich auch pensionieren lassen, damit ich für solche Spässe auch genügend Zeit habe...
Ja, Teddy, das kann ich dir nur empfehlen.
Habt ihr es noch geschafft gestern?
Gehäuse für DIGI-NOW Decoder
Dieses ist jetzt auch soweit. Es ist höher geworden als das der Zentrale. Zum Einen, weil es ein Breadboard enthält, auf welches der ESP32-C6 aufgesteckt ist und zum Anderen, weil es nach oben noch Platz braucht für die Kabel mit Dupont-Steckern.
Die beiden USB-C Anschlüsse werden für den Betrieb nicht benötigt. Sie bieten die Möglichkeit, Software auf den ESP32-C6 zu laden. Auch hier hat es ein kleines, rundes Fenster, durch welches man das von der RGB-LED abgestrahlte Licht gut sieht.
Der Decoder wird samt Gehäuse in ein grösseres Gehäuse eines Dreifach-Port-Moduls eingeschoben (muss noch konstruiert werden). Dieses grössere Gehäuse wird drei MCP23017 Port-Expander und insgesamt 48 dreipolige Federkraftklemmen enthalten, damit bis zu 48 IR-Lichtschranken angeschlossen werden können.
Die rechteckige Öffnung ist für die Durchführung der Kabel vorgesehen. Es werden insgesamt sechs Kabel benötigt:
- Masse und 5 V DC von einer zweipoligen Federkraftklemme (am grösseren Gehäuse) zum ESP32-C6 zur Speisung desselben
- Masse und 3.3 V DC vom ESP32-C6 zum ersten MCP23017 Port-Expander (die 3.3 V DC werden vom ESP32-C6 zur Verfügung gestellt
- die beiden Leitungen SDA und SCL des I2C-Bus für die Kommunikation zwischen dem ESP32-C6 und dem ersten Port-Modul
Ich denke, in diesem Falle hätte es bei Dir daheim auch Ärger gegeben.
😅 😂 🤣 Keineswegs! Bei mir daheim bin ich der einzige, der Ärger macht. Eine Modellbahnsteuerung im Badezimmer wäre bei mir jetzt überhaupt kein Problem. Ich habe schliesslich auch zwei Velos (*) im Wohnzimmer.
(*) Velo = Fahrrad.
Roger, bist da da nicht im Thread ein Bisschen verrutscht?
Klar ist er verrutscht, der andere Admin der weiss wie man solche Pannen korrigiert. 
Sehr schönes Gehäuse.
Danke!
Bei der Zentrale war es einfach, ein ansprechendes Gehäuse zu machen. Bei den Decodern, die etwas unförmig werden und wo noch einiges angeschlossen werden soll, wird es etwas schwieriger.
Gehäuse für DIGI-NOW Central Station
Nachdem ich beim Controller-Typ für das ganze Projekt auf den ESP32-C6 gewechselt habe (bin übrigens immer noch begeistert davon), musste ich das Gehäuse für die Zentrale nochmals anpassen, weil der ESP32-C6 kürzer ist als der Vorgänger, zwei USB-Anschlüsse hat und sich die Reset- und Boot-Taste, sowie die RGB-LED an einer anderen Position befinden.
Ich lasse jetzt das Licht der RGB-LED nicht mehr durch den ganzen Deckel leuchten, was etwas diffus ausgesehen hat, sondern durch ein kleines, weisses, rundes Fenster. Das sieht nach meiner Meinung besser aus.
Zentrale im Betrieb mit leuchtender RGB-LED
Beim Anbringen des Deckels wird das an diesem angebrachte Rohr über die RGB-LED gestülpt und umschliesst diese. Am oberen Ende des Rohrs (bündig mit der Oberfläche) habe ich das erwähnte, 0.6 mm dicke, weisse Fenster angebracht (Mehrfarben-Druck).
Leistungs-Test abgeschlossen --- Standort-Bestimmung
Es ist jetzt ziemlich genau ein Monat verstrichen, seit ich das Projekt gestartet habe. Jetzt will ich mal berichten, wie es gegangen ist und wo ich stehe.
Zu Beginn des Projektes stand für mich fest, dass ich als Microcontroller ESP32 verwenden wollte. Damals wusste ich noch nicht, auf was ich mich da eingelassen hatte. Wie ich in einem früheren Beitrag schon geschrieben habe, gibt es Hunderte von verschiedenen Varianten des ESP32 und leider sind nicht alle gut und nicht alle gleich gut für mein Projekt geeignet.
Der erste ESP32, den ich mir zum Experimentieren gekauft hatte (das war glaub' ein paar Tage vor dem eigentlichen Projekt-Beginn), war ein ESP32-C6 von Espressif (Chip und Board beides von Espressif selber). Ich wusste damals nicht was das C6 bedeutet. Heute weiss ich, dass es eine Variante ist, die speziell gut auf drahtlose Kommunikation ausgerichtet ist und sogar WiFi 6 unterstützt. Mangels Erfahrung hatte ich damals aber Mühe, diesen zusammen mit der Arduino Entwicklungs-Umgebung überhaupt zum Laufen zu bringen.
Dann habe ich gelesen, dass der ESP32-S3 der schnellste und beste unter den ESP32 sei. Klar, dass ich den schnellsten und besten haben musste und daher habe ich mir drei Stück ESP32-S3 von Waveshare beschafft. Für die Kommunikations-Tests, wie ich sie mir vorstelle, braucht es mindestens drei. Mit diesem Controller hatte ich aber nichts als Probleme. Nebst den Fehlern, die ich selber mache, hat der ESP ein eratisches Verhalten an den Tag gelegt, dass es zum Verzweifeln war. Wenn man einmal mit der Arduino-IDE kommunizieren konnte, ging das eine Stunde später nicht mehr. Probleme, nichts als Probleme! Dann kam noch der Störefried (der alte Dell-Monitor), der die ESP-NOW-Kommunikation zum Erliegen brachte. Da hätte ich das Projekt beinahe aufgegeben.
Natürlich suchte ich dann nach einer Alternative unter den ESP32-S3 Modellen. Tatsächlich gibt es ein solches Board von Arduino selber, nämlich den Arduino Nano ESP32. Das ist auch eine S3-Variante. Ich dachte mir, dass ein "richtiger" Arduino ja einfach zu verwenden und mit der Arduino-Entwicklungs-Umgebung vollständig kompatibel sein müsste. Denkste! Es war fast noch schlimmer als mit dem Waveshare. Dann habe ich ihn auch noch zu Tode konfiguriert und damit läuft er jetzt gar nicht mehr (kein Witz!)
Wie durch Intuition habe ich vor einer Woche nochmals den C6 hervorgeholt. Mit der Erfahrung, die ich bis dann hatte, brachte ich ihn auch sofort zum Laufen. Und siehe da, der C6 hat sich als einfach zu konfigurierender, stabiler, problemloser Controller herausgestellt, der einfach nur läuft und funktioniert. Das ist seither so geblieben. Der C6 macht Spass, funktioniert und macht keine Probleme. Das verbleibende Problem ist das, welches ca. 70 cm vor dem Bildschirm sitzt. Aber das kann man dem Controller ja nicht in die Schuhe schieben.
Seither mache ich meine Versuche mit dem C6. Ich habe in der Zwischenzeit auch drei Stück davon (ja, die Bastelgarage liefert schnell).
Heute konnte ich den Leistungs-Test abschliessen. Um es vorweg zu nehmen: Ich bin vom Ergebnis sehr angenehm überrascht.
Ich mache drei Tests (Erklärungen werden mit Hilfe des obigen Bildes klar):
- Kurz (also stark abgekürzt): Schritte 1 und 6
- Mittel (leicht abgekürzt): Schritte 1, 2, 5 und 6
- Lang (keine Abkürzung, volles Programm): Schritte 1, 2, 3, 4, 5 und 6
Die einzelnen Leistungs-Tests kann ich durch Klicken auf dem Amorocos-Bildschirm starten.
Der initiale Befehl an die Zentrale und die Bestätigung von der Zentrale, dass der Befehl ausgeführt worden ist, werden im sogenannten Message-Log protokolliert. Der Zeit-Stempel hat eine Auflösung (Genauigkeit) von einer Millisekunde.
Wie man sehen kann, ist das System sehr schnell. Die kurzen Tests (2 x USB-Kommunikation) dauern so um eine Millisekunde.
Die mittleren Tests (2 x USB- und 2 x ESP-NOW-Kommunikation) dauern 4 bis 6 Millisekunden.
Die langen Tests (2 x USB-, 2 x ESP-NOW- und zwei Mal I2C-Kommunikation) dauern 6 bis 7 Millisekunden.
Meine Beurteilung:
- Dass die USB-Kommunikation schnell ist, wusste ich. Sie ist allerdings sogar noch etwas schneller, als ich erwartet hätte.
- Die kabellose Kommunikation mit ESP-NOW ist auch schneller als erwartet, bleibt aber der Teil, der am meisten Zeit beansprucht (mehr als USB und I2C zusammen).
- Die I2C-Kommunikation ist für mich die grösste Überraschung. Die ist ja mega-schnell. Ich frage mich, warum die allgemein als langsam eingestuft wird.
Das Beste ist, dass ich die Zeiten jetzt durch 2 teilen darf, weil im Betrieb als Digital-System ja nur ein Weg zu Anwendung kommt und nicht (wie hier) nach unten und dann wieder nach oben. Also die Reaktions-Zeit vom Ansprechen einer IR-Lichtschranke bis das Amorocos davon erfährt, dürfte um die drei bis vier Millisekunden sein. Für mich ist das super-mega-ober-hyper-schnell.
Fazit
Ich betrachte die Machbarkeits-Abklärungen hiermit als erfolgreich abgeschlossen. Es scheint, dass ich mit dem ESP32-C6 den richtigen Microcontroller nun gefunden habe. Jetzt habe ich auch mehr Erfahrung im Umgang mit den neuen Technologien gesammelt und kann mich nun an die eigentliche Entwicklung des Digital-Systems machen. Es muss viel Software geschrieben werden, Java-Software im Amorocos zur Kommunikation mit der DIGI-NOW Zentrale, C++ Software für die Zentrale und C++ Software für die Decoder. Dazu kommt die Hardware-Entwicklung für die Decoder und die Port-Module, sowie die Konstruktion und das Drucken der passenden Gehäuse. Mir wird in nächster Zeit sicher nicht langweilig. Wenn ich doch - verdammt-noch-mal - nur etwas jünger wäre! Ich brauche noch viel Zeit.
Probleme und Rückschritte können (und werden) immer wieder kommen. Ich bin aber zuversichtlich, dass die zu meistern sein werden.
Dies ist mein Versuchs-Aufbau unter Einbezug von Port-Modulen.
Auf dem Breadboard (oben) sind unsere beiden bekannten Decoder, die je über ESP-NOW (kabellos) mit der Zentrale kommunizieren.
Der Lichtsignal-Decoder (rechts) ist mit nur einem Port-Modul ausgerüstet. Für meinen Leistungs-Test macht es keinen Sinn, noch weitere dazu zu nehmen.
Der IR-Rückmelde-Decoder (links) hat hier vier Port-Module, welche insgesamt mit 64 IR-Lichtschranken verbunden werden könnten. Dies ist bezüglich zeitlichem Verhalten der am meisten kritische Decoder. Deshalb will ich hier ausgiebig experimentieren und das zeitliche Verhalten untersuchen. Das ist auch der Grund, warum ich nicht nur ein, sondern gleich vier Port-Module verwende.
Die Verbindungen zwischen den Decodern und den Port-Modulen bestehen aus je vier Kabeln. Zwei sind für die Speisung der Port-Module vorgesehen (Masse und 3.3 V). Die anderen beiden sind die Kabel für die I2C-Kommunikation (SDA und SCL). Wenn mehr als ein Port-Modul an einen Decoder angeschlossen wird (wie hier beim linken Decoder), können die Kabel-Verbindungen kaskadiert werden.
Was hier noch fehlt, sind die provisorischen, behelfsmässigen Kabel-Verbindungen zwischen Ausgängen des rechten Port-Moduls und Eingängen der vier linken Port-Module, damit der Mess-Kreislauf geschlossen ist.
Noch etwas zum I2C-Bus: Das ist ein weit verbreiteter serieller Daten-Bus, der in der Regel zwischen Controllern (hier die Decoder) und Peripheriegeräten (hier die Port-Module) eingesetzt wird. Das Besondere daran ist seine Einfachheit in der Anwendung. Es braucht (nebst der Speisung für die Peripheriegeräte) nur zwei Kabel, nämlich eines für den Übermittlungs-Takt (SCL) und eines für die serialisierten Daten (SDA). Praktisch alle gängigen Controller (unter anderen der Arduino und der ESP32) und sehr viele Peripherie-Geräte sind standard-mässig für die Verwendung von I2C ausgerüstet. Die Nachteile der I2C-Kommunikation sind die eingeschränkte Distanz (wenige Zentimeter bis vielleicht ein, zwei Meter) und dass sie eher langsam ist.
Eine Anmerkung zum Widerspruch "Einsatz des langsamen I2C-Bus für eine zeitkritische Anwendung": Zum Einen muss ich verwenden, was vorhanden und bezahlbar ist. Es gäbe schon Alternativen, z.B. der SPI-Bus. Der hat aber andere Nachteile (aufwändigere Verkabelung), die den Einsatz in meinem Projekt eher ungeeignet machen würden.
Zum Anderen gibt es Möglichkeiten, das Port-Modul mit dem I2C-Bus so anzuwenden, dass es eben nicht mehr langsam ist. Ich habe da schon klare Vorstellungen und werde vielleicht in weiteren Beiträgen noch darauf eingehen. Auch die Möglichkeit, den I2C-Bus zu tunen (schnellere Taktrate) ist durchaus vorhanden.
meine Skepsis kam einfach daher, dass ich ganz zu Beginn bei meinen ersten Versuchen mit Rückmeldung viele Probleme mit Stör-Einflüssen hatte
Es kommt wohl auf die Stärke der Störeinflüsse an.
Mein alter DELL-Monitor scheint diesbezüglich eine Krücke zu sein. Wenn der läuft, spinnt die ESP-NOW-Kommunikation. Ist er weg, funktioniert's super.
Gestern habe ich nochmals Versuche gemacht bei fahrenden Loks. Die Zentrale ist auf meinem Schreibtisch platziert und die beiden Decoder auf dem Anlagen-Tisch nahe bei den Gleisen, wo das DCC-Signal zwischen Gleis und Fahrleitung anliegt. Da gab's absolut keine Störungen und die Reaktions-Zeiten waren sehr kurz. Jetzt bin ich wieder sehr optimistisch und nach ersten Versuchen mit den Port-Modulen sind auch meine Befürchtungen, dass diese zu langsam sein könnten, etwas gewichen.
Cool! Das ist jetzt ein typischer All-Gender-Brunnentrog 😀 .
