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
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.
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.
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.
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.
Schaltung.png
(61 KB)
