Ok @Daniel_Garcia , here are some images of more testing that I did with both 2.1 and 2.1-Dither. The first two images (vertical) are what it looks like with 2.0 (and how I expect it to look like too.) The next two is what 2.1-Dither does. For some reason the last pixel tends to get messed up. This does not happen with all of the effects, only with these two. And the last image is what happens with 2.0 (no dither) with just that one effect, all others are fine including the other one that fails under 2.1-Dither. These are all dynamically generated. I have not run actual images through them yet.
Can you get @Mark_Kriegsman and I the code that you’re running through here so we can see what the difference in dithering output is, and why? Also - just to sanity check - what do you get/see when you run 2.1 Dither with dithering disabled? (Also - are you running this on an avr or an arm?)
Oh, I forgot to mentioned that, dithering is disabled. And it’s on a 32U4 AVR. I’ll get you code shortly.
For the spiral one:
void HSVRainbowSpiral() {
static uint8_t hue = 0;
static uint8_t cntr = 0;
static uint8_t off = 0;
if (millis() - patternLastRun > 10) {
if (!off) {
leds[0] = CHSV(hue, 255, 255);
} else {
leds[0] = CHSV(0, 0, 0);
}
LEDS.show();
cntr++;
if (cntr > 5) {
cntr = 0;
off = !off;
hue += 15;
}
for (uint8_t px = NUM_LEDS - 1; px > 0; px–) {
leds[px] = leds[px - 1];
}
patternLastRun = millis();
}
}
The bars one:
void HSVRainbowWheel() {
static uint8_t hue = 0;
static uint8_t off = 0;
if ((millis() - patternLastRun > 10) && (off)) {
FastLED.showColor(CHSV(hue, 255, 255));
patternLastRun = millis();
off = 0;
hue += 10;
} else if ((millis() - patternLastRun > 5) && (!off)) {
FastLED.showColor(CHSV(0, 0, 0));
patternLastRun = millis();
off = 1;
}
}
I also have a rather debilitating migraine right now so I’m off for the night. Take your time.
Sorry to hear about the migraine; I hope you got some rest and are feeling better now.
I’ll single step this code in a bit, but I have one oddball longshot question too: would you check that NUM_LEDS is actually set to the real number of LEDs? I wouldn’t even mention this except that I had a problem with the ‘last pixel’ looking fine under 2.0, but getting messed up under 2.1. It turns out that the v2.0 library has been transmitting NUM_LEDS+1 pixels worth of data the whole time, and that the newer v2.1 code transmits (we think) just exactly NUM_LEDS pixels worth of data.
I had a code with NUM_LEDS set to 30, and a matched bar of LEDs. When I switched it to v2.1, the last led was messed up. The problem? Turns out I had 31 LEDs on the bar and had miscounted them as ‘30’, and it had oops magically been working under v2.0. DOH!
Given how much time you put into building your hardware, this seems unlikely for you, but I had to ask.
As for diagnostic tests, I’d ask this: if you set NUM_LEDS to one more than the number if real LEDs, do the visible artifacts disappear? And if you set NUM_LEDS to one LESS than the real number of pixels, are the artifacts still there, but moved in one pixel?
Thanks for the help in shaking out the boundary cases. The lightpainting photos really help!
Also: LPD8806? WS28xx?
8806 aka, speed demons.
And NUM_LEDS is set at 48, which is what the stick has on each side. There are four strips of 48 wired in parallel. But it happens with just one strip as well. There are also pull downs at the end of each strip, without them they lose their minds when I start sending data.
I’ll test with it set at 47 and 49 later tonight.
I’m assuming you’re using the hardware SPI output, or are you bitbanging SPI output?
Bit banging … SPI is being used to read an SD card, and since no strip I’ve ever worked with has a chip select pin, I’m stuck with bit banging (unless I add additional hardware.)
Ah - ok - that might be the problem then - I’ve run into problems with the bitbang’d output and the last bit in the past. Try setting NUM_LEDS to 49 - but keep the last led 0’d out - easy way to tell if it’s a last bit/byte issue.
Yeah, I’m going to do that in a bit here. I told Mark I would test NUM_LEDS = 47 as well as NUM_LEDS = 49 (actual length is 48). I’ve been fiddling with my UDOO platform for the last few hours. Need to get dinner started for when the kid gets off of work, then I will re-focus on this after I put the black curtain up. 