LED Multiplexer glimmt

[A. S. (rava)]

Hi,

ich habe letzte Woche schonmal einen solchen thread eröffnet. Da sich 
dieser verlaufen hat, möchte hier nochmal alle Informationen 
zusammenstellen.

Ich arbeite gerade an einer Platine, auf der ein Encoder und 31 kleine 
RGB-LEDs sitzen. Das Ganze wird mit einem PIC (auf der darunterliegenden 
Platine) im SPI-Slave Modus gesteuert.

Der PIC hat 2 SPI-Schnittstellen. Mit der zweiten Schnittstelle wird ein 
16Bit-Konstantstrom-schieberegister beschrieben. Mit den Transistoren 
Q1-Q8 (alle an einem µC-Port) gibt sich eine schöne Multiplexermatrix.

Das Ganze habe ich mit einer 4Bit-PWM versehen. Hier mal ein Ausschnitt 
des Quellcodes. Die Methode MuxNextStep schaltet etwa alle 12.5kHz um 
einen Schritt weiter. Alle 8 Aufrufe hat sie alle 8 Transistoren einmal 
durchgeschalten und damit das gezeichnet, was ich "Pattern" nenne. Also 
ein komplettes Bild (muxAdress reset @1.56kHz). 16 dieser Bilder 
wechseln sich ab (pwmIndex reset @ 100Hz). Dann geht's wieder von vorne 
los.

#define ColOff 0b11111111
const u8    ColPatterns[] =
{
    0b11111110,
    0b11111101,
    0b11111011,
    0b11110111,
    0b11101111,
    0b11011111,
    0b10111111,
    0b01111111
};

void MuxNextStep(void)
{
    //  pattern pointer auf aktuelle Position biegen (basierend auf PWM)
    tMuxPatternToShow = &(currentPattern->patternData[pwmIndex]);
    // erstes byte über MSSP2 schicken
    SSP2BUF = tMuxPatternToShow->rowData[muxAdress];
    // Zeit zum senden des Bytes warten
    while(!SSP2STATbits.BF2)
    { ;/* wait for transmission to be completed*/ }

    // zweites Byte über MSSP2 schicken
    SSP2BUF = tMuxPatternToShow->rowData[muxAdress]>>8;
    // währenddessen intensity correction: error handling und neu vorbereiten
    T5CONbits.TMR5ON = 0;                       // timer abschalten
    // error handling
    if(LATA != ColOff)
    {
        LATA = ColOff;
        flagIntensityCorrectionHiccup = 1;      // error flag setzen
    }
    TMR5 = I_CC[pwmIndex];
    // ggf verbleibende Zeit zum senden des Bytes warten
    while(!SSP2STATbits.BF2)
    { ;/* wait for transmission to be completed*/ }

    // Reihe durchschalten und anzeigen, dann sofort timer5 starten
    RowLCK();
    LATA = ColPatterns[muxAdress];
    T5CONbits.TMR5ON = 1;

    // nächsten Schritt vorbereiten:
    //  muxAdress zählen
    muxAdress++;
    //  bei jedem Überlauf auf 8 zählt pwmIndex weiter
    pwmIndex += (muxAdress==0b00001000);
    //  muxAdress läuft von 0 bis 7
    muxAdress &= 0b00000111;
    //  pwmIndex läuft von 0 bis 15
    pwmIndex &= 0b00001111;
}

der timer 5 realisiert eine logarithmische Intensitätskorrektur, indem 
er vorzeitig LATA=ColOff setzt. Die genauen Intervalle kommen aus dem 
16x16Bit-Array I_CC. Um sicherzustellen, dass das timing passt gibt es 
das, was ich "error handling" nenne: das Ding erkennt, dass sich das 
sytem verschluckt hat und schaltet ab (flagIntensityCorrectionHiccup).

Ich arbeite bei 64MHz und mit dem xc8 free compiler auf einem 
PIC18F46K22. Dass die SPI2 mit 32MHz etwas außerhalb den Spezifikationen 
läuft (LED Treiber kann max. 25MHz) scheint kein Problem zu sein. Auch 
wenn ich alles mit Vorteilern auf 1/64 der Frequenz einstelle, verhält 
sich das Ding identisch.



Ich hänge nämlich gerade daran, dass selbst abgeschaltene LEDs glimmen. 
Am besten sieht man das daran, wenn ich nur eine LED anschalte (im Bild 
LED15 blau auf pwm-Stärke 1/16): die ganze Zeile leuchtet leicht.

Im anderen Thread hatten wir ein paar Ideen. Einiges spricht dafür (pro) 
anderes dagegen (contra)

1. Der Leckstrom durch die Transistoren bringt die LEDs einer Spalte 
zum leuchten.
Pro: werden die Spalten mit 10k auf GND gezogen, verschwindet das 
Glimmen.
Contra: die 10k helfen nicht bei jedem Treiberausgang. Bei demjenigen 
Transistor für die Spalte rechts neben der leuchtenden LED, verringert 
der Widerstand das Glimmen, es verschwindet aber nicht ganz!!!!
Contra: messe ich einen nagelneuen Transistor, liegt der Leckstrom 
außerhalb des Messbereiches meines Multimeters (<100nA).
Pro: widerstandsunabhängiger Effekt für 1k und 100R, keine Wirkung bei 
10M.

2. die Transistoren schalten zu langsam für die PWM-Frequenz
Contra: auch bei sehr langsamen Takt besteht das Problem.
Contra: Intensitätskorrektur schaltet Transistoren ohnehin extrem früh 
aus.

3. der µC kann die Gates der Transistoren nicht ganz hochziehen 
(abschalten)
Contra: Messe ich den statischen Fall (anderer Quelltext) mit dem 
Multimeter liegen am Gate saubere 5V.
Contra: an source liegen genauso saubere 5V an. Selbst im regulären 
Betrieb.




was meint ihr?

[User (Gast)]

Deine Mux toggelt schön der Reihe nach Q1,2,3, ... durch? Ändere mal die 
Reihenfolge (z.B. 1,3,5,7,2,4,6,8) und prüfe nochmal, welche Spalten 
sich nicht per Widerstand beruhigen lassen. Das kann parasitäre Effekte 
ausschließen.

Zu durchdenken: Kann dieses Problem auftreten, wenn die LEDs nicht 
ordentlich in Gegenrichtung sperren, bzw. eine recht hohe Kapazität 
haben?
Hat ein Pull-Up-Widerstand auf der SCT2210-Seite einen Einfluss?

Sind alle Farben betroffen oder nur die Blauen?

[A. S. (rava)]

User schrieb:
> Ändere mal die Reihenfolge

wenn ich statt 1,2,3,4,5,6,7,8 die Reihenfolge 1,2,3,4,5,8,7,6 wähle, 
also so, dass nach dem leuchtenden Q7 der Transistor Q6 durchgeschalten 
wird

const u8    ColPatterns[] =
{
    0b11111110,
    0b11111101,
    0b11111011,
    0b11110111,
    0b11101111,
    0b01111111,
    0b10111111,
    0b11011111
};

dann lässt sich Q6 nicht mehr, wie du es nennst "beruhigen". Die 
Q8-Spalte jetzt hingegen schon.


User schrieb:
> Kann dieses Problem auftreten, wenn die LEDs nicht
> ordentlich in Gegenrichtung sperren (...)?
du meinst so wie im Bild? Und das andersfarbige Leuchten von LED15 geht 
im Blau von LED15 unter?
Ich kann bei 5V Gegenspannung allerdings keinen Stromfluss in 
Sperrichtung messen. also <100nA. Das genügt nicht, um die LEDs so hell 
leuchten zu lassen (eben auch getestet).

Ich glaube, in der Richtung denken wir falsch. Die Sache mit dem 
"Beruhigungseffekt" ist schon extrem auffällig.

User schrieb:
> Hat ein Pull-Up-Widerstand auf der SCT2210-Seite einen Einfluss?
weder pullup noch pulldown an den gates bewirken etwas.

User schrieb:
> Sind alle Farben betroffen oder nur die Blauen?

alle Farben. R ist prinzipiell dunkler, daher ist auch das Glimmen 
dunkler. Aber vorhanden.

[Falk B. (falk)]

Versuch es mal mit statischer Ansteuerung. Also den Konstantstromtreiber 
auf 10mA begrenzen (REXT) und langsam die matrix im Sekundentakt 
durchklappern. Wenn es dann immer noch geisterhaft leuchtet ist es ein 
statisches Problem mit Leck- oder Sperrströmen. Wenn nicht, ein 
dynamisches mit parasitären Kapazitäten oder ungünstigen Schaltzeiten.

[A. S. (rava)]

"statisch" ansehen ist so eine Sache. Wenn ich die LED lange aktiviert 
lasse, ist das Glimmen der Nachbarn nicht mehr sichtbar. Das kann 
entweder daran liegen, dass es weg ist. Oder aber die aktive LED ist so 
hell, dass das Glimmen zwar noch vorhanden ist, aber mit dem Auge nicht 
erkennbar ist.

Mir bleibt also bei niedrigen Frequenzen nichts anderes übrig, als die 
LEDs nur kurz aufblitzen zu lassen (TIMER5).


Wenn ich dann den Takt wie von Falk vorgeschlagen weit genug 
herunterschraube sehe ich zwei Effekte:

(1) Wenn LED15blau aktiv ist (Q7 low), glimmen LED9blau-LED16blau leicht 
mit. Ich kann (wie oben geschrieben) nicht klar sagen, ob das 
Schaltimpulse sind oder dies während der gesamten Leuchtzeit von LED15 
auftruitt.
Dieses Glimmen kann man allerdings mit Pulldowns wie oben beschrieben 
bekämpfen.

(2) Schaltet das Ding nach Q7 den nächsten Transistor Q8 durch, blitzt 
LED16blau (und nur diese eine) in Spalte 8 nochmals kurz auf. Diesen 
Effekt kann man nicht mit einem Pulldown an Spalte 8 beheben.
Das ist der Grund, warum bei hohen Frequenzen der Pulldown an Q8 nur 
bedingt hilft: Das Glimmen (1) verschwindet, (2) bleibt aber vorhanden.



Noch eine Beobachtung:
wähle ich

const u8    ColPatterns[] =
{
    0b11101111,
    0b11011111,
    0b10111111,
    0b01111111,
    0b11101111,
    0b11011111,
    0b10111111,
    0b01111111
};

, dann werden also die Spalten 1-4 gar nicht mehr angesteuert. OBOWOHL 
das Blitzen definitiv wärend (1) stattfindet, glimmen mit dem neuen 
Array nur noch die Spalten 5-8 (also LED13-LED16). Dieser Effekt tritt 
aber nur bei hohen MuxFrequenzen auf. Bei langsamen Frequenzen blitzen 
weiterhin alle 8 LEDs auf.

[Michael (Gast)]

Hast du mal versuchsweise OE/ vom SCT2210 während des Umschaltens auf H 
gelegt?

[Falk B. (falk)]

Also ich glaube, es ist noch ein Timingproblem. In deiner MUX-Funktione 
vermisse ich ein unbedingtes

LATA = ColOff;

ganz am Anfang. Probiers einfach mal.

Denn du macht ja folgendes

Neues Muster aus dem Array laden
1. Byte an Treiber senden
2. Byte an Treiber senden
Prüfen ob schon alle Spalten ausgeschaltet sind ?? Warum?
Zeilentreiber mit neuen Daten laden (RCK)
Neues Spaltenmuster anlegen

Gerade bei dem seht hohen SPI.Takt von 32 MHz bleibt praktisch kaum Zeit 
zwischen dem Ausschalten der altewn Spalte und dem Einschalten des neuen 
Zeilenmusters und der neuen Zeile. Und wenn dein PIC etwas schwächlich 
ist, brauchen die MOSFETs wirklich mehrere Mikrosekunden zum Abschalten. 
Da ist die Routine längst fertig.

[A. S. (rava)]

LATA wird in der Regel von Timer5 auf ColOff gesetzt 
(Intensitätskorrektur).


Ich hab's trotzdem versucht, alles sehr weit auseinanderzuziehen 
(LATA=ColOff am Anfang, Durchschalten erst am Ende). Das brachte leider 
nichts.
Auch die Pause vor RowLCK(); zu vergrößern, hat nichts gebracht.




[S] Oszilloskop




@ Michael

Auf das Enable habe ich leider per Software keinen Zugriff, da ich einen 
Fehler im Schaltplan hatte. Es ist jetzt via 1k ständig auf low gezogen.

[Falk B. (falk)]

Hmmm.

Halten wir mal fest. Mit 10K an den Drains von Q1-Q7 kannst du für 7 
LED-Spalten das Glimmen entfernen. Also sollte man das tun.

Spalte 8 mit Q8 scheint anders.

1.) Vielleicht ist DIESE EINE LED kaputt bzw. geschädigt?
2.) Tritt der Effekt auch bei den anderen 3 Zeilen von LEDs auf?
3.) Tritt der Effekt auch bei anderen Farben auf?

Möglicherweise ist die Blaue LED besonders empfindlich. Möglicherweise 
ist es auch eine kapazitive Kopplung im Layout.

[Falk B. (falk)]

ggf. Mal Q8 oder LED16 gegen ein neues Exemplar tauschen.

[Arsenico (Gast)]

hohen SPI.Takt von 32 MHz bleibt praktisch kaum Zeit
zwischen dem Ausschalten der altewn Spalte und dem Einschalten des neuen

32 MHz ?

[Falk B. (falk)]

"Ich arbeite bei 64MHz und mit dem xc8 free compiler auf einem
PIC18F46K22. Dass die SPI2 mit 32MHz etwas außerhalb den Spezifikationen
läuft (LED Treiber kann max. 25MHz) scheint kein Problem zu sein."

[Arsenico (Gast)]

Led scheint trotzdem ?

[A. S. (rava)]

Falk Brunner schrieb:
> Mit 10K an den Drains von Q1-Q7 kannst du für 7
> LED-Spalten das Glimmen entfernen. Also sollte man das tun.

Ich stimme dir zu. Ich habe aber bereits ein paar Platinen machen lassen 
und würde für diese Version auch gerne eine akzeptable Lösung finden. 
Vielleicht kann man mit der Software noch etwas passables hintricksen. 
Dazu müsste ich aber erstmal verstehen, woran das Problem liegt.


Falk Brunner schrieb:
> Spalte 8 mit Q8 scheint anders.

ah sorry, ich dachte das wär deutlich:
Q8 verhält sich anders, wenn eine LED in Spalte 7 angeschaltet ist. Es 
ist IMMER die Spalte nach der aktiven LED, die sich anders verhält.
Wenn ich LED3 aktiviere, besteht das Problem an Q4...

Einen Hardwaredefekt können wir daher ausschließen, denke ich. Außerdem 
besteht das beschriebene Problem bei 2 Modulen (80mA und ca. 15mA).

A. S. schrieb:
> Dass die SPI2 mit 32MHz etwas außerhalb den Spezifikationen
> läuft (LED Treiber kann max. 25MHz) scheint kein Problem zu sein

shit, das hatte ich falsch in Erinnerung. Korrektur: Der PIC erzeugt den 
SPI-Takt aus fOsc/4. Mit den 16MHz bin ich also sicher innerhalb der 
Spezifikationen. Falschenhals wird da schon eher das Platinenlayout.

Das Problem hat ja auch bei langsameren fOsc-Werten bestanden.

Falk Brunner schrieb:
> Möglicherweise ist die Blaue LED besonders empfindlich. Möglicherweise
> ist es auch eine kapazitive Kopplung im Layout.

Tritt bei allen Farben auf.
Wie würde so eine kapazitive Kopplung aussehen? Die Leitungen zu den 
Gates beeinflussen sich gegenseitig? Oder passiert so etwas eher im 
bestromten Teil (also den Spalten selbst)?
Achtung: auf meinem Layout liegen die Transistoren nicht nebeneinander. 
Da sehr wenig Platz war, liegen links vom Encoder Q1, Q3, Q5, Q7 und 
rechts unterhalb Q2, Q4, Q6, Q8.

[Falk B. (falk)]

@ A. S. (rava)

>und würde für diese Version auch gerne eine akzeptable Lösung finden.
>Vielleicht kann man mit der Software noch etwas passables hintricksen.
>Dazu müsste ich aber erstmal verstehen, woran das Problem liegt.

Ich vermute, dass die LED, welche mit 10K "geheilt" werden können, kurz 
gepulst werden. Und zwar lädt sich das Netz am Drain der MOSFETS durch 
den Leckstrom auf, sin halt nur ein paar pF. Wenn dann der Zeilentreiber 
wieder einschaltet, enflädt sich diese Kapazität durch die LED. Dieser 
kurze Puls lässt die LEDs glimmen.

>ah sorry, ich dachte das wär deutlich:
>Q8 verhält sich anders, wenn eine LED in Spalte 7 angeschaltet ist. Es
>ist IMMER die Spalte nach der aktiven LED, die sich anders verhält.
>Wenn ich LED3 aktiviere, besteht das Problem an Q4...

AHHHH, DAS ist schon mal ne Aussage! Aber genau DAS klingt nach 
Timingproblem. Vielleicht ist im Rest deiner Software noch ein Bug?
Denn wenn der Widerstand am Drain keine Wirkung zeigt, heißt das, dass 
dort was niederohmig gegenhällt. Ich würde nochmal GENAU die 
Spaltensteuerung prüfen. Gerade mit deiner über mehrere Stellen 
verteilten Ansteuerung wäre ich vorsichtig! Ein Oszi würe hier sehr 
schnell Gewissheit verschaffen.

>Einen Hardwaredefekt können wir daher ausschließen, denke ich. Außerdem
>besteht das beschriebene Problem bei 2 Modulen (80mA und ca. 15mA).

Die anderen laufen ohne das Problem? Also ein Exemplarfeler?

>Tritt bei allen Farben auf.

OK. Aber warum nur bei dieser Gruppe? Die anderen Zeilen sind doch auch 
verdrahtet?

>Wie würde so eine kapazitive Kopplung aussehen? Die Leitungen zu den
>Gates beeinflussen sich gegenseitig?

So in der Art. Es müssen nicht die Gates sein, kann auch direkt in die 
Drainsignale reinspucken.

>Oder passiert so etwas eher im
>bestromten Teil (also den Spalten selbst)?

Kann man so einfach nicht sagen.

>Achtung: auf meinem Layout liegen die Transistoren nicht nebeneinander.
>Da sehr wenig Platz war, liegen links vom Encoder Q1, Q3, Q5, Q7 und
>rechts unterhalb Q2, Q4, Q6, Q8.

[Tobias S. (picollo)]

grab und wühl ... und wieder grab ...

nun hamma schon bald den 12.01.2015
Funktioniert das Modul nun schon ?
Wenn nicht, dann geb' ich bei Bedarf
auch mal ein bischen Senf dazu ... ;)

[A. S. (rava)]

ich habe mich mit einem Workaround begnügt:

Da die Farbmischung ohnehin nicht so toll war, habe ich mir Diffusoren 
lasern lassen, aus milchigen 1.5mm Kunststoffplatten.

Damit ist das Glimmen nun nicht mehr zu sehen.



Die Software habe ich ebenfalls leicht optimiert, was die Timings 
angeht, aber es war definitiv ein Hardwareproblem gewesen.

[Tobias S. (picollo)]

also brauchen wir nichtmehr genauer darauf eingehn

[A. S. (rava)]

???

ich hab eine Lösung, die für mich okay ist...


Wenn du dich über das Problem unterhalten möchtest, stehe ich zur 
Verfügung ;)

[Tobias S. (picollo)]

also, wenn du mich schon sooo fragst ;)

Angefangen damit, daß es nahezu ein sträflicher Leichtsinn ist, das 
nackte Gate eines MOSFETs mit einem Knoten bzw. Stecker an die lange 
Leine bzw. Leitung zu hängen. Da müssen die armen Tölen ja durchdrehen.

(Entschuldige bitte meinen inneren Witzbold ;-)

Zudem sollte man das Gate doch eher schonend behandeln, erstens mit 
einem Widerstand, zur zusätzlichen Strombegrenzung und zweitens besser 
noch mit einem Spannungsteiler, weil die Sättigung des FETs wird doch 
schon bei 0.6V erreicht.
Denn ein bischen Temperatur, eine kleine Spannungsspitze, und schon 
verabschiedet sich die hauchdünne Oxidschicht, die das Gate von Drain 
und Source trennt mit einem beherzten "Good bye and thanks for the 
Fish", bevor deine LEDs auch nur annähernd die Halbwertzeit erreicht 
haben.

(OK, der Witzbold kommt wieder in die Kiste)

Sollten die Ports des Controllers als Open Collector konfigurierbar sein 
kannst wohl sogar den BC weglassen und den Spannungsteiler direkt am 
Port gegen Masse schalten.
Wenn der Port stattdessen doch nur mit Sättigungsspannung gegen Plus 
schaltet, dann reagiert der FET auf den kleinen Spannungsunterschied Ugs 
wie ein Spannungsabhängiger Widerstand, weil genau das ist ein FET eben.
Und das bischen Strömli reich schon, damit die LEDs leicht glimmen.

Zusätzlich zum 4k7 Drain Widerstand, der das Ableiten weiterer 
Kapazitäten unterstützt, solltest du auf jeden Fall noch einen 4k7 
zwischen jedes Gate und Source stecken, um sicherzustellen, daß das Gate 
auch wirklich an Us hängt. (In deinem Fall diesen am besten gleich 
direkt ankleben ;)
Wer weiß, vielleicht reichen diese beiden Widerstände in deinem Fall ja 
schon für einen einwandfreien Betrieb.

Diese Endstufe hier schaltet übrigen bis zu 30 parallele LEDs mit 
jeweils 40mA einwandfrei. Weshalb in diesem Beispiel auch ein 1µ direkt 
mit am Source hängt, um sicherzustellen, daß der Einschaltstrom auch zur 
Verfügung steht und der FET genau das tut, was er soll.

Was ich da schon gelesen habe, von wegen den Highsider, welcher doch 
eine etwas langsamere Schaltflanke zu Tage bringt, abzuschalten bevor 
das LED Treiber IC mit etwas Verzögerung neu beschrieben wird, war auch 
schon eine sehr gute Idee.

Dann probier dich mal durch und viel Spaß

PS: Wenn du einen Widerstand zwischen Gate und Source hängst, um den FET 
korrekt in den Sperrzustand zu bringen, solltest du diesen vielleicht 
doch auch mit dem zweiten Widerstand in die Signalleitung zum quasi 
Spannungsteiler erweitern, weil der Rgs läd das Gate, das nunmal auch 
eine Kapazität darstellt gegen Plus auf und diese Ladung ziehst du dann 
mit dem µC Port mit Schmackes gegen Masse ... klingt nicht Glücklich ;)

[A. S. (rava)]

okay danke für den Text.

Ich habe leider nicht den Platz, um deinen Gesamtvorschlag so zu 
übernehmen. Außer du hast einen fertigen IC für mich, wo das alles drin 
ist (Bipolar & Widerstände & Mosfet) ;)

Ein Spannungsteiler zwischen µC port und PMOS gate wäre eventuell drin. 
Ob der wirklich nicht schadet, werde ich vor der nächsten Version 
testen.

Tobias S. schrieb:
> Wenn der Port stattdessen doch nur mit Sättigungsspannung gegen Plus
> schaltet, dann reagiert der FET auf den kleinen Spannungsunterschied Ugs
> wie ein Spannungsabhängiger Widerstand, weil genau das ist ein FET eben.

erklärt das auch, warum das Glimmen weggeht, wenn man wie oben 
beschrieben die Drains mit Widerständen "heilt"?

Anyways... ich werde bei Gelegenheit mal den Lötkolben schwingen und 
weitere Versuche anstellen

[Tobias S. (picollo)]

mehr oder weniger stimmt das g
es mindert eher nur zusätzliche Fremdeinflüsse
reicht aber eben offenbar nicht bei allen LEDs

Du hast doch Platinen professionell fertigen lassen oder ?
Warum setzt du nicht gleich den Controller, oder eben die komplette 
gezeigte Endstufe auf die Rückseite, weil grundsätzlich gilt:

Bitte möglichst kein Kupfer zwischen Vorstufenausgang und dem Gate des 
MOSFETs ;)

(wenn doch, dann kostet das den Entwicklern meistens ziemlich Nerven, 
gell g)