500 LED project power supply and sanity check

[spacewarp]

Hi, first time poster here! I'm in the process of researching/designing a larger-than-usual project and would like a sanity check before I pay a lot of money to do something stupid. Basically, I need to control and power 500 addressable RGB LEDs (+ some small extras) from batteries for at least an hour.

I'm currently looking at WS2812B LEDs (accepts a 5V supply and chainable serial communication), which seem to consume ~250mW at full brightness, meaning 500 of 'em would be ~125W. Expected usage is 30-50% of this, but I'm designing for full brightness. To power these the current idea is to have 5 big Li-Ion packs @ 7.4V with 5A max current. Each of these would then power two 5V/3A switching regulators, which would each power a chain of 50 LEDs.

For control I plan to have one of the tiny Arduino boards to handle basic logic and color pattern computation etc, but I see no way this could handle sending the required high-speed control signals to the LEDs (each chain needs 800Kbps). That job is instead outsourced to a small Spartan 6 board (no idea if this is overkill or not) which job is to accept color data from the Arduino at a more reasonable rate and send the high-speed serial data to the ten LED chains. These boards would be powered by their own, smaller, battery.

My main concern is the power supply and overheating (failure is ok, overheating absolutely not). With a common ground for all batteries and regulators, but with separate power supplies I believe it should work and with the nice feature that if a battery runs out then only the part powered by that particular battery is affected. I'm slightly worried though that having the LEDs' serial data connections and the power connections be powered from separate regulators could cause problems.

So, if  anyone sees some opportunity for me to be smarter about this, alternatively shoot myself in the foot, I'd appreciate the feedback.
Thanks

[ajb]

Is this going to be one 'box' that runs all 500 LEDs, or is each string of 50 going to be off on it's own, and connected back to the main controller? 

The big thing to watch out for when you have multiple devices with independent power sources is that you don't have a situation where your signal ground connections wind up carrying substantial amounts of current.  As long as you maintain a solid ground reference connection between physical devices you shouldn't have any problems there.  If you weren't running from batteries you'd likely want to isolate the data interfaces instead of trying to maintain that common ground point, especially if your system will be spread over a large area.

As far as control, using one FPGA to drive ten 800kbps serial streams sounds okay, using one FPGA for *each* serial stream sounds like crazy overkill--not sure which you meant.  Depending on what sort of content you want to drive this whole system with, generating the serial stream may be the easy part compared to generating the data that goes into that serial stream.  You may be better off using a beefier microcontroller to handle primary content, and have it hand off the display data to smaller microcontrollers that buffer and retransmit that data to the LEDs.  If you're trying to do something really intensive like display real-time video, you might want to do all of it in a single FPGA.  It all just really depends on the content you're trying to display and how much data you have to move around and how fast.

[Corporate666]

You asked for feedback.... soooo.... I think your idea is needlessly complex.  I just did a project somewhat similar to this.  My thoughts...

-Arduino is shit, ditch it.  If you have the know-how to use something like the Spartan, I don't see what the Arduino is needed for?  Use a Cypress PSoC4.  This:

http://www.digikey.com/product-detail/en/CY8CKIT-049-42XX/428-3344-ND/4805328

Will easily run 960 LED's purely in hardware with the StripLights free software component and leave all the rest of the chip resources available for whatever you like, and it's $4, and you can get 128k of memory for whatever program/patterns you like.

http://www.element14.com/community/thread/27131/l/psoc-4-pioneer-kit-community-project100-psoc-4-times-square-led-billboard?displayFullThread=true

As for power.... why 3A regulators?   If the LED's are 250mW, that's 50mA @ 5V... so 500 of them means 25A in total.  3A regulators means 9-10 regulators to power the whole lot. 

Use something like this:

http://www.digikey.com/product-detail/en/D12F200A/941-1045-ND/2501317

$22 if you buy one, has an input range of 4.5 - 13.8V, and will supply 5V @ 40amps (200W) - more than enough. 

So your total cost for power and control is under $30.


If you aren't comfortable straying from Atmel, use the OctoWS2812 library

https://www.pjrc.com/teensy/td_libs_OctoWS2811.html#videodisplay

This guy is driving 1000 LED's with full motion video using an Atmel Teensy board.

[tszaboo]

I'm not sure why everyone is sticking to the serial interfaces. If I would want to make a system like this, I would divide the trips into 8 or 16 and use a real parallel port on a MCU to drive it. And I'm not sure why would you go with the Arduino+Spartan configuration, that is like a spaceship with a pogostick hybrid. Just use a proper 32 bit 48+ Mhz microcontorller, so even if you bitbang the interface, it is still fast without #ASM.
But you should wait for Mike to stuble here, he is the pro when it comes to LEDs.

[senso]

The Teensy 3.0 is a Freescale ARM M3 or M4 core running at something north of 60Mhz, not even near an atmega.

[DanielS]

I'm not sure why everyone is sticking to the serial interfaces.

Why make your life more complicated by parallelizing bit-banging when the "smart LEDs" can accept bit rates up to 800kbps which is more than sufficient to drive the 500 LEDs OP wants to use? Since these LEDs use 1/3, 2/3 NRZ coding to signal 0s and 1s, parallelizing across 8-16bits would require a few extra operations at three times the banging rate. It is not too hard to imagine why someone would want to use a small CPLD or FPGA to offload the bit-banging if they need the CPU for other purposes.

[Corporate666]

The Teensy 3.0 is a Freescale ARM M3 or M4 core running at something north of 60Mhz, not even near an atmega.

Humm, I thought the Teensy used one of the Atmel ARM chips - guess not.

Either way, a Teensy or PSoC for a few bucks makes a hell of a lot more sense than Arduino + Spartan... no need to split it up into multiple parts.

[tszaboo]

I'm not sure why everyone is sticking to the serial interfaces.

Why make your life more complicated by parallelizing bit-banging when the "smart LEDs" can accept bit rates up to 800kbps which is more than sufficient to drive the 500 LEDs OP wants to use? Since these LEDs use 1/3, 2/3 NRZ coding to signal 0s and 1s, parallelizing across 8-16bits would require a few extra operations at three times the banging rate. It is not too hard to imagine why someone would want to use a small CPLD or FPGA to offload the bit-banging if they need the CPU for other purposes.

If you bitbang 500*3*8 bit with 25 FPS, you are spending 40% of your time with bitbanging. With a 8 bit interface it is 5%, and you only need to make some small shifting operations, which will probably fit in the waiting periods.

[miguelvp]

The Teensy 3.0 is a Freescale ARM M3 or M4 core running at something north of 60Mhz, not even near an atmega.

Humm, I thought the Teensy used one of the Atmel ARM chips - guess not.

Either way, a Teensy or PSoC for a few bucks makes a hell of a lot more sense than Arduino + Spartan... no need to split it up into multiple parts.

Yeah, a PSoC4 can drive 1024 leds with PWM (green board on the right of the panel)


I based the code to drive that panel from this project that drove a 32x16 panel but that's 512 leds.
http://www.element14.com/community/message/84683/l/psoc-4-pioneer-kit-community-project060

Oh, btw, those are RGB LEDs so it's really driving 3072 and the pioneer demo half of that (1536)

But an FPGA might allow more levels of grey and a higher refresh rate, like this:
Edit: (FPGA project not mine)

[Corporate666]

Yeah, a PSoC4 can drive 1024 leds with PWM (green board on the right of the panel)

I based the code to drive that panel from this project that drove a 32x16 panel but that's 512 leds.

Oh, btw, those are RGB LEDs so it's really driving 3072 and the pioneer demo half of that (1536)

But an FPGA might allow more levels of grey and a higher refresh rate, like this:

Neat project - are you using Mark Hastings' "Striplights" component? 

The WS2812 LED's have a max data rate of 800kbps, and at 24bits per LED and 500 LED's, that would allow 66fps frame rate.

He wouldn't actually need to split the data lines into parallel channels, but he could do that (the Striplights component for the PSoC supports 16 channels, IIRC?).  The trick will be processing the data quickly enough to load it into the LED's.  At 60fps, that's closing in on a megabyte of data per second.  If the need is just patterns and lines and stuff - that's easy enough.  If it's images stored in memory - still doable (but it will eat up a lot of memory of course - luckily PSoC supports DMA!).  If it's decoding full motion video or something... I think that is well into FPGA land for most cases (although the guy who came up with the Teensy project was running video on one of his displays).

[spacewarp]

Wow, I honestly did not expect this much of a response, thank you. I got sick (still am, apologies for any weird grammar, etc) right after the posting the thread and haven't been keeping up so I'll try to answer stuff in order.

Is this going to be one 'box' that runs all 500 LEDs, or is each string of 50 going to be off on it's own, and connected back to the main controller?

Each 50 LED string is going to go of in its own direction, only getting data centrally.

As far as control, using one FPGA to drive ten 800kbps serial streams sounds okay, using one FPGA for *each* serial stream sounds like crazy overkill--not sure which you meant.

The FPGA was intended to drive all ten chains. I like FPGAs but not that much

... Depending on what sort of content you want to drive this whole system with, generating the serial stream may be the easy part compared to generating the data that goes into that serial stream. ...

Very true. The data involved will basically be pretty light patterns, but involving some computation. I'm going to do some small scale testing to see where the bottleneck is in the computations.

You asked for feedback.... soooo.... I think your idea is needlessly complex.  I just did a project somewhat similar to this.  My thoughts...

I have a habit of over-engineering stuff

-Arduino is shit, ditch it.  If you have the know-how to use something like the Spartan, I don't see what the Arduino is needed for?  Use a Cypress PSoC4.

I've never actually used an Arduino but I've understood them to be more beginner-friendly and one of the reasons for using potentially using one is that in the end I may not be the only one having to work with it. That Cypress board looks neat though.

As for power.... why 3A regulators?   If the LED's are 250mW, that's 50mA @ 5V... so 500 of them means 25A in total.  3A regulators means 9-10 regulators to power the whole lot.

One thing that I seem to have omitted from the original post is that this is intended to be worn, and large heatsinks are not an option for several reasons. Therefore the idea was to have 10 smaller regulators to spread out the heat generation.

If you aren't comfortable straying from Atmel, use the OctoWS2812 library

https://www.pjrc.com/teensy/td_libs_OctoWS2811.html#videodisplay

This guy is driving 1000 LED's with full motion video using an Atmel Teensy board.

That looks very interesting I was led to believe that it would be unlikely to handle the communication but that library seems to have a very nice solution to that. In case it wasn't painfully obvious I've never tried to run quite this many LEDs at high speed with weird constraints.

I'm not sure why everyone is sticking to the serial interfaces. If I would want to make a system like this, I would divide the trips into 8 or 16 and use a real parallel port on a MCU to drive it. And I'm not sure why would you go with the Arduino+Spartan configuration, that is like a spaceship with a pogostick hybrid. Just use a proper 32 bit 48+ Mhz microcontorller, so even if you bitbang the interface, it is still fast without #ASM.
But you should wait for Mike to stuble here, he is the pro when it comes to LEDs.

I'm not sure I understand you regarding serial/parallel, but I like your analogy

I'm not sure why everyone is sticking to the serial interfaces.

Why make your life more complicated by parallelizing bit-banging when the "smart LEDs" can accept bit rates up to 800kbps which is more than sufficient to drive the 500 LEDs OP wants to use? Since these LEDs use 1/3, 2/3 NRZ coding to signal 0s and 1s, parallelizing across 8-16bits would require a few extra operations at three times the banging rate. It is not too hard to imagine why someone would want to use a small CPLD or FPGA to offload the bit-banging if they need the CPU for other purposes.

This was pretty much my reasoning, yes.

As stated in reply to Corporate666, I seem to have omitted the fact that this is intended to be worn. It will not be arranged in a nice matrix, but spread out unevenly and part of the computation problem lies in computing and adjusting patterns given an approximate location of each LED.

This is also part of the reason why I've avoided some possibly better suited but larger boards, as even a moderately sized board may cause problems.

[miguelvp]

Neat project - are you using Mark Hastings' "Striplights" component? 

No, I'm using a modified version of project #60, of the 100 projects in 100 days that I linked above, I
did that a while back so I will have to look at the code, but as I recall it uses bit banging but interrupt controlled for the PWM. It's not using the built in PWM.

He wouldn't actually need to split the data lines into parallel channels, but he could do that (the Striplights component for the PSoC supports 16 channels, IIRC?).  The trick will be processing the data quickly enough to load it into the LED's.  At 60fps, that's closing in on a megabyte of data per second.  If the need is just patterns and lines and stuff - that's easy enough.  If it's images stored in memory - still doable (but it will eat up a lot of memory of course - luckily PSoC supports DMA!).  If it's decoding full motion video or something... I think that is well into FPGA land for most cases (although the guy who came up with the Teensy project was running video on one of his displays).

I was using a PSoC 4 and the max hardware PWMs I've been able to use it's 8.
https://www.eevblog.com/forum/microcontrollers/help!-what-mcu-(greater-than-8-bits-of-smarts)-is-easiest-to-graduate-to/msg528985/#msg528985

As for DMA, the PSoC 4 lacks that, you need the PSoC 5 or the PSoC 3, but the later is 8051 based.
PSoC 4 is Cortex M0 and the PSoC 5 is a Cortex M3

Here is the schematic for 8 16 bit PWMs on the PSoC 4:




I guess with the proper latching one could use the PWMs to drive the panel, but have not tried that route. And I have not look at those light strings so not sure if it will apply.

[Corporate666]

No, I'm using a modified version of project #60, of the 100 projects in 100 days that I linked above, I
did that a while back so I will have to look at the code, but as I recall it uses bit banging but interrupt controlled for the PWM. It's not using the built in PWM.

One of the "100 projects in 100 days" was a project written by a Cypress guy called Mark Hastings that performs the WS2811/2812 timing with a custom verilog component.  The component is called "striplights" and is available for download from the project site.  It works with PSoC4 and PSoC5.  It supports up to 16 different strings and I believe the # of LED's per string is limited only by the update bandwidth, but it supports both the 400kbps and 800kbps modes, so for 60fps that would be over 5 LED's per strip, which with 16 channels would be over 500 amps

The component supports functions to draw lines, rectangles, circles, text (with fonts) and individual pixels.  It also does the updating entirely in on-chip hardware, so all the rest of the chip resources are free to use without worrying about timing.

The big hurdle is feeding the data, but it works on PSoC5 (DMA) and, IIRC, PSoC5 comes up to 256k of flash, and of course all the chips can use external resources too

[Corporate666]

One thing that I seem to have omitted from the original post is that this is intended to be worn, and large heatsinks are not an option for several reasons. Therefore the idea was to have 10 smaller regulators to spread out the heat generation.

500 LED's @ 5V/0.06A ea is 150 watts.  If you can get your power supply 95% efficient, that is only 7.5 watts dissipated in the worst case, which would be trivial for a small heat sink to handle without worrying about "hot spots".  And that's worst case - all LED's on 100% in white... realistically average dissipation would probably be a quarter of that.  You could probably get away with just using the PCB as the heatsink in that case.

Based on this being wearable, I'm going to even more strongly recommend the PSoC4 or PSoC5 solution.  They are very beginner-friendly boards, and they have a WS2812 "API" which handles the timing and data stream entirely in on-chip hardware, which means you don't need to worry about interrupts or timing or refreshing - and because the chip does it in hardware, it doesn't even consume interrupts or cause other issues you need to worry about when coding.

PSoC5 is a 32-bit ARM Cortex M3 and you can get the chip up to 256k of flash, and 80Mhz operating speed... so that's quite a lot of processing horsepower available.   Buy their PSoC5 kit for $10 and it will more than handle all your processing side of things:

http://www.cypress.com/?rid=108038

Or get the PSoC4 Bluetooth LE kit

http://www.cypress.com/?rID=102636

The main board comes with a PSoC5LP on it that you can access it's pins/ports, and it has USB and a bluetooth module, for $49... so you could make your project controllable from your smart phone