I have problem with DemoReel 100 when the nuber of leds are 150-300. for about 60-100 it’s ok. but as you see in the video with the sinelon pattern some LEDs are missed, I mean they remain off. if I increase the number of LEDs to 300 more LEDs are mised and only every 3 of them turn on, what is the problem?
What micro controller are you using?
And what LEDs and what version of the library and what version of Arduino?
The demoreel code uses 8-bit math in several places; if you have more than 256 LEDs, there maybe skipping as a result.
One of these days I should update it to 16-bit…
and its also going to be limited below 256 based on the FPS setting. Might be a problem for an Arduino to draw 300 pixels that fast.
It could look better if you apply a bit of blur() to the leds that are in vincinity of the current position but that probably needs some trial and error tweaking. It could achieve kind of a “motion blur” effect as used in video composition as well.
Agree with @Mark_Kriegsman most likely an 8bit math issue
It’s ws2812b, fast led version is 3.1, and my arduino is Uno.
Is there anyway to fix it? If I lower the fps more LEDs are missed.
Short (obnoxious) answer: just switch everything to 16-bit math.
Real answer: I’ll see if I can do something for it tonight, carpal tunnel permitting.
I don’t know how to swith to 16 bit math! is it possible with 8bit uC? By the way as I said this also happens with 150 LEDs far less than 256 ones. the video I posted is with 150 LEDs and an fps of 120.
Yeah, it’s not a microcontroller change, just a code change. Should be small. I’ll post as soon as my hand-health allows.
It’s wasn’t an 8-bit vs 16-bit math thing; it’s a “how many updated per second vs how many pixel” thing. But regardless, this code (below) closes the visual gaps by drawing a short bar between the old position and the new one, instead of just one pixel at the new position, and it gives a much more solid look.
My hands are pretty shot at this point, but feel free to play around with it, and let us all know what you come up with!
Code: https://gist.github.com/kriegsman/261beecba85519f4f934
// Updated sinelon (no visual gaps)
void sinelon()
{
// a colored dot sweeping
// back and forth, with
// fading trails
fadeToBlackBy( leds, NUM_LEDS, 20);
static int prevpos = 0;
int pos = beatsin16(13,0,NUM_LEDS);
if( pos < prevpos ) {
fill_solid(
leds+pos,
(prevpos-pos)+1,
CHSV(gHue,220,255));
} else {
fill_solid(
leds+prevpos,
(pos-prevpos)+1,
CHSV( gHue,220,255));
}
prevpos = pos;
}
Thanks Mark, It worked! I just uploaded it with 300 LEDs. the same problem is also seen in bpm pattern. with 300 LEDs you cant see the beautiful pattern as with 100 LEDs. I think that should be modified as well. I’ll try do something similar to bpm().
Great! Pls share code if you improve it!
Probably same idea: draw “bars” not dots…
Hi @Ahmad_Sajadian the bpm() pattern in the DemoReel code iterates over all LEDs and it also works for me so I assume you mean the juggle pattern ? Juggle is a bit more tricky as there are several dots moving out of sync so you get in trouble because by just drawing bars you overwrite everything else. I tried it with blending but its still not really nice. Its probably one of the applications for the yet to be developed “screen” blend mode (which I am still trying to figure out.
Anyway, look at this modification. I dont really like the effect though
@Sebastian_Stuecker : Thanks Sebastian. Your right, I meant the juggle pattern, yeah I uploaded your code, just a few leds at the end of the strip change color and the rest remain almost white most of the time, I think it should be worked on more. I’ll try once I get some time.