WS2811. Roller coaster fuse effect needs high travel speed of led pixels. 8ft/s

Status
Not open for further replies.

hiuch

New member
Hi first time poster here. Thanks in advance for the help!
I am doing a fuse effect with a group of 7 leds traveling down a 5 meter strand running on Arduino Uno. Colors of leds range from
white (tip) to amber(tail)to imitate a sparking fuse. A tracking projected lit fuse video complete the effect. It looks great but as this is for a roller coaster
the effect have to match the speed of ride vehicle at 8ft/sec. A speed I am not able to achieve with my set up. Would using a Teensy 3.0 increase my chances of success?
How fast can I get the packect of Leds to travel with the Teensy and appropriate codes (faster then Uno?)? Maybe a faster chip then the ws2811?
Here's the Arduino code for reference.

Code:
#include <FastSPI_LED.h>

#define NUM_LEDS 85

// Sometimes chipsets wire in a backwards sort of way
struct CRGB { 
  unsigned char g; 
  unsigned char r; 
  unsigned char b; 
};
// struct CRGB { unsigned char r; unsigned char g; unsigned char b; };
struct CRGB *leds;

typedef struct
{
  double R;
  double G;
  double B;
} 
RgbFColor;

#define PIN 7
#define bri 50 


#define chase 5 //speed of chase = 50 millisec. x 165 leds = 8sec.
unsigned long startPhase = 0;
char jumpState = 0;



void setup()
{
  FastSPI_LED.setLeds(NUM_LEDS);
  //FastSPI_LED.setChipset(CFastSPI_LED::SPI_SM16716);
  FastSPI_LED.setChipset(CFastSPI_LED::SPI_TM1809);
  //FastSPI_LED.setChipset(CFastSPI_LED::SPI_LPD6803);
  //FastSPI_LED.setChipset(CFastSPI_LED::SPI_HL1606);
  //FastSPI_LED.setChipset(CFastSPI_LED::SPI_595);
  //FastSPI_LED.setChipset(CFastSPI_LED::SPI_WS2801);

  FastSPI_LED.setPin(PIN);

 FastSPI_LED.init();
  FastSPI_LED.start();

  leds = (struct CRGB*)FastSPI_LED.getRGBData();




 
}

void loop(){

     for(int i = 0 ; i < NUM_LEDS - 7;i++ ) { //- (X) x=number of leds in chase
          memset(leds, 0, NUM_LEDS * 3);
          int l = i;
           leds[l].r = 13; leds[l].g =2; leds[l].b = 0; l++;
           leds[l].r = 20; leds[l].g =3; leds[l].b = 0; l++;
           
           leds[l].r = 35; leds[l].g =5; leds[l].b = 0; l++;//gb combo, l++ = push next
           
           leds[l].r = 75; leds[l].g =10; leds[l].b = 0; l++;//gb combo, l++ = push next
         
            leds[l].r = 125; leds[l].g = 24;  leds[l].b = 0; l++;  // rgb combo, l++ = push next
            leds[l].r = 175; leds[l].g = 50;  leds[l].b = 0; l++;  
            leds[l].r = 255;  leds[l].g = 120;  leds[l].b = 17; l++; 
            leds[l].r = random(250,50); leds[l].g = 120;  leds[l].b = 17; l++;  
           
           
            
            // l+2; 2 space before next led, but NUM_LEDS - 5
            
           
          FastSPI_LED.show();  //push current data
          delay(chase);        //speed of chase
        }
       digitalWrite (PIN, LOW);
       delay(250);    // 3 min. delay (180000 mil sec. - 5leds x 25 mil sec = 59975
    }
 
A strip of WS2811 takes 30 microseconds per LED to update. This is a rigid timing requirement for the WS2811. Nothing can change that.

The OctoWS2811 library is 8 times faster, but only because you would cut the strip into 8 smaller strips and run 8 separate signals. All 8 (which are 1/8th the original length) update simultaneously. OctoWS2811 can also help by doing the update in the background, so your code can get the next frame ready. But this animation looks so very simple that I do not believe this is a substantial factor.

Other LED controllers, like LPD8806, have very flexible timing. They can update much faster.

What speed you actually need is a mystery to me. I'm confused by many conflicting details in your question. Your code comment seems to indicate you have 165 LEDs. Or maybe only it's only 85, as NUM_LEDs is defined and used in the code? You mentioned a speed of 8 feet/sec. 5 meters is approx 15 feet, so at that speed, the entire length is traversed in 1.9 seconds. But the code has a comment indicating 8 seconds, and it looks like the actual number is 1/10th of that, for 0.8 seconds.

Let's assume you want to refresh 165 frames over 1.9 seconds. That's 11.5 ms per update. 165 LEDs at 30 microseconds each is 4.95 ms. This animation is so very simple, you're probably spending less than 0.1 ms computing the new data for each update, but let's assume it's 0.1 ms. So you'd need to delay 6.45 ms.

If those numbers are right, using OctoWS2811 would not be worth the trouble of running 8 signal wires. It would reduce the update time to 0.62 ms. It would also allow your code to work on the next frame during those 0.62 ms. But if you need a new frame every 11.5 ms, much as I'd like to see you use a Teensy 3.0, that sort of speed would just necessitate longer delays.

Then again, I may have misunderstood what you're trying to do. This question is really confusing with so much conflicting info.
 
Thanks for responding. Sorry for confusing info..

Thanks for the respond. Sorry for the confusion. I did the code for myself and didn't clean it up after messing with it.
Lets forget about meter or feet per second and just deal with LEDs per second. It is too confusing (sorry).
I need the packet of 7 LEDs traveling down the strand of 165 LEDs strip in just 1 second. So it is 165 frames over 1 second
 
Ok. 165 frames/sec is 6.06 ms per frame.

You can probably get approximately that speed with a single strip and FastSPI if you have little or no other delay. 165 LEDs takes 4.95 ms to update. So you have 1.11 ms of extra between updates. If you use delay(1) or delayMicroseconds(1100), you'll probably be very close to the desired speed.

OctoWS2811 is overkill. You would need it if you wanted faster than 1 second or if you wanted many more LEDs, but for 165 updates to a 165 LED strip over 1 second, the normal way is possible.
 
Status
Not open for further replies.
Back
Top