Control Position of Only a Section of Long LED Strip in Real-Time

Status
Not open for further replies.
Looking for project feasibility and recommended parts guidance.

  • Want to illuminate only a short section (maybe 6-10 LEDs) of a long LED strip. Calling the section a light "pulse". Want to control position of pulse in real-time based on manual input
    from user device connected to teensy.
    Left button press= pulse moves left down strip.
    Right button = pulse to right.
    No button pressed = Pulse remains at current position.
    Pulse velocity need is <= 20 m/s.)​
  • Application requires use of a very long LED strip - upwards of 30.5M (100 ft).
  • May not be feasible to route parallel power conductors every 3M or so.
  • Definitely cannot split the length into two separately-controlled strips.
  • Application will tolerate down to 130-165 lm/m (40-50 lm/ft)
  • RGB would be nice but a single color addressable LED strip would work.
Looking for recommendations on:
-LED strip technology to use (5050, WS2812, etc)?
-Teensy model to use?
-Libraries to use
-Communication protocol (spi, i/o pins, etc)
-Any other thoughts?

Many articles seem to indicate this is not possible/feasible for either voltage drop, memory limitations of microcontroller, power requirements or some combination of these. However, all these articles seem to be based on applications where the entire LED strip is assumed to be powered. Again, this application will only ever need the pulse to be illuminated at any one time. Wondering if this fact can be leveraged to achieve a considerably longer LED strip run.
Thanks,
Ryan
 
Again, this application will only ever need the pulse to be illuminated at any one time. Wondering if this fact can be leveraged to achieve a considerably longer LED strip run.

To specifically answer your question, with the commonly available LEDs strips (WS2812B, APA102, LPD8806, etc) you would need to relax this requirement to control only LEDs beyond the first part of the strip:

  • Definitely cannot split the length into two separately-controlled strips.

The way all these LED strips work requires you to update all the prior LEDs in the strip, even if you only wish to change just 1 in the middle. This design is fixed in the controller chips inside the LEDs. No amount of wishful thinking can change that. You'd need a different controller chip inside the LED and a fundamentally different communication protocol than any of the widely used strips actually implements.
 
To write to sectional areas, you must still write up to and including that area, stopping there will not touch the rest of the length, but everything before that section must still be written
 
Also keep in mind that the LED controller chips internally use PWM frequencies between 400 Hz to 2 kHz to actually control the LEDs. Very rapid updates where you keep the color the same for only a few PWM cycles tend to produce poor quality results. Generally the best strategy (for non-POV applications) is to choose a fixed update rate of 30 or 60 Hz and then design your animations and communication around that fixed refresh rate.

Faster is not necessarily better, and in fact becomes horrible as you approach whatever (imprecise) PWM rate is actually used in the LED controller chip.
 
To write to sectional areas, you must still write up to and including that area, stopping there will not touch the rest of the length, but everything before that section must still be written

Yes, so I'm thinking (hoping) frame rate will be able to achieve the pulse animation I'm thinking for. Just subtract a pixel from the direction pulse is going away from and adding one to the direction pulse is traveling towards.
 
Also keep in mind that the LED controller chips internally use PWM frequencies between 400 Hz to 2 kHz to actually control the LEDs. Very rapid updates where you keep the color the same for only a few PWM cycles tend to produce poor quality results. Generally the best strategy (for non-POV applications) is to choose a fixed update rate of 30 or 60 Hz and then design your animations and communication around that fixed refresh rate.

Faster is not necessarily better, and in fact becomes horrible as you approach whatever (imprecise) PWM rate is actually used in the LED controller chip.

Thank you. This is really helpful to know which direction to start in some of the myriad choices involved in a total system.
 
Just subtract a pixel from the direction pulse is going away from and adding one to the direction pulse is traveling towards.

I do not recommend this approach.

I'd suggest computing which pixels should be on at any particular time (rounded to the nearest 1/30th second). This may seem more complex, but in the long run it's much simpler. Teensy is extremely fast and very well capable of doing this calculation many thousands of times per refresh. Put the CPU to good use. A strategy that fully decouples the animation speed from the physical refresh rate gives you tremendous flexibility. Rigidly coupling the 2 will really limit you if you try to do anything else.
 
Status
Not open for further replies.
Back
Top