Having some fun times trying to fade an HSV value by lowering the ‘value’. Try setting the following hue, CHSV(40, 255, 255), then lower the value, say by 15 every cycle. The last few steps it will turn orange, green, then red before finally shutting off. Is this just an artifact of how HSV works? If so, what’s the best way to fade to black?
I haven’t experienced that problem, I love to work in HSV because it is so easy to fade in and out. The glamm() code here:http://pastebin.com/EBpRTPH5 uses the same technique of fading and I have never seen that with the naked eye. Are you seeing it only on the pictures you take?
What IC are you using?
The Micro as well. UCS1903 leds.
I just tried a regular, of-the-reel, LPD8806 strip and it’s showing the same thing as my custom made ones. So try something for me, run this code (modifying it for your strip) and tell me what you get. I’ll grab a video shortly here …
#include “FastLED.h”
#define NUM_LEDS 48
CRGB leds[NUM_LEDS];
#define DATA_PIN 11
#define CLOCK_PIN 12
volatile int value = 255;
void setup() {
LEDS.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, BRG>(leds, NUM_LEDS);
}
void loop() {
fill_solid(&(leds[0]), 48, CHSV(42, 255, value));
LEDS.show();
value -= 5;
delay(150);
}
I distinctly see the last two steps of the fade on my rig too. The last bit of light is pure red. Hrm…I usually fade faster than that so I never noticed.
Yep, the last few steps are off … and I don’t know if it’s the way HSV works, or if it’s in the library. @Daniel_Garcia @Mark_Kriegsman care to elaborate?
I can fade faster but because this is a (fast) moving piece, any color deviation will be visible. For yellow, you will get a streak of red at the last step(s).
This is certainly now how HSV is supposed to work.
I saw the same thing in my fade code when I did the second hardware/software fade test with the WS2801s in RGB mode. I fixed it but I can’t remember how.
I vaguely recall that it was an off by 1 bug, with a for loop going off the end of the array, corrupting one of my variables that was allocated right after the array. Or something like that.
Let me sleep on it.
Or maybe a rounding error. I can’t think. It’s almost 4am.
If it’s a rounding error it’s the same as the flash of blue light in the last fade in this video: http://youtu.be/jjJsdtr7vbY
It only happens when there’s color mixing going on. Primary LED colors, red, green, and blue don’t show it, they fade correctly.
Well, you could think of it as a rounding error but not really. The blue flash in my video above is the same thing that you’re seeing.
When it’s not a primary color, there are two RGB colors being displayed. One is brighter. One is dimmer. Eventually both are going to become black as you fade down. They stair step down because there are only a finite number of bits. Usually this is invisible, but not when you get dim.
At it’s dimmest, one color gets to black before the other. When one color goes to black before the other, that’s when this happens. At the very end you see only one primary color.
It’s helpful to see this in a static mode, something that does not change with time.
#include “FastLED.h”
#define NUM_LEDS 48
#define DATA_PIN 13
#define CLOCK_PIN 11
CRGB leds[NUM_LEDS];
void setup() {
delay(2000);
FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
//FastLED.addLeds<WS2811, DATA_PIN, GRB>(leds, NUM_LEDS);
FastLED.setBrightness(255);
}
void loop()
{
const uint8_t hue = 48; // yellow
for (int i = 0; i < NUM_LEDS; i++)
leds[i] = CHSV(hue , 128, i);;
FastLED.show();
delay(1000);
}
The only thing that puzzles me is the black space at the beginning of the strip. @Mark_Kriegsman what do you think of the black part of the strip?
I understand the reasoning behind why it’s doing it. However, if I use nscale8() on CRGB() or if I use setBrightness(), I don’t see that happening. It’s only happening with CHSV().
Oh ok. Even with this simple code there are some things going on there that I don’t understand like why is part of the strip black before the colors appear.
Paul - usually when the first led isn’t showing colors, i’ve found it to be a grounding or wiring issue somewhere along the line.
It’s the first 16 LEDs in the code above.
I’m not at my computer the whole day today, but I’ll try your code later this evening. Is it possible that values below 16 are just too low to see?
I just checked in a dark place and they’re completely off.
Ok, so @Paul_Russo 's code above on LPD8806 drivers, as-is, on both my 48 pixel POV stick as well as a stock strip straight off the reel, I get only the LAST 20 LEDs to light up: 4 red, 8 yellow, 6 orange, and the last 2 are white. So the first 28 aren’t lit at all.
Now, if I increase the saturation to 255, things change: 9 red, 4 yellow-greenish, 10 yellow-orange, and the last two are brighter yellow. The first 23 aren’t lit.
Now, I do understand that it’s very difficult to maintain a shade of blended colors when you’re changing their intensity, so I totally get the change in tint. Just for fun, I decided to try and run it as CRGB() instead and I noticed that nothing lights up with a value less than 3. At least, on my stock LPD8806 strips, setting CRGB(1, 1, 0) or CRGB(2, 2, 0) will produce nothing. Things start to light up at 3 and higher.
If the same is true for the HSV scale, that explains why several pixels on the low value won’t light up.