Multiplexing problem - White LED ghosting

[hun_yeti]

Hello.

I'm working on a little MCU controlled LED flashlight.
I have a great problem with it: LED ghosting.

It is starting to appear when the switching frequency goes above only a 100hz

I have search Google in this topic, and I have found information that it is maybe because of the stray capacitance of the common anode line, and resistors from the collector  of the transistor  to ground can help with this.

I tried it, even very low value resistors didn't make any difference and I don't have and oscilloscope to check out what is going on exactly.

I even tried to insert a blank frame between each multiplexing but it didn't reduce ghosting, just the overall brightness (as expected).

Maybe the problem is with the code, but i can't find out what it is...
I'm using a TI MSP430g2252 20pin dip.
Here is the code:

Code: [Select]

pic1=0x55;
pic2=0xaa;


if (mpx==10){ //check flag for interrupt (2khz)
mpx=0; //clear flag
if (mpxs==1){ //multiplex segment
P2OUT=BIT0+BIT1;//turn off both segments (pnp bc327)
P1OUT=pic1; //Push character to segment (npn bc337)
P2OUT = BIT1; //Turn on Active segment
mpxs=0;} //Next time start with


else if(!mpxs){ //the other segment
P2OUT=BIT0+BIT1;
P1OUT=pic2;
P2OUT = BIT0;
mpxs=1;}On this picture the multiplexing is running at 1Khz(visible ghosting)


 on this picture it is multiplexing at a 100Hz ( no visible ghosting , but flickering to human eye)


Thanks for the help in advance!

[shebu18]

A clip would be better then pics.

[hun_yeti]

You are right!
here is a little clip:

[ColinB]

Can you post a schematic please?

Am I correct in observing that the LED in the row above (and below?) the illuminated LED is ghosting, but not the ones in the adjacent columns (left/right)?  Based on your orientation in the video, where the transistors are below the LED matrix.

[ColinB]

You might be able to tell something by doing a test where you switch only the 2 "commons" and another test where you switch only the 8 "segments" to see if the ghosting is related to only one of these.

Something like the following (two separate test code snippets):

Code: [Select]

pic1=0x55;
pic2=0xaa;

// Test 1:
// Test switching "commons" only - same data
// driven to segments for each case.

if (mpx==10)            //check flag for interrupt (2khz)
{
    mpx=0;              //clear flag
    if (mpxs==1)        //multiplex segment
    {
        P2OUT=BIT0+BIT1;//turn off both segments (pnp bc327)
        P1OUT=pic1;     //Push character to segment (npn bc337)
        P2OUT = BIT1;   //Turn on Active segment
        mpxs=0;
    }                   //Next time start with
    else if(!mpxs)      //the other segment
    {
        P2OUT=BIT0+BIT1;
        P1OUT=pic1;     // Note USING pic1 ON BOTH COMMONS
        P2OUT = BIT0;
        mpxs=1;
    }
}

// Test 2:
// Test switching "segments" only - same data
// driven to commons for each case.

if (mpx==10)            //check flag for interrupt (2khz)
{
    mpx=0;              //clear flag
    if (mpxs==1)        //multiplex segment
    {
        P1OUT=pic1;     //Push character to segment (npn bc337)
        P2OUT = 0;      //Turn on both commons (BIT1 and BIT0)
        mpxs=0;
    }        //Next time start with


    else if(!mpxs)      //the other segment
    {
        P1OUT=pic2;     //Drive the alternate pattern to segments
        P2OUT = 0;      //Turn on both commons (BIT1 and BIT0)
        mpxs=1;
    }
}


[hun_yeti]

Yes, your observation is correct.
Sorry i should have started out with the wiring.

I only multiplexed it into two parts (and not four) because i wanted the highest possible brightness and i had enough pins (and as far as i understand the more lines are multiplexed the shorter pulse each line gets)

The first and third row share a common anode and the second and fourth lines share an anode.
the first led in the first row and the first led in the second row share a cathode ( with a resistor into the transistor)

I don't have a schematics , i didn't draw it yet, but here is a diagram:

The letters are the anodes and the numbers are the cathodes.
A & B is connected to two PNP transistors And every number is connected to an NPN transistors.

Code: [Select]

7A  6A  5A  4A

7B  6B  5B  4B

3A  2A  1A  0A

3B  2B  1B  0B

I hope it makes it clearer


I don't have to write those test line, because with the buttons on it i can enter pretty much any pattern.
And it always lights up the LED that is on the same cathode witch is multiplexed.

[MikeK]

Make sure everything is shutting off before setting the new port value.  I would use a hardcoded value, like PORT=0 or PORT=255 (depending on your switching transistors).

[hun_yeti]

Make sure everything is shutting off before setting the new port value.  I would use a hardcoded value, like PORT=0 or PORT=255 (depending on your switching transistors).

The software does turns off and it is hardcoded:

Code: [Select]

P2OUT |=BIT0+BIT1;//turn off both segments (pnp bc327- so they have to be high to turn off)
P1OUT=pic1; //Push character to segment (npn bc337)
P2OUT &= ~BIT1; //Turn on Active segment
Only the First and Second bits are toggled because the other Bits on this port are used for buttons

And the thing is that it only appears on faster multiplexing speeds,above 100Hz.

[amyk]

If you haven't read this thread already: https://www.eevblog.com/forum/projects-designs-and-technical-stuff/mysterious-led-problem-could-use-some-help/

[MikeK]

Do the PNPs have pullup resistors to prevent floating?

[ColinB]

If you haven't read this thread already: https://www.eevblog.com/forum/projects-designs-and-technical-stuff/mysterious-led-problem-could-use-some-help/

That really sounds exactly like the problem hun_yeti is having.  It's the capacitance of the LED itself that stores enough charge to light the LED very briefly and dimly, but if driven at a high enough frequency, it is visible.

Try putting a resistor from the PNP collector (A, B connected to LED anodes) to ground.  This will discharge the LED capacitance when the A, B drive is turned off.  Try something like a 4.7 k ohm to start with, but maybe 100k will work fine.

[hun_yeti]

If you haven't read this thread already: https://www.eevblog.com/forum/projects-designs-and-technical-stuff/mysterious-led-problem-could-use-some-help/

That really sounds exactly like the problem hun_yeti is having.  It's the capacitance of the LED itself that stores enough charge to light the LED very briefly and dimly, but if driven at a high enough frequency, it is visible.

Try putting a resistor from the PNP collector (A, B connected to LED anodes) to ground.  This will discharge the LED capacitance when the A, B drive is turned off.  Try something like a 4.7 k ohm to start with, but maybe 100k will work fine.

First i thought this as well, but I don't know anymore...
I tried to connect a resistor to the collector of the PNP transistors, but it did not made any difference, not a 100k nor a 100r.
The program can control the brightness of the LED-s with PWM(well sort off)
But it does not matter how long the pulse is ( how bright the LED i want to be on) the other LED (that should stay off) turns on the same amount

This is the code for multiplexing I'm using in my program ( with the pulse leng control aswell

Code: [Select]

if (mpx==16){ //check flag for interrupt (2khz)
//The loop increments mpx every time
mpx=0; //clear flag

if (mpxs==1){ //multiplex segment
P2OUT |=BIT0+BIT1;//turn off both segments (pnp bc327)
P1OUT=pic2; //Push character to segment (npn bc337)
P2OUT &= ~BIT1; //Turn on Active segment
mpxs=0;} //Next time start with


else if(!mpxs){ //the other segment
P2OUT |= BIT0+BIT1;
P1OUT=pic1;
P2OUT &= ~BIT0;
mpxs=1;}
}

else if (mpx==bright){P2OUT |=BIT0+BIT1;} // shut off all LEDs earlier to reduce the brightness

But maybe this is all because this is all done on the back of a perf board.

After all it is not a deal breaker problem, I just wanted to know what is happening.

[Skibane]

Phosphor persistence?

[David_AVD]

Phosphor persistence?

Any phosphor persistence would be many magnitudes of order shorter than the times observed here.

[andersendr]

When I look at that video, it looks like the light fron the LED that is being lit, is reflecting off the non lit LED's.  To me the tell tale sign was that you had to hold the board at the correct angle to get the problem to show up in the camera.  One thing to try would be to put some paper or tape around the LED and see if the problem still exists.  Another way to verify this would be to hook up a scope or a volt meter to the LED that lights up that should not.  This would tell you if there was trully any voltage across that LED. 

[ColinB]

When I look at that video, it looks like the light fron the LED that is being lit, is reflecting off the non lit LED's.  To me the tell tale sign was that you had to hold the board at the correct angle to get the problem to show up in the camera.  One thing to try would be to put some paper or tape around the LED and see if the problem still exists.  Another way to verify this would be to hook up a scope or a volt meter to the LED that lights up that should not.  This would tell you if there was trully any voltage across that LED.

I considered that it might be reflected illumination from the adjacent LED as well, but it seems to be a greater effect at higher multiplexing frequencies, so I don't think it's the problem.  The reason you need to get the angle exactly right is because the LED lens focuses fairly tightly and if you really want to get a direct shot at the LED die, you need to look directly down on it -- when it's so faintly illuminated, any angle offset may obscure the output.

[hun_yeti]

When I look at that video, it looks like the light fron the LED that is being lit, is reflecting off the non lit LED's.  To me the tell tale sign was that you had to hold the board at the correct angle to get the problem to show up in the camera.  One thing to try would be to put some paper or tape around the LED and see if the problem still exists.  Another way to verify this would be to hook up a scope or a volt meter to the LED that lights up that should not.  This would tell you if there was trully any voltage across that LED.

I considered that it might be reflected illumination from the adjacent LED as well, but it seems to be a greater effect at higher multiplexing frequencies, so I don't think it's the problem.  The reason you need to get the angle exactly right is because the LED lens focuses fairly tightly and if you really want to get a direct shot at the LED die, you need to look directly down on it -- when it's so faintly illuminated, any angle offset may obscure the output.

Reflection was my first guess as well, but i ruled that out.
And yes, i really have to hold the LEDs straight to to camera because these are very focused LEDs, with a viewing angle of about 15-20°.
I wish i had an oscilloscope, that would instantly reveal the problems i think.

[kripton2035]

can you try to place a small capacitor like 100nF in parallel with each row of leds causing that problem ...
just my 2 cents...

[Colin55]

First of all we don't know which way you are scanning.
Turn on one LED in a high-speed scan and let us know if the mirror is before the LED or after the LED.
The fault is definitely due to not turning off the LED fully after illuminating.