Hi all,

Since assembling my Peggy 2 last week, I've been obsessed with understanding the "ghosting" phenomenon. On my board, with the stock Peggy 2 libraries, I see substantial ghosting in two ways: (1) rows "spill over" slightly into the following row, and (2) later rows "bleed backwards" into preceding empty rows.

Through a great deal of trial and error, I've concluded that the root cause of the problem is capacitive effects in the collectors of the row transistors, and in the drains of the LED drivers. As such, the problem can't be completely eliminated, although I've been able to reduce it substantially. The row transistors are by far the lesser of the two evils capacitance-wise, whereas leaving any LED driver outputs on at all during a row transition is very bad. The sequence I arrived at to absolutely minimize ghosting is:

1. Load zeroes into LED drivers
2. Turn off old row (safe to do now that LED driver drains are all "topped off" with capacitive charge)
3. Load new row into LED drivers (safe to do now that no row transistor collectors are carrying any capacitive charge)
4. Turn on new row *if* it has a lit LED
5. Delay or calculate, as you prefer, then repeat

The disadvantage here is speed: turning off the LED drivers, then back on, takes twice as long as the stock Peggy2 libraries. (The driver chips have an "output enable" pin, but sadly it's tied to ground on the Peggy2 board. Attaching it to an unused microcontroller output could speed this up quite a bit. The timing also ought to work out right if you drove these enable pins from an unused demux output, because the row transistors have a turn-off delay due to the base resistors, but sadly you'd need an inverter as the logic level is reversed )

Even if the slowdown in this ghostbuster logic is unacceptable for a particular application, ghosting can still be improved in blank rows by only turning on the row if it has a lit LED. The cost of that check is minimal.

Brian

Errata: In step 3 above, I should have said it's not *quite* safe to turn on the LED drivers with the new row data, because there is *one* row transistor with capacitive charge in its collector -- namely, the row that was just turned off. As far as I can tell, this is unavoidable without a major change to the board.

(For example, adding a "fake" 26th column without any LEDs, whose only purpose is to bleed charge off of the row transistor collectors -- this would require adding 25 silicon diodes to the board with associated traces.)

I think that what you are saying is all basically correct-- we've been through this set of steps (and that sequence) several times, helping out people who had were sensitive to ghosting for one reason or another. (For most applications, the ghosting effect is *simply not noticeable* and for others it renders Peggy 2 *unusable.* Go figure. )

Now, if you don't mind a little bit of hacking (and it sounds like you might not) you can also implement hardware blanking of the LED drivers. Take each LED driver IC out of its socket, bend the OE pin (pin 21) out horizontally, and re-insert the chip into the socket. Solder a thin wire connecting the OE pins on the two chips, and then connect that wire to (say) pin 14 (PB0-- the "off button" location) so that you can establish software control of it.

FWIW, there are quite a few things that we might change in a hypothetical Peggy 3-- including the OE pin how the rows are selected, but we've been making an effort to keep new Peggy 2 versions code-compatible with the older ones.

Thanks for the info -- I might try that hardware modification or something like it.

FWIW, I find that my sensitivity to ghosting is very dependent on the ambient light level. My "man cave" is the darkest room in the house, which is why I noticed this phenomenon early on.

Brian