Outline
My project of the month will complement my new TV. Philips TVs have "Ambilight" - a somewhat over-done but nice feature if used on certain films. Essentially Ambilight follows the picture content with a series of LEDs around the TV's frame. This lights up the wall behind the TV. It's only commercially available for Philips TVs - and they never made decent plasmas. It will be going with my Pioneer Kuro...
Size and quantity of LEDs
Initial calculations: The TV screen area is about 45 inches wide and 24 inches tall (16:9 ratio, 50" panel.) I want to surround the whole frame, top, bottom, left and right, although I only will cover the active picture area as the Kuro has a relatively thin bezel. I will be going with a density of 60 LEDs/m and using WS2812B RGB LEDs (these LEDs are serial-addressed LEDs, which means that each pixel can be independently controlled.)
A quick calculation shows I need to cover 3.5 meters, so I will buy 4 meters of 60xLED/m strip (from Seeedstudio, about $67, or ~£44.)
This will be a total of 210 individual point sources of light.
Power requirements
A rough initial estimate of current consumption from the sparse documentation on these LEDs says 60mA/LED for full white, so the total load at full white x 210 will be 12.6 amps, or 63 watts on 5V rail.
Time to get some LEDs... I bought a small "sample" bunch of 10 WS2812B (eBay #121347733196), and connected them in series using 0.1" headers. I then used some example code for a TM4C123GH6PM launchpad (Tiva launchpad) to give it a quick spin... They work great, although I broke one LED whilst soldering. 9 LEDs at full white initially used 385mA, or about 43mA/LED at 5V supply. However the white had a fairly noticeable blue tint, so I played with running the blue LED at about 75% that of the red and green LEDs. This worked quite well for a neutral white point, and reduced the full white current to 35mA/LED plus made the LEDs run cooler. Even at this low current, the LEDs are very bright - almost too bright to look at for any long period of time - and more than bright enough for an Ambilight effect.
This change in power consumption means I need to supply 5V at 7.35A now, or 36 watts. One of the other things I noticed is that the LEDs would work just fine on about 3.75V with no change in brightness except at full white, where I had to increase the supply to about 4.25V to avoid a yellow tint. I could possibly control the power supply so that we constantly track the LED display status and try to operate at the minimum supply voltage. Not only would this reduce heating in the LEDs, improving their longevity, it would also improve the energy efficiency. Running at 4.25V even continuously chops off another 5 watts.
Full load will be rare (most of the time I imagine sitting somewhere between 5 and 15W of load, which would be 50~150% total intensity on across three colours per LED) but I need it to be able to run continuously just in case.
LED quiescent current is about 800uA at 5V, so 0.84W in dark scenes with all 210 running. The power supply needs to be able to cope with a rapid load shift from 0.84W to ~30W in one single frame (60Hz maximum, it will have less than 1/10th a frame or about 1.6ms to cope with this swing, including any voltage tracking.) That should be an interesting challenge. Since each LED "free-runs" at about 450Hz +/-50Hz, I can rely on running ripple current being relatively low. They will not begin PWM cycles at the same time.
Logic levels
The WS2812B are rated for 3.5V at 5V supply. I found that at 5.2V DC, the strip would receive commands incorrectly (garbage instead of correct colours, or not updating) from a 3.3V MCU. Therefore logic level translation will be necessary, especially if the strip voltage is to rapidly modulate. I will use a logic buffer IC.
Because I can. It's an engineering challenge; yes, I could have built the board with only a USB port, but that would be no fun. Designing a moderately high power DC-DC converter is a challenge, as is putting it all together in an integrated system with a lot of analog processing. Version 2 will use a HDMI port which will enable any HD source (not just a PC) to work with it, this is a proof of concept for a future project, which may be done as a 3rd / 4th year project at my university. That will require a bit more R&D to implement...fair enough :) How do you plan to go around a broadcast flag (DRM thing) on HDMI? as far as I remember you can't capture video from most HDMI sources
That Ambilight effect is pretty cool, too - how many LEDs did you use?
Version 2 will use a HDMI port which will enable any HD source (not just a PC) to work with it, this is a proof of concept for a future project, which may be done as a 3rd / 4th year project at my university. That will require a bit more R&D to implement...
Neat! I didn't know you could do HDMI in on a Papilio! I'm quite surprised you can send HDMI data over a 0.1" header... Personally, I was going to use a device like ADV7619 and work with the raw YUV/RGB/YPbPr data. But if I can shove the HDMI straight into an FPGA, it would be simpler. The ADV7619 even supports HDCP (heh, cheap HDCP stripper?!) but I probably won't need that.
You must be using that 'copper-free', liquid cooled Munster cable, which offsets the losses & crosstalk in the dodgy wiring & termination.Neat! I didn't know you could do HDMI in on a Papilio! I'm quite surprised you can send HDMI data over a 0.1" header... Personally, I was going to use a device like ADV7619 and work with the raw YUV/RGB/YPbPr data.
Nobody is more surprised that it works than me - esp since the termination resistors are on the wing board, not next to the FPGA.
Quick demo video (Avatar)
https://www.youtube.com/watch?v=NqlvkYdZCNo (https://www.youtube.com/watch?v=NqlvkYdZCNo)
There's a VFD on the board, and I have a remote control input :) all of it will be fully configurable.
I looked at boblight and used that for the demo/test. Problem is it can't do large area averages without using too much CPU. So it looks a bit rubbish to be honest. It picks up on single pixels only and this causes problems for fast moving scenes.
xrandr --output VGA1 --same-as LVDS1 --scale 0.667x0.740 --pos 0x0