Howdy all. I built a simple matrix box and could use some advice. I’m terrible at coding so I was super happy to find that the FastLED sample “Noiseplayground” had a wonderful animation effect. It took very little configuring to get it up and running. The problem? As you can see in the photo, it’s just too dim. I’ve tried adjusting the line: LEDS.setBrightness(96); from the default of 96 to something higher, even up to 255 but the display never gets any brighter after 96. (I can however make it dimmer). Any thoughts or suggestions would sure be appreciated. It’s fine in indoors, but I want it in my garage where the lights need to be BRIGHT.
Thanks!
How many LEDs? What power supply? Have you set the maximum power in the code? This will limit the brightness setting…
150 LEDs on a 2812 string. Power supply seems to be fine because other FastLED samples are full brightness. I have NOT set maximum power in the code as I can’t seem to find any other setting to do this.
It would help to see your full sketch, plz post it in http://gist.github.com
Adjusting LEDS.setBrightness from 96 to the max of 255 should make things brighter. Not sure why you’re not seeing a change. I don’t think there’s anything else in the code there that is limiting the brightness. Have you tried changing from 96 to 255 when it’s dark to more easily confirm it is/isn’t changing?
From the photo of your shop it looks like your fighting the brightness of the physical lighting (at least for daytime on a bright day) for the location where you have this installed. Looks like quite a lot of light is coming in from the outside (which is normally a wonderful thing unless you’re trying to see your cool custom installed LED matrix 
. You’re always going to have trouble competing with bright light like that as these little LEDs aren’t /that/ bright comparatively.
Other thoughts:
Depending on what you used for the diffusion that might be cutting the light down quite a bit. How does the pixel brightness look without the diffusion?
You could try doubling up the pixels with a second (duplicate parallel) strip of lights.
What color are the insides of the matrix cells? A lighter color might help light each cell up.
You could shade/darken the skylight area above your matrix to reduce the amount of outside light in that local area. And/or make a bit of a hood to shade the Matrix area.
Marc,
I appreciate your thoughtful remarks. I’ve considered all but they are non-issues. I say this because I can run other LED strip demos on the same box in the same location and they are easily twice as bright. The only difference being that they don’t use hues. Is it possible that hues can only produce so many lumens and that’s it? Am I fighting something that I can’t fix?
Hi Ken, I am not at all an experienced programmer but kinda expecting to find something obvious in your sketch but that did not happen. Although, I struggle with the 'fill_2dnoise16… ’ function and all it’s different parameters and wonder how it works !?
If you can temporarily change your sketch to replace that ‘fill_2dnoise16’ function and set all the leds on full brightness red then green then blue then white, do you then get an acceptable light output !??
If yes, your problem is in that 2Dnoise function. Otherwise apart from a less opaque diffuser, I can’t think of anything else !
Ken, sorry, I missed your point about everything else looking fine brightness wise. Well then… let’s investigate further!
So I just set brightness to 255 and then added this into the main loop right after show()
EVERY_N_MILLISECONDS(200){
Serial.print("\tr: “); Serial.print(leds[0].r);
Serial.print(”\tg: “); Serial.print(leds[0].g);
Serial.print(”\tb: "); Serial.println(leds[0].b);
}
This will print out the R,G,B values for pixel zero every 200 milliseconds. I expected to see a very large range of values, but this is what printed out:
r: 1 g: 0 b: 0
r: 17 g: 20 b: 1
r: 0 g: 0 b: 0
r: 0 g: 1 b: 0
r: 5 g: 3 b: 0
r: 38 g: 33 b: 3
r: 1 g: 0 b: 0
r: 4 g: 7 b: 0
r: 2 g: 2 b: 0
r: 40 g: 47 b: 4
r: 1 g: 0 b: 0
r: 2 g: 2 b: 0
r: 41 g: 22 b: 3
r: 2 g: 4 b: 0
r: 6 g: 2 b: 0
r: 6 g: 49 b: 3
r: 31 g: 19 b: 2
r: 4 g: 3 b: 0
r: 7 g: 4 b: 0
r: 33 g: 25 b: 2
r: 7 g: 6 b: 0
Nothing very high there at all! I would expect to see values above 200 in there somewhere once in awhile. Thus the low brightness you are indeed seeing even with brightness set to 255. @JP_Roy 's comment is definitely pointing in the right direction I think.
I can’t figure out what variable(s) to change feeding the fill_2dnoise16 function to get the values to be higher.
@Ken_Bosak This is not a solution, at least not a proper solution in my mind, but as an experiment past these lines of code in just before the show() line. It will multiple the rgb values way up so you will get some max values of 255. See if this makes the brightness look better on your display.
for (uint8_t i=0; i<NUM_LEDS; i++){
if(leds[i].r <= 32) { leds[i].r = (leds[i].r *8) -1; }
if(leds[i].g <= 32) { leds[i].g = (leds[i].g *8) -1; }
if(leds[i].b <= 32) { leds[i].b = (leds[i].b *8) -1; }
}
@marmil , I think that’s the right plan. I tried your code and the LEDs are brighter but the colours change in unexpected ways. The results are better if you convert to HSV, increase the brightness by increasing V and then write back into the pixel. I’ve just put in a straight multiplier, which isn’t quite right but seems to work 
for (uint8_t i=0; i<NUM_LEDS; i++){
CHSV hsv = rgb2hsv_approximate(leds[i]);
hsv.val = hsv.val*4; //adjust multiplier to suit
leds[i] = hsv;
}
(I’ve got no idea how that noise function works either!}
Or try this which incorporates both solutions…
for (uint8_t i=0; i<NUM_LEDS; i++){
CHSV hsv = rgb2hsv_approximate(leds[i]);
if(hsv.val <= 32) { hsv.val = (hsv.val *8) -1; }
leds[i] = hsv;
}
The colours are still a little unstable due to the conversion to HSV and back to RGB but they’re reasonably close.
@Jeremy_Spencer Agreed, my idea of multiplying anything <= 32 wacks the color for that pixel compared to it’s neighbors for those cases where an r, g, or b value is just above 32. I like your idea of dealing instead with Hue.
I was also thinking maybe maybe instead of using <= 32 gets multiplied by 8, instead use <=64 is multiplied by 4. There would be even less (maybe no) values cut off this way? And if there was an r, g, or b value above 64, then first scale the rgb values down slightly until 64 becomes the max, and /then/ multiply by 4.
So something like this:
if (leds[i].r > 64 || leds[i].g > 64 || leds[i].b > 64) {
…scale r, g, and b all down so the max is 64…
}
And then continue with the scale up by 4x (and minus 1).
Thanks for all the help guys. I’ve been silently watching and trying your suggestions. The one that seems to work the best is @Jeremy_Spencer 's solution of:
for (uint8_t i=0; i<NUM_LEDS; i++){
CHSV hsv = rgb2hsv_approximate(leds[i]);
hsv.val = hsv.val*4; //adjust multiplier to suit
leds[i] = hsv;
}
It keeps the ‘hues’ without introducing the bright colors.
One thing as long as I have the podium. The colors change very fast. I’m hoping to find a way to slow things down and make it a much more relaxing visual. Right now I’d use the word “hyper” to describe the effect. Sorry if this is simple and obvious, but I have no idea what I’m doing. I just tweak setting and look to see how things change.
Best regards!
Ken
Thanks @Ken_Bosak , add FastLED.delay(10); after FastLED.show(); to slow things down. Adjust the delay accordingly
While playing with the fill_2dnoise16 function variables I did manage to get it to do some slower more relaxed stuff at one point but I can’t remember what those settings were. The numbers that are in the example file seem very arbitrary/random to me, and some are such large values. Don’t know how it works. Maybe one could use the visual graphing feature in Arduino to more easily see how something is changing, but maybe that’s just about the same as looking at your LEDs.