LED-Matrix Modul - Ghosts bekaempfen

[Christian K. (Gast)]

Hallo,

ich habe einen uC (PSoC 5LP) so programmiert, das er ein LED Matrix 
Modul (32x64) ansteuert. Das macht der PSoC vollständig mit seiner 
programmierbaren Hardware und ist daher recht schnell.

Jetzt gibt es Ghosts, wie man auf dem Foto sehen kann. Das Foto ist im 
Dunkeln gemacht, damit man das besser sieht. Bei Tageslicht fallen die 
Ghosts kaum auf.

Meine Therorie wie diese Ghosts entstehen ist, das es Übersprechen gibt, 
wenn die Matrix Adresse gewechselt wird. Für eine kurze Zeit stehen die 
alten Daten noch bei der neuen Addresse an oder umgekehrt. Bzw. wenn die 
Addresse wechselt sind kurzzeitig mehrere Addressen gültig - deswegen 
auch mehrfaches Übersprechen.

Wärend des Zeilenwechselns werden die LED's ja mit dem OE Signal 
ausgeschaltet (blanking). Das OE Signal schaltet dafür die 
Zeilenschalter (P-MOS) aller Zeilen aus. Wärend das OE Signal aktiv ist, 
wird die Zeilenaddresse gewechselt und neue Daten in das Ausgangslatch 
des Schieberegisters kopiert (Latch-Signal). Theoretisch dürfte es also 
praktisch kein Übersprechen geben. Bei langsamer Clock passiert das auch 
nicht, aber ab > 1MHz dann doch. Ich wollte das Panel eigentlich mit 
10MHz clock betreiben.

Das zweite Bild zeigt das OE Signal (hellblau) und das Address LSB 
(dunkelblau). (Gelb ist das Pixel-Signal für G1)

Ich habe jetzt schon ziemlich viel mit verschieben der Timings zwischen 
OE, Latch und Address-Wechsel probiert, aber ich bekomme das Ghosting 
bei schnelleren Clocks nicht weg.

Irgend jemand hier mit Erfahrungen? Stimmt meine Theorie oder gibt es 
eine andere Ursache?

Freue mich über jede Hilfe...

[Peter D. (peda)]

Christian K. schrieb:
> Bzw. wenn die
> Addresse wechselt sind kurzzeitig mehrere Addressen gültig - deswegen
> auch mehrfaches Übersprechen.

Da sollte man besser ein Schieberegister nehmen, dann gibt es keine 
Spikes.
FETs können teilweise recht hohe Kapazitäten haben, die umgeladen werden 
müssen. Besser sind da normale BJTs in Kollektorschaltung, die schalten 
sauschnell.

[Martin S. (led_martin)]

Hallo,

Werden die Ausgänge das Ansteuer-ICs für die Zeilen-P-MOS vielleicht nur 
hochohmig wenn das OE Signal weggeht? Die Gates müssen richtig entladen 
werden. Sind diese Zeilen-P-MOS in dem Matrix-Modul verbaut, oder kommst 
Du da dran? Wenn ja, mach da mal Pulldowns an die Drain-Anschlüsse, 
können meist recht hochohmig sein (Erst 10k .. 47k probieren, wenns 
besser wird, aber nicht weggeht, bis 1k runtergehen). Da ich auch schon 
öfter soetwas gehabt habe, baue ich meine Zeilen-Ansteuerungen immer 
Push-Pull. Sonst hängen die Zeilen-Leitungen so in der Nähe der 
LED-Flußspannung rum, und Einkopplungen erledigen den Rest. Aktuelle 
LEDs glimmen schon bei wenigen uA sichtbar! Etwas seltsam ist, daß das 
Ghosting, an manchen Stellen, in beide Richtungen auftritt. Grün scheint 
besonders anfällig zu sein.

Mit freundlichen Grüßen - Martin

[Falk B. (falk)]

@Christian K. (Gast)

>Meine Therorie wie diese Ghosts entstehen ist, das es Übersprechen gibt,
>wenn die Matrix Adresse gewechselt wird.

Meistens.

> Für eine kurze Zeit stehen die
>alten Daten noch bei der neuen Addresse an oder umgekehrt. Bzw. wenn die
>Addresse wechselt sind kurzzeitig mehrere Addressen gültig

Das sollte schon mal nicht passieren.

>Ich habe jetzt schon ziemlich viel mit verschieben der Timings zwischen
>OE, Latch und Address-Wechsel probiert, aber ich bekomme das Ghosting
>bei schnelleren Clocks nicht weg.

Man muss die Verzögerung an der richtigen Stelle machen. Die Hardware 
muss aber auch halbwegs passen.

>Freue mich über jede Hilfe...

Dann zeig uns deinen Schaltplan.

[Georg (Gast)]

Christian K. schrieb:
> Jetzt gibt es Ghosts

Beim Multiplexen muss man die Zeilendaten auf Null (Aus) setzen, DANN 
die neue Spalte adressieren, DANN neue Zeilendaten ausgeben. Dann heisst 
ein paar µs Verzögerung.

Hilft das nicht muss man halt die Ghostbusters rufen.

Georg

[Falk B. (falk)]

@Georg (Gast)

>Beim Multiplexen muss man die Zeilendaten auf Null (Aus) setzen, DANN
>die neue Spalte adressieren, DANN neue Zeilendaten ausgeben.

Nicht zwangsweise.

>Dann heisst ein paar µs Verzögerung.

Das ist der Workaround, wenn deine Schaltstufen nichts taugen.

>Hilft das nicht muss man halt die Ghostbusters rufen.

Ein paar Grundlagen der E-Technik jenseits des ohmschen Gesetzes sind 
auch ganz hilfreich.

[Falk B. (falk)]

Beitrag "pnp schaltet nicht richtig ab?"

[Christian K. (Gast)]

Hallo,

danke schon mal für die Tips, ich habe einen Schaltplan für so ein LED 
Matrix modul gefunden, ist zwar nicht die gleiche Größe, verwendet aber 
exakt die gleichen Bauteile. Ich gehe daher davon aus, dass die 
Schaltung ziemlich ähnlich ist, aber statt 8:1 macht mein Modul ein 16:1 
multiplexing und hat die doppelte Anzahl von Schieberegistern.

Wie man sieht werden die P-MOS Switches vom Addressdekoder (74HC138) 
angesteuert, der auch das OE (output enable) Signal verwaltet. (In 
meinem Modul gibt es zwei 74HC138 wegen 16:1 muximg).

Leider wird der bei den LED Drivern ebenfalls vorhandene OE pin nicht 
benutzt.

Der 16-fach LED Konstantstrom Treiber sind die SM16126, die haben ein 
Schieberegister, ein Ausgangsregister und constant current-sinks für die 
LED's.

Der Ablauf der Ansteuerung ist folgendermassen:
1. Takte die RGB1/RGB2 Daten in das Schieberegister der LED Treiber
2. Disable den output (EN)
3. Latch das Schieberegisterdaten in die Ausgangsregister der LED 
Treiber (ST)
4. Wechsel die Addresse
5. Enable den output
goto 1

3. und 4. kann auch gleichzeitig oder vertauscht werden, aber die Ghosts 
bleiben... Zwischen 2. und 3. habe ich auch schon Delays bis 1µs 
eingebaut aber hat nichts sichtbar geändert.

Vmtl. bleibt mir nichts anderes übrig als mal an den PMOS zu messen, das 
würde ich aber gerne vermeiden, weil dazu auf dem Panel gelötet werden 
muss...

[Falk B. (falk)]

@ Christian K. (Gast)

>Wie man sieht werden die P-MOS Switches vom Addressdekoder (74HC138)
>angesteuert, der auch das OE (output enable) Signal verwaltet. (In
>meinem Modul gibt es zwei 74HC138 wegen 16:1 muximg).

Das passt soweit, der 138er kann die P-MOSFETs kräftig genug ansteuern.

>Leider wird der bei den LED Drivern ebenfalls vorhandene OE pin nicht
>benutzt.

???
Welche meinst du? Die SM16126? Dort braucht man das nicht. Nur am 
Spaltendekoder 74HC138, dort braucht man das, um alle Spalten inaktiv zu 
schalten.

>Der 16-fach LED Konstantstrom Treiber sind die SM16126, die haben ein
>Schieberegister, ein Ausgangsregister und constant current-sinks für die
>LED's.

http://www.deppenapostroph.info/

>Der Ablauf der Ansteuerung ist folgendermassen:

Erspar uns die Lyrik, zeig und deinen Originalcode ala Anhang.

>1. Takte die RGB1/RGB2 Daten in das Schieberegister der LED Treiber
>2. Disable den output (EN)

Welchen denn?

>3. und 4. kann auch gleichzeitig oder vertauscht werden, aber die Ghosts
>bleiben... Zwischen 2. und 3. habe ich auch schon Delays bis 1µs
>eingebaut aber hat nichts sichtbar geändert.

dann mach mal 10us rein, nur zum Testen. Wenn das nix bringt, liegt der 
Fehler woanders.

>Vmtl. bleibt mir nichts anderes übrig als mal an den PMOS zu messen, das
>würde ich aber gerne vermeiden, weil dazu auf dem Panel gelötet werden
>muss...

Ich hatte auch schon mal den merkwürdigen Effekt, daß die LEDs eine Art 
Speichereffekt zeigten, wenn das Anodenpotential nicht aktiv auf GND 
gezogen wurde. Abhilfe brachten jeweils 1k Ohm von den Spaltentreibern 
(DRAIN der MOSFETs) nach GND. Vielleicht waren es auch 100 Ohm, weiß 
nicht mehr genau.

[Harry L. (mysth)]

Ich hab auch so ein Display hier rumfliegen, aber ein richtiges 
Datenblatt inkl. Beschreibung der Ansteuerung hab ich noch nicht 
gefunden. (Vermutlich nicht intensiv genug gesucht)
Kannst du mir da weiter helfen?

Gruss

Harry

[Christian K. (Gast)]

Falk B. schrieb:
> ???
> Welche meinst du? Die SM16126? Dort braucht man das nicht. Nur am
> Spaltendekoder 74HC138, dort braucht man das, um alle Spalten inaktiv zu
> schalten.

Ja genau, denn wenn die current sinks zusätzlich aus wären während des 
Umschaltens, wäre die Cross-Talk Gefahr geringer. (ist aber eh nur 
philosophisch da nicht änderbar)

Falk B. schrieb:
> dann mach mal 10us rein, nur zum Testen. Wenn das nix bringt, liegt der
> Fehler woanders.

Ich habe den Clock der Schaltung um den Faktor 10 reduziert, dann ist 
das ghosting weg. Es hat also schon was mit dem Timing zu tun. 
Allerdings sind 10µs nicht akzeptabel weil das stark auf die Helligkeit 
des Panels gehen würde und auch nicht ins timing budget passt.

Ein paar technische Daten:
Frame Wiederholfrequenz fw soll >100 Hz sein
PWM ist 5bit (32 Stufen)
Mux-Rate ist 1:16
Shift-Bits sind 128 (es sollen zwei Panels in Reihe werden)
System Clock ist fc

Das ist die Gleichung für das Timing Budget:

(128+x)*32*16=fc/fw

x ist die Anzahl der Clocks während der output disabled ist. fc kann 
max. 7MHz sein weil der DMA Controller die Daten nicht schneller liefern 
kann. Dann kann man mit

x=fc/(fw*32*16)-128

leicht ausrechnen das x kleiner als 9 sein muss um 100Hz refresh rate zu 
schaffen. D.h. die blanking Zeit muss kleiner als 9 Takte also 1.3µs 
sein...

Diese Schaltgeschwindigkeit ist jetzt auch für die P-MOS nicht wirklich 
ein Problem.

Falk B. schrieb:
> Ich hatte auch schon mal den merkwürdigen Effekt, daß die LEDs eine Art
> Speichereffekt zeigten, wenn das Anodenpotential nicht aktiv auf GND
> gezogen wurde. Abhilfe brachten jeweils 1k Ohm von den Spaltentreibern
> (DRAIN der MOSFETs) nach GND. Vielleicht waren es auch 100 Ohm, weiß
> nicht mehr genau.

Das ist interessant... Dann muss ich wohl doch mal am Panel löten. Die 
grünen LEDs scheinen übrigens besonders empfindlich zu sein

[Christian K. (Gast)]

Harry L. schrieb:
> Ich hab auch so ein Display hier rumfliegen, aber ein richtiges
> Datenblatt inkl. Beschreibung der Ansteuerung hab ich noch nicht
> gefunden. (Vermutlich nicht intensiv genug gesucht)
> Kannst du mir da weiter helfen?

Das beste was ich finden konnte war die Schaltung die ich oben verlinkt 
habe. Ein Datenblatt mit Timings usw. habe ich auch nicht gefunden. Aber 
zumindest für die normalen Timings kann man ja die 
Komponenten-Datenblätter hernehmen.

https://www.mikrocontroller.net/attachment/303029/Schematic_for_16x32_RGB_LED_matrix_panel.pdf

[Harry L. (mysth)]

Danke!
Das sollte in jedem Fall helfen.

Harry

[Christian K (Gast)]

So Ursache ist gefunden. Ehemals eingeschaltete PMOS Transistoren haben 
noch soviel Ladung gespeichert, das die nachfolgenden LED's noch 
nachleuchten.

Abhilfe schaft ein Widerstand von dem Drain des PMOS zu Ground (pull 
down).

Interessanterweise sind für solche pull-downs schon unbestückte 
Lötstellen vorhanden. Ich habe auf drei Zeilen 1.8k und auf den anderen 
180 Ohm bestückt und es ist viel besser. 1.8k ist noch zu viel, 180Ohm 
ist besser.