Beiträge von Pesi

    Ich hab' den Fehler gefunden :) - hat gerade mal drei Minuten gedauert... ^^


    Es liegt tatsächlich an der Konfiguration des Players - ich hab' einfach mal ne tpm2-Datei mit weiß drin auf die Karte, tatsächlich bleiben die weißen Pixel dunkel...


    noch mal in's Manual geguckt: Da ist standardmäßig RGB-LEDs eingestellt, aber auch der RGBWMODE = 1 - also weiß als 4. Kanal (den's bei RGB natürlich nicht gibt) umrechnen. _CONFIG_-Datei mit RGBWMODE = 0 auf die Karte, und schon geht's:



    Das ist natürlich ungünstig - der technische Laie macht da halt erst mal seine tpm2-Dateien auf die Karte, und wundert sich (oder, je nach Animation/Programm vielleicht auch nicht), warum da kein weiß kommt.


    Kann mir jetzt nur vorstellen, dass er bei Dir die _CONFIG_ nicht gelesen hat, evtl. ist da noch ".txt" hinten dran gestanden...?


    Ich schreib' denen jetzt gleich mal, dass die das ändern sollen, also default-mäßig ne sinnvolle Kombination von LEDTYPE und RGBWMODE drin steht, damit das auch ohne config-Datei funktioniert - und dass die vielleicht auch mit .txt hinten dran eingelesen wird... die sind recht fix, meine gewünschte Änderung im Manual war hier auch schon in der gedruckten Version drin! :)


    Ansonsten super Teil! - Sehr cool finde ich die Funktion, dass man verschiedene Dateien per Taster abrufen kann... ich baue gerade so eine 48 x 8-Pixel-Laufschrift (6 m x 1 m), da kommt das dann hin, und man kann einfach per Knopfdruck verschiedene Texte abrufen - einem Kumpel habe ich letztes WE LED-Stripes in seine alten Rasterleuchten eingebaut:



    Da kommt dann auch so ein Teil hin, kann er per Knopfdruck verschiedene Animationen auswählen... für die paar Piepen fang' ich da echt nicht das selber basteln an...


    P.S.: Die Daten dafür kommen dann natürlich von Jinx! - habe mal mit dem Hexeditor geguckt, da liegt das Problem nicht, weiß ist da weiß in der Datei...

    Ah, noch was: Es könnte ja auch sein, dass der Controller da oben drin das aufteilt, und an 20 Ketten parallel ausgibt - mache ich bei meinen selbst gebauten Controllern auch so (Code ist irgendwo im Forum).


    Z.B. hier:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Das sind auch nur 36 Ketten, die runter hängen, da geht auch keine Leitung wieder nach oben oder von Kette zu Kette…


    EDIT: Ah, noch was: Bei dem Preis für das Dings braucht man eigentlich gar nicht mehr mit selbst basteln anzufangen…


    Noch mal EDIT: Sorry, unkonzentriert! 🤪 - Du hattest ja geschrieben, dass Du ne andere Größe brauchst… und ja, da wird wohl genau so was drin sein (wie meine Controller), das eben an Kette 1 die Daten für LED 1-20 ausgibt, an Kette 2 die Daten für LED 21-40, usw.

    Es gibt tatsächlich so LED-Ketten, bei denen die Adressen fest „einprogrammiert“ sind - siehe dazu diesen Thread hier: WS2812 (SK6812) LED in Reihe Probleme


    Weiter runter scrollen, da kommt dann die Erklärung/Auflösung, wie das raus gefunden wurde…


    Ich hatte mich damals gefragt, warum zur Hölle jemand sowas baut, aber hier wäre dann die Erklärung: Damit könnte man so einen Baum sternförmig verkabeln, und trotzdem alle LEDs einzeln ansprechen… bei den Verlinkten Ketten geht‘s halt nur von 1 bis 100, k.A., ob‘s da noch welche mit mehr Einzel-Adressen gibt…

    Ah, nachdem ich nun den Thread noch mal gelesen habe (das Phänomen interessiert mich wirklich, in der Glotze kommt auch nix... ^^ ) bin ich noch verwirrter... Du schreibst oben (Post #4):


    "Vom Config-Eintrag "LEDBITS" ist da keine Rede. Woher soll man das dann wissen? Einen Hellseher beauftragen?"


    Hast aber am Samstag schon im Jinx!-Thread RE: Jinx! - LED Matrix Control ... und die nächste Matrix Software ... geschrieben:


    "

    Meine _CONFIG_ sieht so aus:

    AUTOSTART=1

    LEDCOUNT=256

    BRIGHT=100

    LEDTYPE=GRB

    LEDBITS=8

    RGBWMODE=2

    SAVE

    "


    Wie bist Du denn da dann auf die LEDBITS gekommen, mit ner Glaskugel...?! :/


    Ich kenn' mich da irgendwie langsam nicht mehr aus, was da nun Sache ist...?!?

    Wir drehen uns hier irgendwie im Kreis... 8o


    Ich habe das so verstanden, dass der Mau eben genau *nicht* einen 4. Kanal braucht, weil er normale RGB-Pixel hat (WS2812B, auch wenn das *immer noch nicht wirklich bestätigt ist*) - also hilft es ihm auch nix, das mit diesem Tool umzurechnen. Und genau das, was das Tool macht, macht der Player ja intern (wenn er so eingestellt ist, was aber natürlich bei WS2812B nix bringt, weil die ja nur RGB.....)


    Aber, trotzdem guter Hinweis: Der Mau könnte mal die von Jinx! ausgegebene Datei mit diesem Tool einlesen, und dann schauen, ob hier die Pixel richtig dargestellt werden.


    Das (Zitat Mau) "Darin die Farben" verstehe ich nicht ganz: Sind die Farben so im GIF, oder in der .tp2-Datei...? - Wenn sie im GIF so sind, müssen sie nicht zwingend in der tpm2-Datei so sein, *falls* z.B. Jinx! da Probleme beim Umrechnen hat. Deswegen, wie gesagt, das Angebot, dass Du mal so ne tpm2-Datei hier rein stellst, und ich schaue mir (oder Du selbst kanst das ja auch machen) mit nem Hexeditor an, was da drin ist...


    Ansonsten, wie gesagt, wenn Du schon so ne Unsumme für das Teil ausgegeben hast, doch einfach mal dem Support schreiben: info äd diamex bunkt de - die sind echt nett und schnell, habe denen gestern wegen eines Fehlers im Manual geschrieben, und paar Stunden drauf schon ne Antwort mit der Änderung bekommen...


    Wie schon gesagt, evtl. hast Du ja einfach nen fehlerhaften Player bekommen, und dann bringt's natürlich nix, da Stunden weiter nach dem Problem zu forschen. Sowas habe ich in der Arbeit auch immer wieder, man sucht und wundert sich, warum läuft die Sch**e nicht wie sie soll, ist doch alles richtig konfiguriert - und am Ende stellt sich raus, dass schlicht und einfach das neue Gerät ab Werk defekt ist...

    Weil, wie auch schon wiederholt gesagt, das kann nicht sein, dass das grundsätzlich nicht möglich ist, mit diesem Player weiß auszugeben. Da hätte man sicher schon diverse Male was dazu in diversen Foren etc. gelesen. Du bist jetzt tatsächlich hier im Forum (kannst gerne über die Suchfunktion nachprüfen) der Erste, der dieses Problem hat...

    Ah, OK, Verwirrung... 8o - oben hast Du den S3 (OHNE E) verlinkt, da hab' ich das Manual runter geladen, da gibt's diese Angaben mit LEDBITS usw. - Beim S3E haben sie wirklich die Keywords geändert.


    Noch mal wegen der LEDs: Auf dem Foto kann man halt auch nicht erkennen, ob das nun wirklich WS2812B sind oder was anderes. Entweder Makro-Foto, auf dem man sieht, wie viele Chips da drin sind, oder, wie gesagt, Link zum Produkt...


    Weil hier auch Verwirrung: Du schrobst ja von "versucht, die Farbe Weiß noch mit drei verschiedenen LEDs darzustellen, statt wie heute üblich, mit einer einzigen?" und im anderen Thread von "modernen Stripes" - hört sich für mich danach an, dass Du welche mit 4 Chips (also RGB und noch mal extra weiß) meinst - WS2812B haben nur RGB - aber ohne zu wissen, *was das denn nun genau ist*, wird man schlecht weiter kommen.


    Wenn das normale WS2812B sind, dann kann es unmöglich sein, dass man die nicht mit diesem Player ansteuern kann. Da hätten ja schon x Kunden denen das um die Ohren gehauen und sich in div. Foren beschwert... :D


    Vielleicht liegt der Fehler ja auch ganz woanders... also dass es in der tpm2-Datei schon falsch drin ist... wenn Du da mal eine machen kannst (oder mehrere) mit je einem Frame alle LEDs rot, alle grün, alle blau, alle weiß, dann könnte man sich das mal angucken, ob da die Farben richtig drin sind... wie sieht es denn aus, wenn Du eins der internen Programme des Players abspielst, ist denn da weiß mit dabei?



    Ach, und, ich bleibe dabei: natürlich ist es *für Dich* billiger, nen Arduino zu kaufen und was drauf zu kloppen - Aber DU musst auch nix mit dem Verkauf von sowas verdienen. Der Hersteller schon. Und der bietet dafür dann auch Support. Das kannst Du auch noch probieren, einfach mal da zu fragen, was da nun los ist... vielleicht hast Du ja auch nur leider ein "Montagsgerät" bekommen... Ich wundere mich immer bisschen über diese Mentalität in deutschen Foren, dass man fertig für den technischen Laien verkaufte Komplettgeräte preislich mit was selbst zusammen geschustertem vergleicht. Und wenn man das dann da schon "teuer" kauft, dann nicht mal beim Hersteller fragt (der im Gegensatz zum Arduino-Chinesen auch nen deutschen AP hat), sondern in irgendnem Forum... ^^


    Wenn's mit dem Teil bei Dir gar nicht klappt, dann schick' es doch zurück, und bau das schnell selbst mit dem Arduino und dem SD-Reader... bevor Du noch mehr Zeit damit verschwendest, und dann hast Du auch noch 16,75 Euro gespart... :)

    Nee, steht doch da (auf der von Mau verlinkten Seite) in der Beschreibung: "- Unterstützt RGB und RGBW-Leuchtdioden (z.B. SK6812)" - und im Manual https://www.led-genial.de/medi…nstiges/led-player_s3.pdf auch noch mal.


    Zum Thema "dass dieser Player völlig veraltet ist, und versucht, die Farbe Weiß noch mit drei verschiedenen LEDs darzustellen, statt wie heute üblich, mit einer einzigen?" - das ist auch heute noch völlig üblich, auf einer Matrix weiß aus RGB gemischt darzustellen. Mir ist auch kein professionelles LED-Panel bekannt, das für weiß einen extra Chip drin hat. Das mit der 4. Farbe (weiß) bei "Digitalen LEDs" ist nur deswegen aufgekommen, damit man diese Stripes außer buntibunti auch für Beleuchtung einsetzen kann - auf ner Matrix für Bilder o.ä. ergibt das eigentlich keinen Sinn...

    Was sind das nun genau für LEDs, haben die ne 4. Farbe (also extra weiß)...? - Du schreibst WS2812B, die haben aber immer nur RGB (siehe cdn-shop.adafruit.com/datasheets/WS2812B.pdf) - hast Du mal nen Link? - Die Chinesen verbauen oft was anderes, schreiben dann im Titel aber trotzdem "WS2812B", damit das in der Suche auftaucht, weil der Begriff einfach am bekanntesten ist.


    Wenn es wirklich RGBW-LEDs sind, dann musst Du das dem Player auch sagen, damit er 4 Byte pro Pixel ausgibt. Das Manual (lohnt sich immer, so was zu lesen) wurde ja schon erwähnt, da findest Du die Angaben...


    Tipp: Du schreibst im anderen Thread, Du hast eingestellt:

    LEDBITS=8
    RGBWMODE=2


    Beide Werte gibt es lt. Manual nicht, LEDBITS muss 24 oder 32 (naa, klingelt was...? ;) ) sein, und RGBWMODE 0 oder 1... LEDCOLORS dient dann wie gesagt nur dem Umsortieren der Farben, auch hier hilft es nix, einfach mal irgendwas rein zu schreiben (GRBW / RGBW ist kein gültiger Wert... auch LEDTYPE kommt in der Liste nicht vor, siehe S.9)


    Ach, und zu "happigen Preis von 30 Ocken" (anderer Thread): Könntest _Du_ das billiger herstellen, und dann auch noch mit Gewinn verkaufen...? 8o

    Zum 2. Problem kann ich nix sagen, kenne diesen Player nicht… Evtl. hat es was mit diesem RGBWMODE=2 zu tun…? Dass der eben für RGBW-Pixel ist, also da dann das weiß nicht aus RGB gemischt wird, sondern auf dem 4. Kanal ausgegeben, wodurch dann RGB-Pixel natürlich schwarz bleiben…


    Das 1. ist kein Bug, sondern logisch: Diese Angaben bewirken ja, dass Jinx! bzw. der Player die Farben umsortieren. Wenn Du nun bei beiden GRB einstellst, dann sortiert Jinx! die Farben um, so dass sie für Deine Matrix passen… der Player sortiert dann noch mal um, also passt es am Schluß wieder nicht mehr. Deswegen nur an einer Stelle umsortieren.


    Ich mache das bei meinen selbstgebastelten Controllern immer so, dass der Controller umsortiert… dann kann ich in Jinx! Immer RGB einstellen, und muss nicht bei jeder Matrix/Stripe etc. überlegen, was ich da nun wieder einstellen muss… 😉

    Das geht, und zwar mit Relais. Wenn ich das richtig verstehe, dass normal 2 so LED-Panels in Reihe an einer KSQ hängen, dann würde die Schaltung so aussehen:



    Es leuchtet immer nur das/die Panel, bei dem/denen das Relais offen ist, das also nicht überbrückt ist. Hier im Beispiel Gruppe 1. Gruppe 2 und 3 sind für die KSQ "nicht vorhanden", weil sie ja überbrückt sind, also so, wie wenn die Leitung da direkt zurück gehen würde zur KSQ.

    Was passieren kann:

    - Alle Relais sind geschlossen, dann hast Du einen Kurzschluß an der KSQ - das ist normal aber nicht so schlimm, wenn es nicht gerade ein super-Billo-Schrottteil ist, macht der das nix, ist kurzschlußfest.

    - Zwei oder alle Relais sind offen - dann hängen mehr als 2 Panels in Reihe an der KSQ. Dann fährt die die Spannung hoch, weil sie ja den Strom durchtreiben will. Wenn dann wieder nur 1 Panel aktiviert wird, bekommt das für einen kurzen Moment zu hohe Spannung, und kann defekt werden.


    Verhindern kann man das mit der Ansteuer-Logik. Wie geht das überhaupt, über nen Arduino, oder RasPi oder so? - Ich würde da noch ein 4. Relais auf der Primär-Seite der KSQ anbringen. Dann die Programmierung so, dass erst die KSQ stromlos gemacht wird, kurz warten, die Einstellungen für die Panels ändern (also dass halt die leuchten, die dran sind), und dann wieder Strom ran an die KSQ...

    Ja, stell' den Code doch mal rein, ist bestimmt interessant.

    Bei Ethernet ist es so, dass ein Datenframe (außer Du benutzt "Jumbo Frames", das muss der Switch aber können) max. ca. 1400irgendwas Bytes Nutzdaten übertragen kann. Ansonsten wird das Paket fragmentiert, das muss dann auch wieder Netzwerkkarte, Switch und Empfänger können...


    Deswegen klar: (Zitat) "Alles als ein Block übertragen mit den 43200 Kanälen scheint aber nicht zu klappen." - so ein Riesenframe geht bestimmt nicht durch... ;) - dafür gibt es eben diese Aufteilung auf mehrere Blocks, damit die Frames klein genug bleiben. Jinx! ist hier sehr komfortabel, mit der automatischen Aufteilung und patchen über ein Device. Prinzipiell sollte das auch möglich sein*, das z.B. bei Artnet auch automatisch so zu machen, also z.B. statt dass Du 10 Artnet-Devices patcht, gibt es nur eins, und die Ausgaberoutine teilt das selbst in versch. Universes auf...

    *damit meine ich, man könnte das wohl so programmieren, hat Sven aber nicht gemacht, ist da bei Artnet halt auch nicht üblich...


    Du kannst dann auch das

    Code
    #define UDP_TX_PACKET_MAX_SIZE 50000

    wieder runter setzen, weil das ist ja Verschwendung, so große Frames werden da nie ankommen...

    Das (Zitat) "Um 1024 channels/block kommen die Daten interessanterweise am schnellsten durch (dauert ca. 3,5ms). Kürzere oder längere packets machen es langsamer."


    kann ich mir auch so erklären: Wenn Jinx! die Daten auf mehr Blöcke aufteilen, und mehr Ethernet-Frames verschicken muss, dauert das natürlich länger, als wenn es nur "ein paar" Frames sind... dass es bei größeren Paketen langsamer wird, liegt dann wohl irgendwie an Netzwerkkarte/Switch, dass die evtl. irgendwie Probleme bekommen, wenn man mit der Framegröße an's Maximum geht...

    (Zitat) "Damit Jinx! 1024 channels sendet, muss ich dort übrigens 1023 einstellen... hat mich ne Zeit gekostet, das zu checken." - 1024 lässt sich nicht durch drei teilen... ;) - ich vermute, dass Jinx! nicht RGB eines Pixels über mehre Blöcke verteilen kann... deswegen 1023, das sind glatt durch drei dann 341 Pixel...


    btw., ich habe noch nie ausgerechnet, wie viele Pixel man eigentlich über tpm2.net übertragen kann... ^^ - bei Frames mit 1023 Bytes, also je 341 Pixel, wären das dann (bei max. 255 Blöcken) 86.955 Pixel - also genug für den Teensy :S

    Ich habe gute Erfahrungen mit der hier gemacht: https://www.amazon.de/gp/product/B01JYLZWPI - so 10 Stück als "Türschilder" verbaut, die alle noch laufen. Aktuell aber leider nicht verfügbar. Kannst ja mal googlen, ob es von der Marke auf Ebay oder sonstwo was gibt.

    Ansonsten habe ich auch gute Erfahrungen mit Produkten (hier Pixel-Ketten) von BTF-Lighting gemacht, aber k.A., ob die sowas haben... einfach mal bei Ebay schauen...


    Ansonsten, k.A. wo Du das Ding her hast, aber evtl. halt einfach mal Pech mit nem Montagsprodukt gehabt, und wenn Du da noch eins bestellst, funktioniert es besser...(?)

    Vorab: Bist Du wegen der Größe sicher, oder ist das ein Vertipper...? - ich kann in Jinx! maximal 480 Pixel in einer Dimension anlegen, also 12x1200 geht bei mir nicht...


    Mich hat das interessiert, also ob Sven das richtig implementiert hat mit dem tpm2net - hat er! :)


    Also von dem her ginge es, nur ein Output Device anlegen mit 43.200 Channels, z.B. auf 36 Blocks verteilt á 1.200 Byte, dann passt das gut in einen normalen Ethernet-Frame. Und dann einfach per "fast patch" alle Pixel in einem Rutsch patchen... ich hab' das mal mit 120 x 120 ausprobiert, und im Wireshark nachgeguckt: Jinx! teilt die Daten dann automatisch auf 36 Blöcke auf und zählt den Index hoch...


    Ich kenn' mich mit Teensy nicht aus, programmiert man da in C...? - landet jeder empfangene Ethernet-Frame in einem Buffer...?


    selbst habe ich früher Byte für Byte (bei "normalem" tpm2) empfangen und in Assembler ausgewertet, inzwischen habe ich auch eine tpm2.net-Empfangsroutine für Arduino/ESP8266 - die funktioniert im Prinzip so:


    Ein Frame wurde empfangen und liegt im Buffer - dann parse ich den:


    - ist das erste Byte 0x9C (Startbyte) und das zweite 0xDA (Frametyp: Daten)? - wenn nicht, Frame verwerfen
    - Ansonsten Byte 3 (Hi-Byte) und 4 (Low-Byte) raus ziehen, daraus die Nutzdatenmenge errechnen
    - Dann an der entsprechenden Stelle (Nutzdatenmenge+6) nachschauen, ob da das Blockende-Byte 0x36 steht - wenn nicht, Frame verwerfen
    - Ansonsten ist der Frame gültig, Byte 7-n weiter verarbeiten.

    Das ist jetzt die simple Version, ohne Aufteilung auf mehrere Blöcke. Die brauchst Du aber, also musst Du noch nachschauen:
    - Byte 4: Paket (Block)nummer
    - Byte 5: Gesamtzahl der Pakete (Blöcke)


    und dann halt die Daten an die entsprechende Stelle (ausrechnen anhand Blocknummer und Framegröße) in deinem Arbeitspuffer schreiben. Das wäre die Luxus/ordentlich-Variante, die für (fast, die Blöcke müssen alle gleich groß sein) beliebige Werte funktioniert...

    Was Du bei Dir vereinfachen kannst, wenn der Teensy fest ne Matrix mit 14.400 Pixeln bedienen soll, und die Aufteilung immer 36 Blöcke á 1.200 Byte ist:

    - 9C, DA, Framegröße und Blockende-Byte gar nicht auswerten. Es schickt ja nur Jinx! auf den Teensy (davon gehe ich mal aus...), also muss das ein tpm2.net-Frame sein, und der wird schon passen (wenn nicht, flackert's/ruckelt's so und so...)
    - nur die Block-Nummer auswerten, und die Bytes dann an die entsprechende Stelle in den Zwischenpuffer kopieren. Also Block 1 ist Byte 1 bis 1.200, Block 2 ist 1.201 bis 2.400, usw.
    - Wenn Du Block 36 empfangen hast, ist das Bild komplett, ausgeben an die Matrix.


    weiß nicht, ob Du das so auf Teensy umsetzen kannst...? - ich kann den Arduino-Code auch rein stellen bei Bedarf, aber der ist wie gesagt ohne Auswertung der Block-Nummer... das sollte aber noch easy rein zu machen sein...

    mehr Infos auch auf http://www.tpm2.de

    Für mich hört sich das an, als ob da (mindestens) eine LED kaputt ist. Ab der geht dann natürlich kein Signal weiter... Also insb., dass der Teil mal kurz aufgeleuchtet hat und dann nix mehr ging, klingt stark danach.


    Kann auch ne schlechte Lötstelle sein, insb. wenn es so ne flexible Platine ist. Schau doch mal bei der esten LED, die NICHT leuchtet, ob da ein Pin ab ist oder sowas. Oder bei der davor, dass da das Signal schon nicht weiter geht.

    Auch mal probieren: Auf die erste LED, die nicht leuchtet, sanft drauf drücken. Hatte ich auch schon mal, dass da drin ein Bonddraht ab war, durch leichtes Drücken auf die LED hat sie wieder kontaktiert...

    Im Prinzip kannst Du dann diese defekte (und weitere, falls noch weiter hinten welche sind) LED dann austauschen... oder gleich ne komplette neue Matrix kaufen, soo viel kosten die ja nicht...

    Interessante Zusatzinfo: Kann dann gut sein, dass Du wirklich ne Matrix mit WS2812B bekommen hast. Habe mich neulich mit nem Freund drüber unterhalten, der war früher auch hier im Forum aktiv, und hat seit Jahren nen eigenen LED-Shop. Er hat mir erzählt, dass die WS2812B wohl generell schlechte Qualität haben, und bei den meisten Matritzen/Stripes, die als "WS2812B" verkauft werden (weil die Bezeichnung bekannter ist), in Wirklichkeit SK6812 drauf sind, weil es da weniger Ausfälle gibt.

    Was ich irgendwie auch bestätigen kann: Ich habe vor ziemlich genau 1 Jahr bei JLCPCB in China so Matrix-Platinen mit 39x15 Pixeln (WS2812B) für ein Projekt für nen Kunden anfertigen lassen. Da war bei der Hälfte der Platinen das selbe Problem, ein Teil blieb dunkel, wegen (von vornherein) defekter LEDs... als "Entschädigung" wurde mir dann ein Gutschein über 10 Euro bei der nächsten Bestellung angeboten... 8o

    Der Arduino ändert aber auch nix dran, dass Du diese KSQ nicht mit 100 Hz ein- und ausschalten kannst, sondern die dann einfach (bei duty cycle 50%) auf 50% Leistung geht, weil das für sie ein PWM-Signal ist... :P

    DA ist der "Flaschenhals", die KSQ kann das nicht, scheißegal, ob vorne ein China-Dimmer, Arduino oder Parallelport vom PC dran hängt!

    Das nur als Hinweis, k.A., ob Stroboskopeffekte überhaupt gebraucht werden...

    Welche "Stolpersteine" erwartest Du bei den Motoren...? - Also, inwiefern interessiert das den Motor, ob das PWM-Signal nun von einem gekauften Dimmer oder einem Arduino erzeugt wird...? :/

    Und noch mal: Der pauschale "Tipp" "nimm doch nen Arduino" hilft dem karlio genau gar nix - das ist so, als ob jemand in nem Autobastlerforum fragt "brauche Hilfe beim wechseln der Bremsscheiben" und jemand schreibt dann "nimm' nen Schraubenschlüssel" 8o - Er braucht eine Anleitung. Arduino programmieren kann er sogar ein bisschen, es geht um das elektronische drumherum, und das wird noch komplexer, wenn er einen Arduino nimmt statt fertige Komponenten...

    karlio das sind halt die Nebeneffekte beim Fragen in so nem Forum... sorry! - Ich hab' Dir ja eigentlich nur empfohlen, hier wegen ner geeigneten KSQ zu fragen, weil ich da halt auf die schnelle keine finde... aber die hast Du ja nun schon selbst... Alles andere war ja eigentlich schon klar, also ich bastle dann lieber in der PLK mit Dir, als hier weiter Zeug zu tippen und nutzlose Kommentare dazu zu lesen...

    Ach, auch noch wichtig, weil da Motore im Spiel sind: Was soll das Ganze denn werden...? - Irgendwas mit Stroboskopeffekten....? - Weil dann kann ich Dir schon mal sagen, dass Du mit diesem Setup nur eine relativ niedrige maximale An/Aus-Frequenz erreichst... ist schon mal limitiert durch DMX, und die KSQ wird auch keine 100 Hz oder mehr mitmachen, weil sowas "interpretiert" sie ja schon als PWM-Signal...

    Ich vermute fast, dass die auch bei einem PWM Signal unter 10V reagiert

    Ja, dann bekommst Du aber nicht den vollen Strom - weil bei 100% duty cycle (= "voll an") liegen dann z.B. die 6 V da an, d.h, die KSQ gibt dann 60% des Stroms aus, weil Du sie dann ja praktisch mit 0-10V ansteuerst...

    Und mit diesem Dimmer wird es so (Also auch wenn Du den mit 10 V betreiben würdest) gar nicht funktionieren - weil der schaltet ja die Ausgänge nach GND durch, bzw. sind sie offen, und bei offen am Eingang der KSQ liefert sie 100%... deswegen kann es auch sein, dass ein einfacher Trimmer nicht reicht, weil auch wenn bei dem z.B. nur 100 Ohm zwischen den Eingängen anliegen, kann das sein, dass das für die KSQ "offen" bedeutet.


    Ich bin jetzt nicht so der Analog-Schaltungs-Experte, aber mit sowas sollte es funktionieren:



    Erklärung: Über der Zenerdiode liegen 10 V am DIM-Eingang an. Wenn T2 durchschaltet, sind es 0 V, und der Eingang ist auch nicht offen. T1 ist dafür da, das Signal zu invertieren, weil sonst die KSQ an wäre, wenn der Dimmer "aus" sagt. Prinzipiell sollte es sogar ohne die Zenerdiode + Vorwiderstand gehen, weil der Transistor schaltet ja zwischen offen (= 100%) und "0 V" (= 0%) um...


    Bzw. in dem Fall sogar ganz ohne weitere Bauteile: Einfach GND vom Dimmer an Dim- von der KSQ, und den Ausgang an Dim+ - dann schaltet der FET im Dimmer den Eingang zwischen offen und kurzgeschlossen (= 0 V) um... Nachteil: Das Signal ist invertiert, also Du musst dann in Deiner SW 100% einstellen für Licht aus und 0% für Licht an...


    Kannst Du ja mal so ausprobieren, ansonsten kann ich Dir die Schaltung oben zamlöten, und dann kommt das einfach zwischen den Dimmer und die KSQ...


    Das mit dem Spannungsteiler erkläre ich Dir mal mit Zettel und Stift, zu viel zu tippen... ;)


    EDIT: Quatsch (ist schon spät... ), in der Schaltung oben braucht es T1 gar nicht, weil das Signal wird ja schon invertiert: "Licht an" heißt ja, der FET im Dimmer schaltet "DIM" nach GND - dann sperrt T2, also liegen zwischen DIM+ und DIM- an der KSQ 10 V an, also "Licht an"...

    Ma schauen ob das in diesem Thrad noch beantwortet wird...

    Wie Du siehst, ja, es hätte aber trotzdem nicht geschadet, einen neuen Thread mit passendem Titel aufzumachen, weil Du willst ja nicht ne LED mit Arduino dimmen, sondern nen PWM-Dimmer an ne KSQ adaptieren. ;)

    Wie auch immer: Der Ansatz ist richtig, einfach die 24 V vom Dimmer auf 10 V runter teilen. Das geht einfach mit 2 Widerständen (ausrechnen, siehe "Spannungsteiler"), oder, Du nimmst einen Trimmer, und stellst den dann so ein, dass 10 V raus kommen.

    Da hast Du auch kaum Verlust, weil, Du teilst ja nicht den "großen" Strom, der durch die LED fließt, sondern nur die Steuerspannung, da fließt kaum Strom...

    Superluminal Also zwischen 2 fertige Geräte noch einen Trimmer einzubauen halte ich für deutlich einfacher, als an nen Arduino FETs am Ausgang und nen RS-485-Bustreiber am seriellen Eingang und noch nen DIP-Schalter zum Adresse einstellen hinzubauen und dann auch noch SW anzupassen und aufzuspielen... ;)

    Abgesehen davon hilft ihm die Info "Nimm halt nen Arduino" original überhaupt nix, weil dann hat er ja das selbe Problem, wie kommt er dann von den 5 V vom Arduino bzw. 24 V von seinem Netzteil auf die 10 V für den KSQ-Eingang. Also die Problematik ist exakt die selbe, nur dass er noch mehr Aufwand hat mit dem Arduino ^^

    karlio ich kann Dir das gerne mal zeigen, bzw. wir das zusammen machen. Ich hatte Dir ja empfohlen, Dich hier anzumelden, wegen der Frage nach einer geeigneten KSQ, die man per PWM dimmen kann... Aber die hast Du ja nun wohl schon selbst gefunden...? - Hast Du mal nen Link dazu? - Weil genau DAS wäre ja das interessante Teil... Also was die exakt will am Eingang usw.