Beiträge von Pesi

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

#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

Ach, guck' mal, gerade erst unter dem anderen Artikel entdeckt: https://www.amazon.de/dp/B088K1JH6X

Kostet bisschen mehr, die Alitove war so bei 24 Euro, aber wie gesagt, mit BTF auch gute Erfahrungen gemacht... natürlich alles ohne Garantie, ich weiß nicht, wie diese Matrix ist, und China-Zeug bestellen ist ja generell immer so'n bisschen wie Lotterie...

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...

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...

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" - 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...

Zitat von karlio

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"...

Zitat von karlio

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.

Eigentlich hast Du die Frage schon selbst beantwortet: „Die reine weiße LED wird gar nicht angesprochen, aber dazu sind beide Softwares der Controller auch nicht ausgelegt.“

Die LEDs erwarten 4 Byte pro LED, der Controller schickt aber nur 3 Byte für jede LED raus. Deswegen verschiebt sich das pro LED um eine „Stelle“…

Eigentlich sollte dadurch dann schon auch regelmäßig ein weißer Chip angesteuert werden… aber evtl. ist ja auch zufällig noch was anderes falsch (falsches Protokoll eingestellt oder sowas…)

kommt auch drauf an, wie lange das Ganze mit den 3 Zellen laufen soll…

schön, dass Du Dich dazu entschieden hast, da selbst auszuprobieren, und dass es gut läuft! ?

den Arduino Simulator kannte ich tatsächlich auch noch nicht. Danke für den Tipp! Ich habe zwar (seitdem ich auf den Geschmack gekommen bin, davor jahrelang nur Assembler… ?) immer diverse Arduinos (und ESP) rumliegen, aber wenn man mal unterwegs ist und grad ne Idee ausprobieren will, ist das sicher hilfreich! ?

Für mich klingt das nach: Du hast 512 Kanäle aktiviert. Das wären dann 170 LEDs á 3 Kanäle (RGB)…

nee, der passt schon - fragst Du, weil keine Antwort kam…?

das ist halt schwierig: Du postest ein Bild von nem Haufen Einzelteilen, und fragst hier, wie Du das zamschrauben musst. Es gibt nicht mal ein Abbild, wie das Ganze fertig aussehen soll.

also wie soll Dir da jetzt jemand Tipps geben..?!

Wenn es wirklich filigran sein soll, kann ich diese LEDs empfehlen: https://www.btf-lighting.com/c…dually-light-10-leds-m-5v

einfach die "Ketten" in einen Rahmen spannen, man sieht dann kaum was außer den LEDs selbst.

Nachteile:
- bei kleinerem Pixelabstand (so wie bei Dir) müsste man die Ketten falten - das ist halt schon Aufwand bei 3.600 Pixel
- leuchtet zu beiden Seiten (kann aber je nach Anwendung auch ein Vorteil sein)

Nur so als Tipp, falls jemand über den Thread stolpert und ähnliches vorhat...

Und aufpassen: Es gibt da auch "Fake-WS2812B", die sich nicht wie "echte" ansteuern lassen, sondern feste Adressen haben! - Siehe dazu hier: WS2812 (SK6812) LED in Reihe Probleme

ja, hat er… ich habe schon paar Posts gelöscht und verschoben, Uralt-Threads geschlossen. Wenn das weiter geht, dann Meldung an Stefan, den Troll zu kicken…

1. bitte keine Trolle füttern!

2. keine Leichen ausgraben - daher Thread geschlossen.

also, ääääh, nee! ?

da der Thread schon uralt ist und nur vollgespammt wird, hiermit geschlossen.

ja, die SW ist gut gemacht, erlaubt auch, solche Threads nach TTT zu verschieben… (und ggfs. zu löschen…)