There's only 1 column that's not working, what can it be ?

Each column is controlled by one pin of one of the two LED driver chips. If one isn't working, there's probably a bad solder connection at the relevant chip pin, or possibly a pin of the chip that isn't seated in its socket.

I'll try that with the chip. Thanks again!

What exactly is this L2 position ? I got a little curious about it. Is there any disadvantage by engaging it on my board ?

Adding a wire at L2 disables L1, which is an inductor-- an element that is sometimes slowing down the turn-on sequence a little too much. We're replacing the current L1 with a smaller-valued inductor that should resolve this issue.

The board is working now ! It wouldn't without your help, Windell ! Thank you very very much ! I'd like to post a video of it running an app, and that made me wonder why this forum doesnt have a showoff section (not a good idea, or i just didn't find it ?)

There is room in the memory to add a few extra animations in the default program. We have not thus far because (1) no one had really asked for it and (2) if we were to add others, they would probably look a bit strange for folks with things like "JOE'S BAR" spelled out on their Peggies. So... if we were to a few additional animations, what would you suggest?

The 16-level is pretty nice ! Maybe a 16-level with that 'Peggy RGB code' functionality to turn the "pixels" individually by pressing a button. It's a nice way not to have only static and also test button functionality 'out of the box'. (RGBW)

Thanks !

I'm confused by the L1/L2 situation. My board does not already have a component in L1. I soldered in an inductor at L2 per the instructions. But I am getting blinking of the rows of LEDs. Shorting L2 stops the blinking, but also reduces the overall intensity of the LEDs.
George

I'm confused by the L1/L2 situation. My board does not already have a component in L1. I soldered in an inductor at L2 per the instructions. But I am getting blinking of the rows of LEDs. Shorting L2 stops the blinking, but also reduces the overall intensity of the LEDs.

Hi George,
We had a problem with the first round of Peggy 2.2 boards in that some configurations were unstable at startup with the inductor that we supplied. The inductor is not a critical component, but is there (ironically) to prevent a different potential instability.

The inductor on that first batch was in location L1, and it can be shorted out by adding a wire across L2. We switched to a different inductor, now in location L2-- which seemed to solve the problem in our tests --and this can be shorted out by adding a wire across L1 (or across L2 as you've discovered). This is the first report we've had of a problem with the new configuration-- Can you tell us what your configuration is in terms of LEDs & power supply?

In any case, shorting across the inductor is a permanent and fine solution to the problem. As for the brightness, what you're now seeing is normal operation at low power. Peggy is a multiplexed display, which means that only one row is driven at a given moment. Normally, all 25 rows are scanned at high frequency to light all of the LEDs. But, when scanning is not active-- at startup or during programming-- all of the power meant to go to all 25 rows is dumped into one row, so it's *very* bright. (Close to the maximum safe level for the LEDs.) If you've just finished building it, you might want to follow through with the step about adjusting the trimpots to a higher brightness level.

So, just to be clear, I should remove L2 and insert a jumper instead? Should I also put a jumper across L1, or is the single jumper at L2 enough?
George

So, just to be clear, I should remove L2 and insert a jumper instead? Should I also put a jumper across L1, or is the single jumper at L2 enough?

Any of these is fine. The "cleanest" solution that we'd recommend is to leave L2 in place and add a new jumper at L1, but that's just because we try not to request any desoldering in our kits.

If you've got the jumper at L2 now, it's certainly fine to leave it like that.

P.S. In case it helps, the problem for me depends on the number of rows populated with LEDs. I tested the board by adding a couple of LEDs, and they worked; then a few more in a different row, and they were fine too; but the third and fourth rows started to cause the problem (namely, not all rows of LEDs were lit and those that were, blinked). I might of course done something wrong during assembly.

> I might of course done something wrong during assembly.

No, probably not. What you are describing is also what we heard for the some of the boards with the other (L1) inductor. This is discouraging-- I thought that we'd seen the last of it once we tested the new inductors. (We may simply omit the inductor alltogether from the kit in the near future. No good seems to come of it being there.)

OK, I jumped L1 and all the LEDs light up. But now I have another problem: they do not light up with equal brightness. They are either quite bright or very dim (but still perceptibly illuminated). Their luminosity depends on the number of LEDs in their column and row. (I have not fully populated the board.) Turning the trimpots has no effect on them.

Does this set of symptoms match any particular problem, such as a bad transistor?

George

Hi George,
What you are seeing may be normal or not, depending on *a whole lot* of different things. But... it sounds like your system voltage is too low; that would explain all of the symptoms. What type(s) of LEDs are you using, and how are you powering the board?

If you've got a bad transistor, it will generally just not light up a given row. Parts like these rarely have partial-failure modes-- if it goes, it goes.

I'm using the LEDs and power supply from the awesomeness kit.

I have populated the following LED locations and see the following illumination pattern:

D0 - dim
D24 - bright
D1200-D1209 - bright
D1010-D1014 - bright
D1110-D1114 to D1410-D1414 (4x5 block) - dim
D2400 - bright

When I check the pulse waveforms at the LED anodes with an oscilloscope, I see a pattern that is hard to describe. The pulse period is 0.45 ms. Unpopulated rows show what looks like an exponential decay from 5V to ~1V. In populated locations, I see a pattern that is not obviously correlated with luminosity:

D0, D24 - voltage is 5V for ~0.02 ms, followed by a sharp drop and exponential tail

D1010-D1014 - voltage is 5V for ~0.04 ms, then ~3V for ~0.06 ms, then drops to a constant ~1.6V

D1110-D1114 - voltage is 5V for ~0.02 ms, then ~3V for ~0.06 ms, then drops to a constant ~1.6V

D1210-D1214 - voltage is 5V for ~0.02 ms, then drops to a constant ~1.6V

D1310-D1314 - voltage is 5V for ~0.05 ms, then drops to a constant ~1.6V

D1410-D1414 - voltage is 5V for ~0.02 ms, then drops to a constant ~1.6V

D2400 - voltage is 5V for ~0.02 ms, followed by a sharp drop and exponential tail

I'm hoping you can make sense of this, because I sure can't.

George

What's happening is that the LED driver chips are reacting to the absence of LEDs in a given location in the row above. The voltage in each chip ramps up when it finds an empty spot in the row, and it's still high when it gets to the next row. There are a number of ways to avoid seeing this effect. While these aren't the only methods, I'd suggest one of the following:

1) Populate the entire LED array,
2) Leave each row lit longer (the scan rate by default is much higher than necessary), or
3) Reprogram the display to only turn on the LEDs that are actually populated.

Regardless of which of these ways you are going to go, I strongly suggest that you finish building the display before you start to work on tweaking it, programming it, or worrying about its uniformity.

I finished populating the array and it's working! Thanks so much for your help.

By the way, there's a typo in PeggyWriter_Hello.pde. It should be "&frame" since the function definition calls for pointer arguments.

George