Go Down

Topic: RGB LED array (shiftbrite) at video rates (Read 1 time) previous topic - next topic

mcpantsface

Hi all,
So I'm starting a fun LED project where I'd like to run an LED array from Processing at video rates using an Arduino.

What I've realized is there are some data rate limitations I'm up against, mainly the serial interface between Processing and Arduino.

I found this post which says the serial data rate is limited to ~86us/byte when running at 115200 baud.
http://stackoverflow.com/questions/4158184/rapid-serial-port-writing-to-arduino-from-processing

Here's the example I'd like to run by you guys:
I'm using the Shiftbrite LEDs and want full 10bit control which means I need 2bytes/color.
I have 81 lights so that means: 2bytes/color X 3 colors X 81 lights = 486bytes.
So to write all the LEDs it will take 86us/byte X 486 bytes = 41ms
This means my frame rate is limited to 1/41ms = 24.4fps

Is this correct? Am I forgetting anything?

So if I want to get to 30fps (or 60fps) on the LED array would the easiest choice be to run multiple Arduinos, for example run two parallel serial interfaces from Processing to two Arduinos with each Arduino controlling half the lights?

Thanks in advance!

scswift

You're forgetting that you need not send two bytes per LED if you want 10 bit control. 

If you pack your data, you can get your overhead down to:
10bits * 3 colors * 81 leds / 8bits = 303.75 bytes
304 bytes * 86us = 26144 us
1000ms / 26ms = 38fps



coyote

Every shiftbright gets 32 bits. (two control bits)
35.88fps

scswift

You don't need to transmit those control bits from the PC to the Arduino, because one will always be set to 0 if you're setting the brightness of the leds, and the other isn't used.

Page 7:
http://www.allegromicro.com/en/Products/Part_Numbers/6281/6281.pdf

macegr

That's true, but packing the data to 30 bits will probably drastically increase the overhead when trying to processing the incoming 8-bit bytes.

It's also possible to pack the color data to three bytes, using 0-254 as your full scale color data and 255 as a start packet flag. The loss of two bits per color can be made up by implementing a gamma curve, which may be desirable regardless of the data transmission method.

It may also be possible to set higher baud rates than 115200, all hardware involved should support it. However, I have not experimented much down that path.
Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store

scswift

That's true, but packing the data to 30 bits will probably drastically increase the overhead when trying to processing the incoming 8-bit bytes.


Shifting a few bits around is hardly going to tax the Arduino.  At 115200 bps, you've only gotta process 14K bytes per second.  The Arduino could handle 10x that amount without breaking a sweat.
(I can send 64K bytes per second to a 12 bit DAC after generating the samples through additive synthesis, all while updating two servos, a shift register, and reading four analog inputs.)

Go Up