Dot matrix "blurring"

I have found in multiple instances that, when running 8 LEDs by manipulating a port (PORTD = B10101010) or using an 8-bit shift register (shiftOut), the 0's don't quite turn the LEDs off. First, I observed this when using a shift reg to run 7 LEDs in a POV display. Then in my Solid State Lighting project where I ran 7 HIGH POWER LEDs with MOSFETs and the port manipulation technique. Now I'm seeing it happen with an 8x8 matrix running from 2x74HCT164 shift reg's. Any advice?

The High Power POV project:

The current 8x8 LED matrix: Drawing a square one pixel at a time. If i remove a delay in my program, the image looks nothing like a sqaure.

No advice without code & schematic...

You may have the internal pullup resistors enabled. The documentation for digitalWrite specifically warns:

The pullup resistor is enough to light an LED dimly, so if LEDs appear to work, but very dimly, this is a likely cause. The remedy is to set the pin to an output with the pinMode() function.

The other possibility (which I see with my LoL (lots of LEDs) shield) is that if you are using pin 13, then the connected LED and resistor stop it being a proper ground zero reference. So I found that some LEDs (and not others) would not turn off totally. This is if you are using Charlieplexing, or something similar.

is that if you are using pin 13, then the connected LED and resistor stop it being a proper ground zero reference.

This is simply not true, pin 13 has a 1K resistor and LED to ground. This doesn't prevent the output from going to zero. It will however stop it from floating properly in a Charlieplexing application.

The most likely cause of this is poor software that doesn't turn off the LEDs before changing the pattern. But without code we can't tell.

Are you driving the matrix display directly from the shift registers without a driver? If so, you are going to get a bit of blurring and dimness and lack of contrast, since these chips aren't designed to drive this kind of load. (They are designed to output a logic level rather than drive a load, and 'dim' and 'off' are both perfectly within parameters as a logic level 0)

With the MOSFETS, the cause is probably to do with the driving circuit and the wiring of the circuit so we need both a schematic and a good photo to help. Messy wiring can cause crosstalk which could lead to a dimly lit LED.

I say with the shift registers, there is a 99% chance that you are either not using or your shift registers do not support "latching", which means that the dim light is actually the '1's flying into the shift register. But again, I really have no idea without code/schematics.

Grumpy_Mike:
This is simply not true, pin 13 has a 1K resistor and LED to ground. This doesn't prevent the output from going to zero. It will however stop it from floating properly in a Charlieplexing application.

Good point. But if I change my sentence to "the connected LED and resistor stop it floating properly" then my point stands that, depending on the application, this might account for it. It did with the Charlieplexing. However it might have nothing to do with it.

I grant you that the OP said he was using PORTD, and the docs say that "PORTD maps to Arduino digital pins 0 to 7". Therefore talking about pin 13 is a red herring, sorry.

"The most likely cause of this is poor software that doesn't turn off the LEDs before changing the pattern. But without code we can't tell."
"I say with the shift registers, there is a 99% chance that you are either not using or your shift registers do not support "latching", which means that the dim light is actually the '1's flying into the shift register. "

That is the problem.

This shift register is not double latched. So, say you were sending in 0x80 - 10000000
The outputs will all see that 1 as it makes it way to bit 7, and then bit 7 will look brighter if the there is some pause before the next shft in.
You should probably switch to another kind of shift register, one with input registers and an output latch, or add a seperate latch chip after the register you have now.
This is a nice chip, with 25mA current capability, but it is not the chip for this job.

The POV display used PORTD directly. If I wanted to turn on each of the 7 LEDs I would simply write: PORTD = B11111110;
The schematic on that project was as follows:


...where the gate on the n-channel mosfet was connected directly to the corresponding pin of PORTD..

I don't have a schematic for the matrix circuit, but I am simply using shiftOut() on two shift reg's which have there outputs tied to the corresponding row/column pin of this display (Green 8x8 LED Matrix Display Technical Data).

I don't believe that the issue is with my code because when I use a substantial delay in my drawing function, there is not problem. The faster the program runs, the more the image blurs (eventually to the point where the entire display is solid green). Sounds electrical, but I have been wrong.

"I am simply using shiftOut() on two shift reg's which have there outputs tied to the corresponding row/column pin of this display"

Which shift reg's are you using? 74HCT164?
"when I use a substantial delay in my drawing function, there is not problem. The faster the program runs, the more the image blurs"

That certainly sounds like what I described in post #8. Change your shift register to one that uses an output patch.

@CrossRoads

Thank you sir! That makes perfect sense. It does beg the question, though; how would this particular shift register be useful? Wouldn't almost any logic device connect to it see those ones moving by and flip some flops and so forth? Also, does the internal circuitry of the atmel chip shift data into the PORT data registers this way? (wondering if this is why my POV display had slightly ON LEDs that were supposed to be OFF). I'll check to see what we have in the lab for shift registers and change to code to handle latching. Again, thank you.

Shift register outputs are not always read immediately; the data could be set up, then clocked into something else, or used to control other logic gates whose output is used elsewhere eventually.
The Atmel chip can write to each port's pin one by one, or I believe the 8-bit internal bus can be used to write to all 8 at once.
Without seeing the details of your other design, the MOSFET used, the voltage on the LEDs, the sensitivity of the LEDs, etc. it is hard to say why they didn't go completely off. But your past that one now, right?