TRX-4 Drohne Ford Bronco

  • Hallo,


    ich bin neu hier im Forum.

    Normalerweise fliege ich Copter und Thermik-Elektrosegler.

    Ich habe mich von den genialen Videos auf Youtube inspirieren lassen und mir einen TRX-4 Ford Bronco zugelegt.


    Wie alle meine Modelle habe ich den Bronco auch "drohnifiziert".


    Akkuhalter und sämtliche Elektronik, bis auf die Servo und Motor, habe ich entfernt.

    Stattdessen finden folgende Komponenten in einer 3D gedruckten Elektronik-Box platz, die die Stelle vom Akkuhalter einnimmt.

    - AUAV-X2.1 Autopilot von mrobotics.io

    - GPS Neo M8N

    - 868 MHZ SIK Telemetrie Sender für Mavlink Protokoll

    - FrSky R-XSR Empfänger mit FrSky Telemetry Passthrough


    Der Deckel der Elektronik-Box is mit einer Moosgummi-Dichtung versehen.

    Die Kabel werden einfach mit der Moosgummi-Dichtung mit eingequetscht.

    Ich hoffe das ist einigermassen Spritzwasser resistent.


    Der Autopilot läuft mit der Ardupilot Rover Software (http://ardupilot.org/rover/)


    Am vorderen Karo-Halter habe ich eine Power-Box montiert.

    Die Power-Box enthält:

    - BEC für den Autopiloten mit Akku Strom- und Spannungsmessung

    - 5V BEC für die Servos

    - Motor-Treiber H-Brücke zur Ansteuerung des originalen Titan brushed Motors


    Ich verwende keinen üblichen ESC.

    Der Autopilot kann direkt ein PWM-Signal für eine H-Brücke ausgeben.

    Ich verwende den "Pololu G2 High-Power Motor Driver 18v17" https://www.pololu.com/product/2991

    Der Motor-Treiber ist mit modernen FETs ausgerüstet und braucht bis 17A keine Kühlung.

    Ich habe keine nennenswerte Erwärmung festgestellt, auch wenn der Treiber in der geschlossenen Power-Box untergebracht ist.

    Die Strombelastung im Crawler ist ja auch eher gering.

    Ich mag normalerweise keine brushed Motore.

    Der original Titan-Motor arbeitet damit für mein Verständnis so gut, dass ich das erst einmal so lasse.

    Der Bronco lässt sich damit sehr feinfühlig von extrem langsam bis volle Pulle bewegen.

    Bei 16kHz PWM Frequenz pfiept da auch nichts.

    Bei neutral-Gas ist die Bremse aktiv, der Motor wird kurzgeschlossen. Bremst zwar nicht so stark wie der originale Traxxas Regler, aber doch gut genug.



    Der Akku ist über der Vorderachse platziert.

    Ich verwende 3s LiIon Rundzellen 18650, 20700 und 21700 mit 3Ah, 4Ah und 5Ah.

    Die passen da perfekt rein.


    Die Beleuchtung habe ich mit WS2812b "Neopixel" RGB LEDs realisiert.

    Zunächst nur die Front- und Rückleuchten mit den Funktionen Licht aus/ein/Fernlicht, Bremslicht un Blinker.

    Mangels Leiterplatte habe ich für die Frontscheinwerfer einen Rahmen 3D gedruckt und die LED through-hole darin verklebt und mit Fädeldraht verkabel.

    Dann mechanisch mit Epoxy versiegelt und damit hoffentlich auch wasserfest gemacht.

    Die seitlichen und Rückfahr-Lichter kommen noch. Vielleicht auch eine 8x4 Neopixel Matrix hinter dem Kühlergrill.

    Jede LED kann einzeln mit 24bit RGB angesteuert werden.


    Zur Licht-Steuerung verwende ich einen "Adafruit Trinket M0" Controller, der über den SBus-Ausgang vom Autopiloten alle 16 Kanäle geliefert bekommt.

    Von Chassis geht nur ein 3-adriges Kabel zum Prozessor in der Karo (Strom + SBus)

    Die Verkabelung der LED ist wegen dem Neopixel Bus-Konzept relativ übersichtlich.


    Der Ardupilot kann neuerdings WS2812 LEDs auch direkt ansteuern. Die Programmlogik kann dann per LUA-Script auf dem Autopiloten implementiert werden. Wenn das etwas weiter ausgereift ist werde ich darauf umstellen. Der Trinket M0 wird dann überflüssig.


    Telemtriedaten kommen zum einen über einen 868 MHz Mavlink Datenlink vom Autopiloten zur Bodenstation am PC oder Smartphone (z.B. Mission Planner oder QGroundControl).

    Zum anderen liefert der Autopilot den Telemetrie-Stream über FrSky Telemetry Passthrough zum FrSky Sender, wo die Daten mit dem YAAPU Telemetry Script visualisiert werden. https://github.com/yaapu/FrskyTelemetryScript

    YAAPU ist zwar eher für Flieger gedacht, geht aber mit dem Rover auch ganz gut.


    Als Sender verwende ich eine FrSky Q X7, die ich auf "Taranis Pistola" umgebaut habe.


    Gefahren bin ich damit noch nicht sooo viel. Nur ein paar Waypoint-Missionen im Garten und ein wenig Crawlen im Manual-Mode.


    So, genug Infos fürs erste.

    Happy Crawling!


    Rainer

  • =O=O=O Ich verstehe zwar vielleicht nicht die Häfte von dem was Du schreibst :scratch:,


    finde es aber absolut spannend und warte mal auf ein Video zur Verdeutlichung! :jaja:

  • Hallo Rainer,


    Willkommen im Forum! :thumbup:


    Ich verstehe auch nur die Hälfte ?(


    Über Telemetrie im Auto habe ich auch schon nachgedacht, da ich für ein Projekt eine Futaba T14SG nutzen will um dann über Telemetrie Akku/Empfänger Spannung (geht ja schon über den Empfänger) sowie Motordrehzahl, Temperatur Überwachung von Motor und ESC. Eventuell wäre noch interessant ein Gyro zu nutzen um ein aktives Fahrwerk mit Niveau Regulierung je nach Hangfahrt umzusetzen.


    Bei manchen Dingen kommen mir Fragen auf.


    1) Wofür einen Autopiloten nach GPS? Warum ich das Frage? Mir ist klar das damit Dein TRX-4 autonom fahren kann, aber nach meiner Ansicht nur im relativ einfachen Gelände. Dort wofür ein TRX-4 Chassis eigentlich konzipiert ist, für schweres Gelände, dürfte autonomes Fahren ohne Sensoren bis zum Abwinken gar nicht funktionieren - oder? Wenn ich meinen TRX-4 durchs Gelände bewege, muss ich nicht nur das Fahrzeug genau beobachten, sondern auch das Gelände "lesen" um zu sehen wie ich mit den Stärken meines Autos das Gelände meistern kann und ebenfalls die Schwächen des Wagens kennen um möglichst zu verhindern, das mein Auto durch die Gegend purzelt. Denn das ist ja der Reiz am Fahren mit dem TRX-4 --- zumindest für mich.


    2) Wofür benötigst Du RGB LEDs in einer Fahrzeugbeleuchtung? Oder anders ausgedrückt, sind RGB LEDs nicht ein "Zuviel an Farbenspiel"? Für Blinker sind nur gelbe LEDs ausreichend, für Rücklichter sind rote LEDs ausreichen, die sollten auch nicht zu hell sein, damit das Rücklicht nicht nur unnatürlich hell erscheint, sondern andere Fahrer nicht blendet. Fahrlicht ist weiß und sollte für Nachtfahrten dann wiederum hell sein um das Gelände gut erkennen zu können. Ich möchte fast sagen, das 5050 SMD RGB LEDs für Blinker zu groß, für Rücklichter zu hell und für Fahrlicht kein schönes weißes Licht abgeben - ist aber nur meine Meinung.


    Ansonsten scheint das ein interessantes Projekt zu sein und ich werde das mit Neugier verfolgen. Was heutzutage mit 3D Druck möglich ist, ist an Deinem Projekt zu sehen. Eine individuell gedruckte und mit Elektronik bestückte Fernsteuerung ist schon ein Hammer - für mich unerreichbare Dimensionen des Hobbies. :respekt:


    Vielleicht achtest Du darauf, das Dein TRX-4 nicht zu Front lastig wird, das wirkt sich bei Bergabfahrten negativ aus.


    Ich wünsche Dir viel Spaß im Forum und viel Freude an Deinem TRX-4!


    Herzliche Grüße, Detlef

  • Hallo Detlef,


    das autonome Fahren mit einem Modellauto steckt sicherlich noch in den Kinderschuhen. Ich denke aber das wird noch Fahrt aufnehmen. Der TRX-4 ist fürs autonome Fahren ganz gut geeignet, weil er langsam genug fährt und auch vorm Blumenbeet nicht zurückschreckt. Autonomes Fahren geht aktuell sicherlich nur auf einfachem Gelände. Obwohl ich heute Nachmittag mal testweise auf einem gepflügten Acker unterwegs war. Wenn man langsam genug fährt würde das schon auch autonom gehen. Das erweitert aber auf jeden Fall den Anwendungsbereich. Ich kann ja jederzeit auf manuell umstellen und selber fahren. Macht auch Spass das Teil einfach mal ein paar Runden im Garten drehen zu lassen.


    Das schöne an den NeoPixel LEDs ist, dass ich die Farbe und auch die Helligkeit mit 24 bit RGB nach Belieben einstellen kann. Jedes LED hat eine eingebaute Konstantsromquelle auf jeder Farbe, sodass auch mehrere LEDs und auch bei nicht ganz so stabiler Betriebsspannung immer die gleiche Farbe und Helligkeit zeigen. Es gäbe auch RGBW NeoPixel mit einem zusätzlichen vierten Weiß-Kanal. Darauf habe ich jedoch verzichtet.


    Wenn das Licht zu hell ist, dann mach ichs im Programm einfach dunkler. Ich könnte die Helligkeit auf einen Poti in der Funke legen und dann stufenlos einstellen. Auch die Farbe vom "Weiß" kann ich nach Belieben einstellen. Ist es zu blau, mach ichs einfach ein wenig gelber. Und wenn ich morgen vielleicht mal ein rot/blaues US-Polizei-Blaulicht haben möchte, dann ist das nur eine Frage der Software.

    Wenns autonom fährt ist natürlich der Warnblicker an.

    Im Video unten sieht man, dass ich die unteren Front-Scheinwerfer sowohl fürs weiße Fahrlicht als auch fürs gelbe Blinklicht verwende. (das Gelb kommt im Video nicht so gut rüber wie es tatsächlich ist.)


    Das Rücklicht ist aktuell eine einzige LED, kombiniert Rücklicht, Blinker und Bremslicht.

    Das Rücklicht hab ich auf Rot mit 25% Helligkeit eingestellt.

    Wenn ich Bremse kommt 100% Weiß drauf. Durch das rote Glas wird das Weiß auch Rot, aber eben viel heller.


    https://youtu.be/9kZRhWJQQK8



    Viele Grüße

    Rainer

  • Geiler Shit :thumbup:

    Einfach mal so unheimlich viele Bastel- und Hirnschmalzstunden in einen Beitrag gepackt - flash!


    Von den WS2812 hab ich mal 5.000Stück in einem Modell verbaut, da kann man schon echt coole Sachen damit machen :headbang:

    Gruß aus der Schweiz :D
    Turnschuuh


    ░▒▓█▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄█▓▒░ mein RC4WD Raptor - Defender - Job

  • Hallo Rainer,


    Gefällt mir sehr gut die Möglichkeiten die sich durch die programmierbaren LEDs eröffnen. Leider gibt es diese nicht in der Bauform 1206, sonst könnte ich sie in meinen kleinen Orlandoo Modellen (Maßstab 1/32) einsetzen, wo die komplette Licht- und Motorsteuerung (ebenfalls mit Pololu Motortreiber) von einem kleinen Pololu-Arduino Board erledigt wird. Bei diesem Maßstab geht es natürlich extrem eng zu mit dem Platz für die Elektronik.


    Mein aktuelles Modell (ein Orlandoo OH32P02 Toyota Tundra) wird wohl auch ein wenig autonom fahren können. Ich werde versuchen einen Lern-Modus zu implementieren. Ob das klappt weiß ich noch nicht.


    Hier in diesem Tread sind meine Arduino-basierten Steuerungen dokumentiert: Lichtsteuerung & mehr mit Arduino


    Gruß

    RCfreund

  • Moin Rainer!


    Du schreibst von NeoPixel LED - was ist das? Ich frage, weil mir der Begriff bei Dir das erste Mal begegnet und ich in dem was Du an Bildern gezeigt hast, eine 5050 RGB SMD LED erkenne. Eine RGB LED ist ja eigentlich nichts anderes als 3 LED Chips in einem Gehäuse (hier das übliche 5x5mm LED Package) die jeweils sichtbares Licht in einer anderen Wellenlänge emittieren (R = Red / G = Green / B = Blue) und durch Mischung der Ansteuerung dann auch alle möglichen Mischfarben erreichen können. Die Helligkeit wird dann über die Stromstärke geregelt. Klar wird die Ansteuerung über 4 Leiterbahnen geregelt, 1x ein gemeinsamer Minuspol und drei separate Steuerleitungen, deren Steuerung praktisch über drei separat voneinander geschalteten dimmbaren LED Treibern (regelbaren Konstantstromquellen) gewährleistet wird. So gibt es ja auch LED Leuchten, die stufenlos von Kaltweiß (6500K) bis hin zu Warmweiß (2700K) geregelt werden können. So ist es mir aus der Lichttechnik bekannt. Was bedeutet nun "NeoPixel"? Ist damit die LED Steuerung gemeint? Ich lerne gerne, deswegen frage ich viel wenn ich etwas nicht kenne.


    Das autonome Fahren ist bestimmt sehr interessant und wenn ich mir so vorstelle die Steuerung über GPS mit Neigungssensoren, Beschleunigungssensoren, Abstands- oder Entfernungs-Messsensoren und Kameras zu kombinieren, sind wir über die Rover Technik ganz schnell im Bereich Robot Technik.

    Das ist natürlich eine vollkommen andere Ambition das TRX-4 Chassis zu nutzen als zum Spaß manuell im Gelände zu fahren...


    ...wobei ein Acker für den TRX-4 eigentlich noch fast "Straße" ist. Ich denke beim autonomen Fahren kommt es in erster Linie darauf an eine ganz bestimmte Strecke exakt zu fahren. Beim Fahren im Gelände kommt es darauf an Hindernisse in einem bestimmten Winkel und einer Linie an- und überfahren damit das Fahrzeug das Hindernis überwindet und nicht stecken bleibt oder umfällt.





    So in etwa. Denkst Du das könnte mit Sensoren im autonomen Fahren auch gemeistert werden? Kann praktisch das fahrerische Können des Menschen durch KI ersetzt werden? - Das ist für mich eine interessante Frage, die ich durch Deinen Beitrag nicht nur technisch, sondern auch philosophisch überdenke.


    Fahren Rover auf dem Mars eine zuvor erkundete Strecke per autonomen Fahren oder können die Rover mittels Sensoren und KI, Hindernisse selbstständig umfahren oder gar bewerten ob sie die Hindernisse überfahren können?


    Ich stimme Turnschuuh zu, Dein Beitrag lässt völlig andere Perspektiven aufkommen und das mit so viel fundiertem Hirnschmalz das es sich nicht um Hirngespinste handelt sondern um be-greifbare Ideen und Umsetzungen! Nach meiner Meinung wird das eine Bereicherung des Forums und ich bin gespannt was da noch so kommt...


    Danke und herzliche Grüße, Detlef

    Einmal editiert, zuletzt von Lifthrasir ()

  • Gegoogelt hatte ich vorher, nur ist der Unterschied für mich nicht 100%ig verständlich? Vielleicht habe ich noch nicht genug Kaffee?

    Also wenn ich eine RGB LED und den Begriff "NeoPixel" dazu nehme, dann ist der Unterschied nach meinem Verständnis, das jede RGB LED einen zusätzlichen Adress- oder Code-Chip integriert hat um in einem Verbund an LEDs jede LED gezielt mit einem digitalen Adress-Code anzusprechen und anzusteuern. Also vergleichsweise mit der Adressierung beim Futaba S-Bus Verfahren?


    Wenn mein Verständnis richtig ist, sollte der nächste Schritt in der Beleuchtungstechnik von der passiven LED zu aktiven LED (z.B. mit integriertem Photowiderstand) mittels digitaler bidirektionaler Steuerung/Kommunikation/Telemetrie - wie auch immer bezeichnet - stattfinden. Oder?


    Eine Rückmeldung der anliegenden Stromstärke wäre dann ebenfalls denkbar und somit würde das intelligente Licht noch intelligenter. Da würden sich wieder bisher ungeahnte Ideen und Möglichkeiten auftun, gerade auch in Bezug auf OLED und Displays.

    Einmal editiert, zuletzt von Lifthrasir ()

  • Gegoogelt hatte ich vorher, nur ist der Unterschied für mich nicht 100%ig verständlich? Vielleicht habe ich noch nicht genug Kaffee?

    Die normalen 5050 RGB's leuchten alle in der selben Farbe/Helligkeit.

    Bei den digitalen LED's kann man wirkich jeder einzelnen LED sagen, wie und ob sie zu leuchten hat.

    z.B. so ein digitaler LED Streifen hat 144LED/m, eine Eingangsseite und Ausgangsseite. Betrieben wird das ganze mit 5VDC und einer Signalleitung. Über die Signalleitung kommen dann die Daten und sagen den LED's dann, was läuft ;)


    So kann man mehrere Streifen hintereinander machen, mit Zwischenspeisung für Spannung theoretisch endlos. Nur wenn die 2. LED ausfällt, kommen ab da keine Info's zur nächsten LED.


    Für das RC-Fahrzeug wäre es easy, hinter jede Lampe solch eine LED zu verbauen und dann entsprechend anzusteuern. Gibt schon viele, die das so gelöst haben.


    Theoretisch könnte man sich damit ein großes LED-Display bauen, wenn man die Streifen nebeneinander macht.

    Gruß aus der Schweiz :D
    Turnschuuh


    ░▒▓█▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄█▓▒░ mein RC4WD Raptor - Defender - Job

  • Die normalen 5050 RGB's leuchten alle in der selben Farbe/Helligkeit.

    Bei den digitalen LED's kann man wirkich jeder einzelnen LED sagen, wie und ob sie zu leuchten hat.

    Normale LED Stripes sind üblich so aufgebaut, das 3 LEDs in Reihe mit einem SMD Vorwiderstand geschaltet sind und dann je nach Länge des LED Stripe diese Reihenschaltung mehrfach parallel an eine 12V Konstantstromquelle geschaltet werden, weil die Leitungen durchgeschliffen sind. Klar das dann alle LEDs gleich angesteuert werden.

    Wenn jede einzelne LED angesteuert wird, kann das entweder durch eine direkte Verdrahtung jeder einzelnen LED erfolgen, was natürlich bei der Anzahl viel zu umständlich ist - oder es werden kodierte Steuersignale genutzt, die dann durch einen Empfängerchip entschlüsselt werden.


    So kann man mehrere Streifen hintereinander machen, mit Zwischenspeisung für Spannung theoretisch endlos. Nur wenn die 2. LED ausfällt, kommen ab da keine Info's zur nächsten LED.

    Das mit der Unterbrechung der Informationssendung wenn eine LED defekt ist, ist unlogisch und kann ich so nicht nachvollziehen, denn der Ausfall einer LED durch einen Defekt unterbricht nicht die durchgehenden Steuerleitungen, über die die codierten Steuerbefehle gesendet werden. - Oder?


    Für das RC-Fahrzeug wäre es easy, hinter jede Lampe solch eine LED zu verbauen und dann entsprechend anzusteuern. Gibt schon viele, die das so gelöst haben.

    Das ist eine Lösungsmöglichkeit, jedoch für den Bau von bisherigen Modellautos und deren Vorbilder unnötig, da es bisher keine Scheinwerfer gibt die die Lichtfarbe respektive die Funktion ändern --- außer den neuen Blinkern die Tagfahrlicht und Blinker in einem sind - aber das sind erst relativ neue Entwicklungen und dann würde eine solche Ansteuerung Sinn machen. Leider sind Tagfahrlichter im Maßstab oft so klein das es dafür in den Abmessungen noch keine direkt einsetzbare LEDs gibt, denkbar wäre dann ein Einsatz von Glas/PMMA Lichtleitern, die das Licht von einer größeren RGB LED zum Tagfahrlicht bringen.

    Die Leucht-Stärke (Simulation Abblendlicht und Fernlicht) einer weißen LED kann ich ebenso durch zwei verschiedene Vorwiderstände bewerkstelligen, eine einfachere Möglichkeit für Leute, so wie ich, die sich nicht mit programmierbarer Steuerung wie Arduino auskennen.


    Diese Möglichkeiten der Elektronik wie Lichtsteuerung und autonomes Fahren sind auf jeden Fall sehr interessant! Und wenn ich betrachte was sich im Modellbau tut, angefangen von Antriebs und Akku Technik über 3D-Druck, Telemetrie und bidirektionale S-Bus Steuerung bis zu den hier gezeigten Möglichkeiten --- dann sind nach "oben" wahrscheinlich keine Grenzen mehr...


    ...bitte mehr davon! Danke!


    Herzliche Grüße, Detlef

    3 Mal editiert, zuletzt von Lifthrasir ()

  • Das mit der Unterbrechung der Informationssendung wenn eine LED defekt ist, ist unlogisch und kann ich so nicht nachvollziehen, denn der Ausfall einer LED durch einen Defekt unterbricht nicht die durchgehenden Steuerleitungen, über die die codierten Steuerbefehle gesendet werden. - Oder?

    Jede LED enthält neben den 3-4 LED-Steinchen einen Steuerchip, der einen Dateneingang hat und einen Datenausgang, damit wird eine Kette gebildet.

    Meist geht der Chip kaputt und mit ihm der Datenausgang.

    Wenn dir also unterwegs eine LED stirbt, ist das in der Regel der Steuerbaustein, und der gibt die Daten nicht mehr "nach unten" weiter -> alle nachfolgenden LEDs sehen nix mehr und sind/bleiben duster.

    jedoch für den Bau von bisherigen Modellautos und deren Vorbilder unnötig, da es bisher keine Scheinwerfer gibt die die Lichtfarbe respektive die Funktion ändern

    Der Trick ist hier nicht die Farbänderung, sondern das nahezu beliebig lange Ketten mit nur plus/minus/Daten gebaut werden können.

    Der Karostecker hat dann nur 3 Pole. Egal ob da ein Polizeiauto mit doppeltem rot/blauem Warnbalken läuft oder ein einfacher Polo mit 2 Scheinwerfern, 2 Rücklichtern und 4 Blinkern.

    Außerdem kann man zumindest theoretisch die Farbe "fest anpassen". Kauf mal passende LEDs für Blinker im richtigen Orange, oder 5mm-Scheinwerfer und 3mm-Standlichter in übereinstimmender "Halogen"-Farbe.

    Mit "Neopixeln" kann man in der Software einfach "ein bissel mehr R zum G&B" geben und die Lampe wird wärmer.

    Wobei die Dinger aufgrund des Aufbaus für Scheinwerfer m.E. eher nicht geeignet sind, aber du verstehst was ich meine.

  • Jede LED enthält neben den 3-4 LED-Steinchen einen Steuerchip, der einen Dateneingang hat und einen Datenausgang, damit wird eine Kette gebildet.

    Meist geht der Chip kaputt und mit ihm der Datenausgang.

    Wenn dir also unterwegs eine LED stirbt, ist das in der Regel der Steuerbaustein, und der gibt die Daten nicht mehr "nach unten" weiter -> alle nachfolgenden LEDs sehen nix mehr und sind/bleiben duster.

    Ist das wirklich so? - Unglaublich das eine solch fatale Schwäche in die Massenproduktion kommt.


    Ein Verfahren ähnlich der digitalen S-Bus Codierung wäre doch auch bei der Ansteuerung einzelner LEDs mit integrierten Decodierung Chips und der damit möglichen einzelnen Adressierung im Verbund ohne Datenverlust für andere LEDs bei dem Defekt einer einzelnen LED.

    Für eine RGB LED Verkettung wären lediglich 4 Leiterbahnen, 1x Plus und drei Steuerleitungen notwendig, sowie ein Schlüssel/Adress-Chip in den LED Packages und Steuersignale denen ein Adresscode vor gesendet wird.


    Jede LED wäre einzeln ansprechbar und bei einem Defekt würde nur eine LED ausfallen.

  • Dann bräuchte aber jede LED eine feste Adresse, wie soll das gehen? Bei den NeoPixelstreifen bekommt die 1. LED ihre Infos und reicht die an die nächste weiter. So weiß jede LED, welche Nr. sie in dem Streifen hat.

    Vorteil des vorhandenen Systems: Man kann den Streifen nach jeder LED einkürzen oder neu anfangen. Falls mal eine LED kaputt gehen sollte, reich es wenn man Din und Dout der defekten LED brückt und im Programm das ganze anpasst.

    Gruß aus der Schweiz :D
    Turnschuuh


    ░▒▓█▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄▀▄█▓▒░ mein RC4WD Raptor - Defender - Job

  • Unglaublich das eine solch fatale Schwäche in die Massenproduktion kommt.

    Das ist keine fatale Schwäche, das ist ein tolles System, nur das "der Chinamann" es bei der Verarbeitung schleifen lässt.

    Probleme gibt's nur bei den Billigststreifen, bei denen z.B. Widerstände oder Kondensatoren fehlen.

    ähnlich der digitalen S-Bus Codierung

    Das erfordert eine Programmierung der Adressen.

    Möglich bei 10 Servos, unmöglich bei 5000 LEDs (siehe Turnschuuh's Projekte).

    Steuersignale denen ein Adresscode

    Da müsste die Steuerung ja Adressen speichern oder verteilen.

    Bei den WS2812 ist das ein simples Schieberegister.

    D.h. du kannst einfach eine LED an den Proz machen und 3x 8 bit rausblasen, und die leuchtet dann. Dabei ist egal, welche Bauform die hat, oder sogar ob überhaupt eine angeschlossen ist.

    Speicherbedarf minimal, Rechenaufwand minimal, Geschwindigkeit maximal. So kann z.B. im Weihnachtsstern ein kleiner 4kB-Prozessor 50 LEDs ansteuern, und das sieht auch noch toll aus... ;)


    Letzteres ist im übrigen auch der Grund für das von dir vermutete Problem:

    Jede LED nimmt sich die ersten 24bit vom Datenstrom ab für ihre eigenen Farben, danach wird sie quasi durchsichtig und reicht die Daten durch.

    Das erfordert nunmal, das jede LED einen Treiber am Datenausgang hat, und ohne den wäre es eh unmöglich, die hohen Datenraten und Leitungslängen zu schaffen.

    Immerhin kann man eine Kette von etwa 1000LEDs mit ca. 25Hz aktualisieren, wenn der Prozessor so schnell die Daten liefern kann.

    1000 LEDs sind selbst beim dichtest gepackten Stripe mit 144LEDs/m knappe 7 Meter, und das mit nur einem Datenpin.

    Und eine Leitung von mindestens 7m Länge kannst du nicht mit einem Datensignal von einem Microcontroller steuern, der kann gar nicht genug Strom liefern, das Signal verschleift und wird nicht mehr erkannt.

    Bei den WS2812 dagegen ist jede Datenleitung nur maximal wenige Zentimeter lang, da gibt's keine solchen Probleme.

  • Ich bin kein Computer Techniker oder Elektroniker - für mich sind das reine Verständnis Beispiele.


    Eine Adressprogrammierung wäre während der LED Produktion ohne weiteres möglich, mit einer 12 Bit Verschlüsselung hätte ich schon 4096 Adressen. In der Digitalen Technik ist heute schon so vieles möglich, wenn ich bedenke was wir für Funktionen und schaltungsspezifische Parameter in IC programmiert haben, nur damit unsere Konkurrenz unsere Funktionen schwerer kopieren konnten, dann denke ich das auch solch eine Adressierung und codierte Signale möglich sind, die vielleicht über Verstärker Bausteine nach einer bestimmte Datenbuslänge wieder aufgearbeitet werden? - Natürlich ist der Aufwand und der damit erzeugte Zweck als rentabler Kosten/Nutzenfaktor zu sehen, aber ich denke rein theoretisch sollte so etwas doch möglich sein - oder? Was dann praktisch und bezahlbar auf den Markt kommt steht auf einem anderen Blatt.


    Vielleicht sollten wir das Thema nicht weiter ausdiskutieren ohne die Zustimmung des Themenstarters, damit wir nicht zu sehr in OT abrutschen? Ich danke Euch für Eure Erklärungen! Das Thema fasziniert mich, weil es so viele Möglichkeiten des "Wenn" gibt, sich die Welt so enorm erweitert - sorry wenn es zu sehr OT ist.