ich bin aktuell dabei, ein RC-Funktionsschiff zu modernisieren. Als neue Zentrale dient ein ESP32, der die Signale vom Empfänger auswertet.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für jeden kleinen Verbraucher vom ESP32 aus verlegen möchte, würde ich die Schaltaufgaben gerne dezentral über ein Bussystem (I2C) lösen. Geschaltet werden sollen primär LEDs (teilweise mit Blink-Mustern) und kleine Verbraucher wie Mini-Motoren. Ströme liegen meist unter 100mA, in Ausnahmen bei 200-300mA.
Mein aktueller Lösungsansatz:
Nach einiger Recherche bin ich bei der Kombination aus einem MCP23017 (als Port-Expander für den I2C-Bus) und nachgeschalteten ULN2803A Darlington-Arrays (als Leistungstreiber gegen Masse) gelandet. Für die paar Ausnahmen über 100mA würde ich diskrete Logic-Level MOSFETs an den MCP hängen.
Da ich jedoch nicht mehr ganz auf dem neuesten Stand bin, wollte ich die Runde fragen, ob dieses Setup heute noch Sinn macht oder ob man das moderner/eleganter lösen kann:
Gibt es mittlerweile "All-in-One"-Bausteine?
Gibt es empfehlenswerte I2C-ICs, die den Expander und eine Treiberstufe (bis z.B. 300mA) bereits in einem Chip vereinen, sodass ich mir das separate Darlington-Array sparen kann?
Die PWM/Servo-Frage:
Eigentlich brauche ich für die LEDs kein PWM. Wenn das Bussystem aber PWM-fähig wäre, könnte ich zukünftig auch dezentral Servos (z. B. für Kräne) darüber ansteuern. Wäre hier ein Umstieg auf einen PCA9685 (plus ULN2803A für die LEDs) die bessere Architektur, oder handle ich mir damit Nachteile bei der LED-Steuerung ein?
Ich programmiere den ESP32 in Python/MicroPython, falls das für die Chip-Wahl (Treiber-Verfügbarkeit) relevant ist.
Vielen Dank im Voraus für eure Einschätzungen und Tipps!
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu verbinden. Nicht ueber Platinengrenzen hinaus. Daher wuerde ich keinen I2C fuer soetwas verwenden, eher irgendwas Richtung RS232 - moeglichst nichts mit bidirektionalen Leitungen oder OpenCollector.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für
jeden kleinen Verbraucher vom ESP32 aus verlegen möchte, würde ich die
Schaltaufgaben gerne dezentral über ein Bussystem (I2C) lösen.
Bussystem ist schön und gut, aber es spart nichts an der Verkablung von Lämpchen, Motoren und dem anderen Schnickschnack. Dann bleibt noch die Stromversorgung, die je nach Verbraucher kräftig oder weniger kräftig ausgelegt werden muss.
Ausserdem ist I²C weit entfernt von fehlertolerant - eine Spannungsspitze zur falschen Zeit blockiert den Bus. Dafür gibt es zwar 'Reparaturmethoden', aber es muss erkannt werden und zwar, bevor du mit dem Modell einen Eisberg rammst.
Ich würde soweit wie möglich auf Standard aus dem RC Sortiment zurückgreifen. Und den ESP32 würde ich persönlich nochmal überlegen und doch auf einen Pico(2)W zurückgreifen - einfach, weil der schon so viele Ports hat.
Der Gedanke eines Bussystems im RC-Modell treibt mich auch schon geraume Zeit um. Ich habe zwar einen Modell-Lkw, aber auch hier fände ich die Aufteilung in verschiedene "Knoten" schön, z.B. einer im Chassis, einer im Fahrerhaus, einer hinten im Bereich der Rücklichter.
Natürlich erspart es nicht die End-Verdrahtung der einzelnen Lämpchen, aber es ist schon praktisch, wenn man trennbare Einheiten hat (z.B. Aufbauten oder Fahrerhaus), die nicht mit zig Adern mit der Zentrale verbunden sind. "Früher" hat man an dieser Stelle 37- oder 50polige Sub-D-Stecker verbaut, aber das ist ja sowas von 80ies...
Aus der Modellbauwelt kommen dazu auch Antworten, z.B. vor Jahren das System "Blauzahn" (heute ist das Projekt aufgegeben, schade) oder der "Kingbus" von Pistenking (den habe ich mir noch nicht genau angesehen)
Meistens aber wird eine zentrale Verdrahtung propagiert. Hunderte von mehr oder weniger intelligenten Modulen gibt es, Soundmodule, Fahrtregler, Auswerte-, Umschalt- und Funktionsbausteine... Alle halbe Jahre versucht sich wieder jemand an einem noch universelleren, mit noch mehr Ausgängen... Und alle versammeln sich mehr oder weniger an einem Ort im Modell, und von dort aus schlängeln sich die Leitungen zu jeden einzelnen Verbraucher und Servo.
Für den Wunsch nach Bussystem bleibt also Selbstbau.
Ich finde den I2C nicht ganz so verkehrt. Es sind ja im Modell doch nur Entfernungen von 1-2m zu überbrücken. Hat den Vorteil, daß der zentrale Controller quasi per "Broadcast" Befehle an die verteilten Knoten geben kann, und nicht per Daisychain wie bei RS232 oder RS485.
Kenne mich leider auch nicht so richtig aus - könnte man die Fehlertoleranz erhöhen, indem man als verteilte Knoten nicht Hardware-Bausteine verwendet, sondern wiederum kleine Controller, die Kommunikationsfehler besser ausbügeln?
Aber das ideale habe ich noch nicht gefunden. CAN wäre Overkill, SPI kenne ich nicht gut genug, und es gibt noch zig weitere Industrie-Busse... wer die Wahl hat hat die Qual.
Klar spart man sich nicht die Verkabelung an den LEDs bzw. Verbrauchern. Aber wenn ich z.b. ein Mast mit 10 Lampen habe und einen mini motor der das Radar dreht, dann wäre es schön wenn ich da nicht 12 Kabel ziehen müssen durchs Boot. Zusätzlich muss da ja dann auch ein Stecker dran, weil der Mast im Aufbau ist und angenommen werden kann. Es können in einem Boot schnell mal 40-50 LEDs geben. Das wird dann schnell wild. Die Spannung ist übrigens überall gleich mit 6V.
Beim Bussystem bin ich offen. SPI mit Schieberegister habe ich auch schon mal angeschaut. Wäre auch ok. RS232 wäre Overkill, weil ich dann ja auch wieder ein Protokoll implementieren müsste.
Die kritischen Steuerungen des Boots bleiben natürlich im Standard. Also Lenkung und so wird nicht über den MC gemacht. Es geht nur um die Sonderfunktionen.
Generell geht es mir hier ja hauptsächlich um den Weg und das basteln. Im Studium habe ich mit humanioden Robotern gearbeitet und die Servos dafür waren im RS485 Bus. Ich fande das damals eine super schöne Lösung.
@Tom: Freut mich, dass ich nicht alleine bin mit der Idee.
Da ich im Rumpf und in den Aufbauten nicht hunderte einzelne Kabel für
jeden kleinen Verbraucher vom ESP32 aus verlegen möchte
Mein Gott, wie viele Lämpchen willst du denn einzeln steuern ?
Hunderte ist doch komplett unrealistisch, oder bekommt jedes Bullauge eine elektrisch verstellbare Jalousie und jeder der Titanic-Kabinen eine einzeln dimmbare Ambientebeleuchtung ?
Vergiss nicht, dass jeder CAN-Bus Endpunkt eine Platine braucht, das macht man ja im Auto auch nicht so.
Jeder Verbraucher hat erst mal Anschlüsse die NICHT CAN-Bus sprechen, sondern einfach Strom wollen. Das sind üblicherweise 2 Kabel, weniger werden es auch mit CAN nicht (dort zumindest 4: VCC, GND, CAN_H, CAN_L) und damit weniger. Es bringt nichts, mit CAN nun aus 2 Leitungen 4 zu machen, erst bei mehr als 4 Verbrauchern spart es Drähte.
Was willst du bei LED mit ULN Treibern, für ein Modell reichen doch 20mA satt, vielleicht mit Ausnahme des Flak-Scheinwerfers.
Zähle also realistisch deine Verbraucher, überleg welche Treiber du BRAUCHST (und ein Motor
Wenn alle Verbraucher und Treiber in voller Ausbaustufe bekannt sind, kannst du uberlegen ob du Portexpander brauchst, oder ob die LED nicht einfach eine Kette von WS2812 sein können und die L9110 nicht direkt an den ESP dürfen.
Und erst dann uberlegt man, welche Platinen den minimalen Aufwand erfordern, und ob es unbedingt CAN sein muss.
Klar spart man sich nicht die Verkabelung an den LEDs bzw. Verbrauchern.
Aber wenn ich z.b. ein Mast mit 10 Lampen habe und einen mini motor der
das Radar dreht, dann wäre es schön wenn ich da nicht 12 Kabel ziehen
müssen durchs Boot.
Der Aufwand kommt wohl eher auf die Größe des Boots an: Wenn der Slave nur 3cm vom Master entfernt ist, ist die Aktion ziemlich sinnfrei.
Wenn es darum geht, Aufbauten vom Rumpf zu trennen und dabei wenig Kabelverhau zu haben, ist es sinnvoll.
Aber I²C? Da kann man auch anderen einen Open-Collektor-Bus verwenden (z.B. UART oder SPI auf Open-Collektor; oder One-Wire).
Dazu setzt man ein "popeliges" Protokoll auf der UART-Schnittetelle um, damit die Slaves auch wissen, ob die Nachricht gültig und überhaupt für sie ist.
Als Slave kann man dann auch irgendwelche 8-Pinner verwenden.
Natürlich erspart es nicht die End-Verdrahtung der einzelnen Lämpchen,
aber es ist schon praktisch, wenn man trennbare Einheiten hat (z.B.
Aufbauten oder Fahrerhaus), die nicht mit zig Adern mit der Zentrale
verbunden sind. "Früher" hat man an dieser Stelle 37- oder 50polige
Sub-D-Stecker verbaut, aber das ist ja sowas von 80ies...
Wedico hatte damals eine mehrpolige Diodensteckervindung zwischen Zugmaschine und Auflieger.
Später hat sich irgendwer eine IR-Übertragungsstrecke in den Königsbolzen gebaut (erfordert dann eine eigene Stromversorgung im Auflieger).
I2C-Bus war urspruenglich dazu gedacht, mehrere ICs auf einer Platine zu
verbinden.
Das ist zwar grundsätzlich richtig aber es ist selbst im Professionellen Bereich nicht unüblich, dass I2C über die Platinengrenze hinweg benutzt wird. Dabei reden wir nur von wenigen Meter, nicht irgendwie 100m weiter. Die Entfernungen in einem RC-Modell sind überschaubar, I2C dürfte da über mehrere Platinen hinweg problemlos anwendbar sein. Ich selbst hab I2C im Fastmode über einen Meter Flachbandkabel gejagt, war gar kein Thema, völlig problemlos.
Matthias S. schrieb im Beitrag #8087226:
Bussystem ist schön und gut, aber es spart nichts an der Verkablung von
Lämpchen,
Im Grunde schon ein wenig: Du kannst alles dezentralisieren und so Kabel sparen da nur das Bus-System quer durchs Modell gezogen werden muss. u.a. das ist der Grund warum wir heutezutage drölfzig Steuergeräte im Auto haben und nicht alles irgendwo zentral sitzt. Man muss es natürlich klar durchdenken damit man wirklich einen Vorteil hat, ich denke das ist Ziel des Threads
