Hallo, ich verwende das oben genante SPI-LED als Ansteurung für Panele. Ich habe ein Prototype entworfen der über RS485 Transceiver (ein Transceiver für Clock und ein Transceiver für Data) die Daten an LED ansteuern. Beim Inbetriebnahme mit 0,5Mbps; 1Mbs bin ich in der Lage 4*(18*36) =2592 LED anzusteuern. Sobald die Frequenz auf 2Mbps, 3Mbps oder 4Mbps funktioniert die Panele nur Teilweise (Beschreibung in PDF hinzugefügt). Mir is bei der Abmessung aufgefallen, dass das Duty Cycle (hier 50%) des Clock-Signale immer geringer bis auf null geht. Wie kann ich es Lösen? Ich habe das Duty Cycle des Clock auf 70/30% eingestellt. Aber Der Duty Cycle (on Zeit) hat sich immer erhöht bis auf 5V. Ich habe außerdem auf dem Clock an bestimmten Zeile einige Pullup Widerstände eingebaut, zwar hat sich die Flanke verbessert, aber ich immer noch nicht 2592 LEDs mit 4Mbps ansteuern. Ich würde mich auf alternative Lösung freuen. Gibt es spezielles IC für SPI-Clock oder allgemein, die ein Signal bekommt und es umwandelt auf 50% Duty-cycle und spezielles mit Aufbau von SPI Protokoll? Ich danke Ihnen für Ihre Mühe im Voraus. LG Rompel
Angehängte Dateien:
-
Schaltung.png
61 KB
Hallo Rompel, hast du echt 2592 in daisy-chain? Warum hast du keine n Segmente gemacht? Dann wären doch nur 2592 / n LEDs in Reihe? Hast Mal mit dem Oszi am VDD-GND gemessen? Evtl. fehlen nur Kerkos? Gruß Martin
Ich habe ein Daisy Chain. Heute habe ich natürlich versuch der Input clock vom ersten LED an LED an der Stelle 486. Da ging es Problemlos bei 4Mbps. Ich werde morgen bei 4 Panel probieren und schauen. Kerkos gab es an jeweilige LED und sollte nicht das Problem meiner Meinung nach, als die Spannung nich eingebrochen wurde. Wäre 2592/n ein Ansatz und wird dadurch die Datensynchronisierung nicht leiten? Es gibt Delay in Clock Messung an jeweilige LED.
Wilfried M. schrieb: > Hallo, > ich verwende das oben genante SPI-LED als Ansteurung für Panele. Ich finde dazu kein Datenblatt. Ohne das geht es schlecht. > Mir is bei der Abmessung aufgefallen, dass das Duty Cycle (hier 50%) des > Clock-Signale immer geringer bis auf null geht. Wie kann ich es Lösen? Das ist sehr merkwürdig und sollte eigentlich nicht so sein. > Gibt es spezielles IC für SPI-Clock oder allgemein, die ein Signal > bekommt und es umwandelt auf 50% Duty-cycle und spezielles mit Aufbau > von SPI Protokoll? Nö. Dein Problem liegt woanders. Deinem Schaltplan zu folge gibt die LED Takt und Daten wieder aus. Dabei wird aber anscheinend das Tastverhältnis vom Takt vermindert. Das darf nicht sein. Wir brauchen erstmal das Datenblatt zur LED.
Hi, anbei das Datenblatt. Freu mich auf dem Feedback im Voraus
Wilfried M. schrieb: > die ein Signal > bekommt und es umwandelt auf 50% Duty-cycle https://de.wikipedia.org/wiki/Monostabile_Kippstufe
Der Versatz im Signal wird so gering sein, dass er eben nur bei so einer extrem hohen Anzahl LED mit hoher Taktfrequenz ein Problem darstellt. Die LED hat sicherlich eine Latenz um Data/Clk wieder aus zu geben. Diese finde ich im DB aber nicht. Beispiel latenzfehler: Bei nur 20ps Fehler summiert sich dies auf 50ns bei deiner LED Anzahl. Das Beispiel spricht von 32 LED in Reihe, ich vermute da garantieren sie auch die 15 MHz. Gruß Anselm
Anselm schrieb: > Der Versatz im Signal wird so gering sein, dass er eben nur bei so einer > extrem hohen Anzahl LED mit hoher Taktfrequenz ein Problem darstellt. > Die LED hat sicherlich eine Latenz um Data/Clk wieder aus zu geben. > Diese finde ich im DB aber nicht. Das Problem ist nicht die Latenz (Verzögerung), sondern die unsymmetrischen Laufzeiten von LOW->HIGH und HIGH->LOW. Die müßte man mal versuchen zu messen. Sprich, an einer LED Jeweils Ein- und Ausgangstakt auf einem Oszikanal messen und die Verzögerung der beiden Taktflanken messen. >Beispiel latenzfehler: Bei nur 20ps Fehler summiert sich dies auf 50ns >bei deiner LED Anzahl. >Das Beispiel spricht von 32 LED in Reihe, ich vermute da garantieren sie >auch die 15 MHz. Sehe ich auch so. Die Dimensionierung von 4 * (18*36) = 2592 LED in einer Kette ist EXTREM! Und hier ist die Durchschleifung des Taktes sogar eher kontraproduktiv, denn jeder Buffer verzerrt das Tastverhältnis, und wie man sieht, alle in die gleiche Richtung. Lösung. Die vier Stränge parallel ansteuern. Das macht die Sache auch nicht langsamer, denn die Anzahl der Bits bleibt ja gleich. Mittels externem DeMux ala 74HC157 geht das auch mit dem Hardware-SPI.
Kann man die auch irgendwo kaufen, so einzeln, 100 Stück oder so? Frage für einen Freund. :-)
Bob schrieb: > Kann man die auch irgendwo kaufen, so einzeln, 100 Stück oder so? > Frage für einen Freund. :-) Ich sehe bei den Dingern keinen nennenswerten Vorteil gegenüber den WS2812B & Co. Im Gegenteil.
Falk B. schrieb: > Ich sehe bei den Dingern keinen nennenswerten Vorteil gegenüber den > WS2812B & Co. Wie bei den APA102, man kann den Takt in einem sehr weiten Bereich einstellen ohne das die sich daran stören würden. Und die interne PWM mit der die LEDs angesteuert werden dürfte auch höher sein, dazu konnte ich dem Datenblatt nur gerade nichts finden.
Falk B. schrieb: > Bob schrieb: >> Kann man die auch irgendwo kaufen, so einzeln, 100 Stück oder so? >> Frage für einen Freund. :-) > > Ich sehe bei den Dingern keinen nennenswerten Vorteil gegenüber den > WS2812B & Co. Im Gegenteil. Der Einzige Vorteil dabei ist die Helligkeit oder Efficienz, wir kriegen damit mit wenige Strom mehr Licht aus, als mit allen anderen LED mit integrieten Treiber. und Wir dachten außerdem, die mit höheren Datenrate betreiben könnten. Aber laut Brightek ist es nicht der Fall
Bob schrieb: > Kann man die auch irgendwo kaufen, so einzeln, 100 Stück oder so? > Frage für einen Freund. :-) Sie können die über die Firma Beck GmbH & Co. Elektronik Bauelemente KG besorgen Aber so eine kleine Menge kann ich dich nicht garantie. Lohnt sich immer zu probieren.
Falk B. schrieb: > Lösung. > > Die vier Stränge parallel ansteuern. Das macht die Sache auch nicht > langsamer, denn die Anzahl der Bits bleibt ja gleich. Mittels externem > DeMux ala 74HC157 geht das auch mit dem Hardware-SPI. Danke für die Lösung. Das haben wir schon daran gedacht. Die Idee war auch auf jede Panel ein kleines µC zu bauen, das nur ihr Daten ausschneidet und der rest an der nächsten Panel weiterleiten. Aber dafür brauchen wir extra Kabel (3*2) statt nur 1*2. Dies die Integration noch komplizierte und auf die Panele haben wir nicht genug Platz.
Wilfried M. schrieb: > Sie können die über die Firma Beck GmbH & Co. Elektronik Bauelemente KG > besorgen Aber so eine kleine Menge kann ich dich nicht garantie. Lohnt > sich immer zu probieren. Danke. Also privat geht da nichts und Brightek haben die nicht direkt im Portfolio. Aber die sind hier als Lieferant gelistet, vielleicht mache ich mal eine Anfrage.
Falk B. schrieb: > Das Problem ist nicht die Latenz (Verzögerung), sondern die > unsymmetrischen Laufzeiten von LOW->HIGH und HIGH->LOW. Die müßte man > mal versuchen zu messen. Sprich, an einer LED Jeweils Ein- und > Ausgangstakt auf einem Oszikanal messen und die Verzögerung der beiden > Taktflanken messen. Hi, ich habe hierzu was gelesen und habe den Eindruck der könnte daran liegen. https://highfrequencyelectronics.com/Jun04/HFE0604_Hancock3.pdf da habe ich was auch interessantes gelesen aber gibt es eine Möglickeit es zu lösen? Ich habe auch die Flanke von Ein und Ausgang gemessen und die sind nicht symmetrisch und mit Pull konnte ich auch nicht viel schaffen. Eine Idee?
Wilfried M. schrieb: > Hi, > ich habe hierzu was gelesen und habe den Eindruck der könnte daran > liegen. > > https://highfrequencyelectronics.com/Jun04/HFE0604_Hancock3.pdf Was meinst du konkret? > da habe ich was auch interessantes gelesen aber gibt es eine Möglickeit > es zu lösen? > > Ich habe auch die Flanke von Ein und Ausgang gemessen und die sind nicht > symmetrisch und mit Pull konnte ich auch nicht viel schaffen. Was heißt das GENAU? Ein paar Zahlen und Screenshots wären nicht schlecht. Siehe Netiquette.
Wilfried M. schrieb: >> Die vier Stränge parallel ansteuern. Das macht die Sache auch nicht >> langsamer, denn die Anzahl der Bits bleibt ja gleich. Mittels externem >> DeMux ala 74HC157 geht das auch mit dem Hardware-SPI. > > Danke für die Lösung. > Das haben wir schon daran gedacht. Die Idee war auch auf jede Panel ein > kleines µC zu bauen, das nur ihr Daten ausschneidet und der rest an der > nächsten Panel weiterleiten. > Aber dafür brauchen wir extra Kabel (3*2) statt nur 1*2. Dies die > Integration noch komplizierte und auf die Panele haben wir nicht genug > Platz. Wirklich? Wiviel Platz ist denn? Sicher genug für einen RJ45 Buchse. Dazu normales Ethernetkabel mit 2x4 Adern, fertig. 2x2 Adern für Takt + Daten jeweils mit GND verdrillt (hf tauglich), die restlichen 2x2 = 4 für die MUX im Panel. Reicht.
Angehängte Dateien:
-
LED_CD_Refresh.png
2,8 KB
OK, was auch möglich wäre, ist eine aktive Regenerierung von Takt und Daten nach X LEDs. D.h. man braucht eine kleine Schaltung, welche die Daten mit dem Ausgangstakt der letzten LED einliest und mit dem frequenzgleichen, jedoch "frischen", nicht verzerrten Takt wieder ausgibt. Das kriegt man mit einem kleinen CPLD hin, ggf. auch diskret, vielleicht auch mit einem clever programmieren uC. Dann braucht man nur die bisherigen zwei Signale zum Panel. Den "frischen" Takt kann man direkt vom Paneleingang nehmen. Man muss nur die Phasenverschiebung der beiden Takte berücksichtigen, dafür braucht man ein Mikro-FIFO mit vielleicht 2-4 Bit. Vielleicht reicht auch eine Trickschaltung mit einem Schieberegister und ein paar FlipFlops. Siehe Anhang.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.