Hi and first of all:

Archive FastLED Archive
,
1

Hi and first of all: Amazing library! I stumbled about it when I realized my Raspberry Pi Xojo project needed an Arduino for WS2801 control, and though I never programmed in C before I find the code easy to follow and modify. Anyway, there is one issue I couldn’t find a solution for when searching this group:

For my project, I want to display a temperature chart and created a palette:

DEFINE_GRADIENT_PALETTE( celsius_outertemp ) {
0, 18, 0, 50, //deep purple, -30
38, 28, 0, 70, // just to keep the gradient flowing
80, 40, 20, 100, // -5 degrees: Color kicks in fully
96, 255, 255, 255, //white, 0
116, 0, 0, 200, //blue, +3
128, 0, 131, 160, // türkis, 10°
138, 0, 150, 118, // türkisgrün, 13 °
150, 0, 160, 0, // grün, 17°
160, 0, 130, 0, // grün, 20°
167, 0, 190, 190, // gelb, 22°
173, 210, 183, 0, // Orange, 24°
196, 200, 0, 0, // Rot, 32°
206, 230, 0, 0, // Rot, 35°
255, 230, 0, 230 }; //pink, +49

created a Palette from it:
CRGBPalette16 CelsiusPal = celsius_outertemp;

but when trying the values they are never on spot.
When I use this line:
fill_solid(LEDs, NumLEDs, CRGB(0, 130, 0));
it gives me a nice green that should be equivalent to the value of 160.

But on using ColorFromPalette, a loop like
for (int i = 160; i < 180; i++) {
fill_solid(LEDs, NumLEDs, ColorFromPalette(CelsiusPal, i, 255, LINEARBLEND));
FastLED.show();
FastLED.delay (500);
}

starts in the blue range and finishes a bit more to the green than with the first line of code, about 30 too high. Any hints what might be wrong?

2

Is it possible that one piece of code you were using uses the color correction argument in the array definition but the other one doesn’t?

3

Thanks for your reply, Daniel!
To be honest: I am not sure. I have a TypicalSMD correction in the setup. Do I have to define it somewhere else too?

Still, I wouldn’t know why the colors are off by a certain number. A yellow should be somewhat yellow, not green, even if color correction is used – or do I err?

4

Hmmm. Try it without color correction. Maybe there’s a bug where color correction works on fill_solid but not palates?

5

Good idea, but no, it’s the same. Guess I’ll try a few combinations and see if there is really a certain offset I could compensate easily. Just wish I’d knew why – you didn’t see anything suspicious in that code, did you?

6

I don’t use color palates much, but I think you might be using 4-bit color. Try using CRGBPalatte256 instead?

CRGB ColorFromPalette (const CRGBPalette256 &pal, uint8_t index, uint8_t brightness=255, TBlendType blendType=NOBLEND)

7

Thanks again for your reply!
As far as I understood, a palette16 is not a 4 bit color palette but uses 16 anchor points to interpolate between all possible 256 values.
Anyway, I’ve been experimenting a bit more and found there’s something fishy with the interpolation of close color anchors. The deep orange / red area of the hot colors isn’t really shown, it’s a very bright color, almost white. Only when I reduce the refresh rate to about 80 or if I disable interpolation, the defined colors do show.

Using a Palette256 brings memory warnings currently on an Arduino Uno, but if there should be a minimum color distance for good interpolation in a palette16, maybe it would be worth a try.

Strange is: There seem to be no colors below position 4. A ColorFromPalette(0–3) brings dark LEDs only.

I thought I found the offset – a value of +15 brought the intended colors over a broad range, but where the yellow and orange should be suddenly a deep green appears.

Think I will give it a final try with a clean project, just testing the color values and comparing to a default palette. If it still won’t work, I am probably better off with some default color values and blending colors by hand.

8

@Ulrich_Bogun ah, maybe the issue has to do with the fastLED’s temporal dithering feature. You would have to ask @Daniel_Garcia , but I wonder if one way that you define colors does dithering and the other way you define colors does not do dithering. Try running your animation at full brightness using the global brightness variable and see what happens.

9

I finally made it. I cannot say exactly what really solved it: I redesigned the palette for a smaller temperature range so that colors are not too close, and I guess that was the main factor. There’s enough distance between color anchors to give a nice gradient between each.

When I view the gradientFromPalette with the standard method, there’s still a wraparound at the end (is it so that palettes are rather circular instead of linear?), but with my custom gradient method using floats (I only use 117 LEDs in total, but on different segments so I needed a gradient that calculates fractions, not integers) it looks perfect now.

Still no clue why I had no values below array position 4 before - but somehow it was fixed along the line too.

Thanks a lot again!