Driving a LED matrix

[gary]

I have now spent many hours trying and failing to get a good PWM picture on my televisor.
I found some code to increase the speed of the PWM output significantly, and confirmed with my oscilloscope that frequency was correct. Still have very poor, hard to even recognise, picture with long lines and poor shading. Then I started to wonder - if I seem to be putting a reasonably fast PWM out from the Arduino, what could be going wrong. Is it possible that the LEDs I am using simply can't switch that fast? I looked up LEDs - they generally switch VERY fast. Then the next candidate was my darlington TIP122 -- looked it up... uh oh... "Designed for general−purpose amplifier and low−speed switching applications." Oh dear, could it be that this transistor has been the cause of my frustrations? I haven't yet found what "low speed" means, but it sure looks like a possible culprit.

Hmmm, very possibly, however, the TIP122 is often used as an output transistor for good quality amplifiers so clearly it's response is fine for audio so I doubt it was a culprit in your early experiments, now we are up at 375kHz that's another matter of course, the specs, show a significant roll off in gain and at 375kHz it's down to about 100 (there could well be other factors) which is enough gain for our purposes, having said that, the transistor's switching times are inversely proportional to collector current, but even that seems ok unless I am completely misreading the specs (as is likely).

Darlington transistors are regarded as having fast switching times in general.

You say the PWM looks fine on your scope, I assume that's coming out of the pin or DAC? What does it look like on the top of the emitter resistor?

It would be good if you could hack a bit of code together to do a frequency sweep.

Is there any chance you could send me your current code?, I have a nano and due here that I can run it on and have a look.

EDIT: I should say, of course, even if the TIP122 is too slow it's easily replaced with a high speed version, or even a MOSFET.
EDIT2: Or, we can simply filter the circuit before the TIP122

[Andrew Davie]

OK, I have been doing some experiments to find out what is up.
Firstly, I confirmed the WAV file playing interrupt is playing at ~41kHz. I did this by incrementing a counter and every 44100th increment I printed to the debug screen "tick" - and the ticks came at pretty much every second. I confirmed by counting 60 ticks while timing a minute. So, that part seems fine - I definitely have a ~44.1kHz interrupt doing the WAV file reading and playing (and writing the LED brightness).

Next I found a motor PWM value that spun my disc at pretty much 750rpm. I confirmed with the oscilloscope looking at the IR pulse - 80ms spacing between pulses = 12.5 Hz. That speed was used for all tests, so it's at the frame rate I would see in a "real" picture. So, WAV @ 44.1kHz and disc rotating ~750rpm.

Next, I put in a toggle allow me to switch the LED PWM duty between just two states - 0 or 127. So, black or 50% duty cycle grey. This should allow me to see if there are any PWM artefacts creating a 127-bright pixel with 50% on, 50% off. And I ditched the WAV file data and just toggle the brightness at 44.1kHz (i.e, in the interrupt).

Then I put in a counter which only toggled "every n-th interrupt". This allows me to "toggle every 5 interrupts" or "every 8" etc. So what I expect to see is starting with "every 1 interrupt" I should see pixels going black/white at the maximum pixel resolution of my display. That is, changing at 44.1kHz. Then I went through a dozen or so values of N, allowing me to see how the system behaved with longer and longer white and black states.

And here's the result for a subset of those... The number underneath indicates the N value (so, 2 means I toggled when my when my counter which is incremented every interrupt is > 2 ... that is, every third interrupt, toggle). So the bands (black, or white) are N+1 interrupts long.

bands2.jpg (212.55 KiB) Viewed 3480 times

Interpretation for N

• N=0 I am toggling every pixel, and it's happening so fast I can't see pixels. The resolution, in other words, is fine - many pixels per scanline.
• N=1 Now I can get a reasonable idea of how many actual pixels there are on a scanline. I can see bands, each being 2 pixels deep on any scanline. That is, 2 pixels of grey, two pixels of black. Given the view area is a bit bigger than an actual frame, I estimate the number of interrupts per scanline at about 100 (roughly 25 white bands + 25 black bands) so that gives an estimate of 100 (interrupts) * 32 (scanlines) * 12.5 (frames per second ) = 40000 - which is great - that's close to the expected number 44100 and good enough for an eyeball estimate. Note, too, that we are not seeing any PWM "dottiness" caused by the PWM being too slow. The grey is actually... grey. The bands have sharp divisions and even in size. All looking good.
• N=2 This is a 3-interrupt deep line, so should be 1.5* as big as the N=1 value. Could be OK hard to tell.

So, this experiment tells me a few things for sure.

• I have a ~44.1kHz interrupt inside which I can set pixel intensity
• There are no PWM artefacts visible, so the PWM is plenty fast enough
• I do indeed see different shades of grey because if I used 255 for the duty cycle I see white, and at 127 I see grey
• The brightness banding is sharp and defined - I don't see any effect of "slowness" of the LED or transistor
• Everything looks A-OK actually.

Conclusion: I can only conclude that I must have a bug in my WAV file reading code. Although I did earlier see clear images at lower speeds, this doesn't seem to upscale to higher speeds. Something must be going wrong with the actual DATA that I am feeding the LEDs, because the experiments above seem to indicate that the display is working as expected. So, time to start hunting on the WAV side of things.

[Andrew Davie]

Darlington transistors are regarded as having fast switching times in general.

Given my experiment just completed, I don't suspect the transistor or the PWM anymore. Must be my WAV file reader.

It would be good if you could hack a bit of code together to do a frequency sweep.

Thanks for the suggestion. I effectively did that with my experiment just posted. I modified the speed at which I was changing pixels, rather than the PWM frequency itself. It's allowed me to, in my view, confirm correct operation of the display circuitry. I must be feeding it garbage data.

Is there any chance you could send me your current code?, I have a nano and due here that I can run it on and have a look.

Happy to share code - I'm an "open source" believer. However, you wont be able to run it as the processor is different, and I'm using hacky timer stuff that's close to the metal. You'd need an ATmega32U4 to run this at the moment.

Thanks for your comments/help!