Possible Gremlin...?

I just built a Scav Master and my heat up/cool down effect is occasionally exhibiting random flashes. (Watch the middle part of the chassis after I fire it up).

OS is 7.7 downloaded a couple of days ago.

Full config is here:

And the line of code controlling that pixel LED is here:


It’s not a biggie, and I know the dither at very low light levels means I’ll never get the fade up to red from black to be completely smooth, but it’s the white flashes that I don’t think should be there. As such, I’m curious to know what people think. Are the white flashes an unavoidable dither artefact or something that can be fixed?

As always, thoughts welcome.


Weird. Maybe there’s something up with IgnitionDelay in general.
This is in the style editor. Notice all the activity while power isn’t even on:

That is weird! :open_mouth:
And looks like you’re using a different style editor to me, as the one I use shows the line in question flawlessly.

Curiouser and curiouser.

@nosloppy may be using a slightly changed version of the editor is all. That part shouldn’t matter as I’ve used his version and it all relies on the same stuff.

tl;dr advisory and I could well be completely wrong with my thinking here.**

@Sabersense Maybe a rewrite or even expanding that line of code with more parameters (if that’s a thing) so there’s more to go off of and less chance of errors will solve it? Where I am going w this is the way you have the playing of the colors timing-wise and layered it appears that there’s a point where all the different colors meet a point in time where they all stack up and the board is interpreting (or it just happens based on the culmination of a combined value set) it as all those values are not as individuals playing among each other and each coming and going out of play. Instead it’s reading them as a group, all at once, in a specific point in time, with all the values added and stacked resulting in a “spiked” value which at that point if you add everything up can be a very bright color, in this case white. Picture 4 people with flashlight beams dancing on a wall, each round a different shade and output value of the same theme. What happens when randomly, or through subtle influence they all meet at the same time? You get a bright spot. To paraphrase, you got a lot of fuel going in at times all at once. **I am not 100% sure here and hopefully this makes sense to those w more knowledge since I am pulling from a past experience with fuel mapping.

So, skipping all that, LMK if this works better or switch the line to a pulsing effect instead.


I retract that it might be IgnitionDelay, and resubmit it might be InOutHelper.


Still doing it. Unrelated to OP it seems. Moving on.

Here’s another option to try out that’s a pulsing/rotating effect.


Thanks for the blade styles Revo - but unfortunately they don’t really give the effect I’m after, and I’d prefer to fix the preferred behaviour rather than go with something different.

However I think I’ve made some progress…

I tried the same config with OS-6.7 and 6.9, but they’re all the same. So I tried to think what’s different about this Scav to others I’ve built, when the others have all worked fine.

The only thing I came up with that’s different on this one is that the LED for the crystal chamber - which is wired on from the two flickering LEDs as a sub-blade - is one of the new nano pixels from Saber Armoury. Description here:

That sub-blade array comes from data 1, so is pre-resistored. So I tried writing the crystal chamber out of the config completely.

Lo and behold - the issue was gone!

So my guess is these nano pixels don’t terminate data as well as regular pixels, causing data reflections back up that blade array?

So the moral of this story appears to be that if you’re using one of these nano pixels, give it its own data line rather than adding it to a sub-blade.

Which leaves me with my last question - is there a way for me to fix this in the config, as opening this chassis up is basically out of the question? I’m guessing the answer is no. :confused:

@Sabersense No worries and while I get where you’re coming from I’ll point out you hint at not wanting to tear back into the build. With that logic maybe having two different code options that could stop the issue and save you having to swap out a pixel should be worth a try. No it doesn’t address the direct issue but in this hobby work-arounds are a thing. :wink:

@profezzorn is there a point where a small resistor can be wired in-line to regulate the data feed better? *If it is indeed the pixel itself. I’d be interested in seeing what the line is seeing before and after.

MTFBWY. :smiley:

1 Like

There are neopixels that don’t like to talk to each other properly, but most of the time, that’s not actually the problem. Instead, the problem is power. I don’t see any mention of how power was wired for these pixels, and if SHARED_POWER_PINS was on or not…

Thanks @Revo - you’re right of course, and I must confess I did like the second style you posted in particular, so I took the liberty of keeping that one for a future install. :grinning: :+1: :pray:

Positive for the pixels is in series fed directly from the battery +, and negative is in series from a single LED power pad. So it’s effectively like taking one single strip of LEDs and dividing it up into separate blades using sub-blades.

The only other power consideration is that there is also a conventional 3mm accent LED. For the positive for this, I added a 100 ohm resistor in line, fed from the first pixel positive (as this was hard wired to batt+ in any case). The negative for the 3mm LED goes to a different LED pad for individual control.

I also tried writing that 3mm LED out of the config completely but it made no difference, so I don’t think that particular power arrangement is the issue.

Since the pixel array of three pixels are all fed from the same LED power pad and the same data pad, I didn’t define SHARED_POWER_PINS as I thought that was only for arrays that shared a power pad but had their own data lines. But I can give it a go when I get home and see if it makes a difference.

Will report back…

If they are powered from the same pad(s), then SHARED_POWER_PINS should not be needed, or make any difference.

It does sound like these pixels don’t really want to talk to each other…

1 Like

:wink: FWIW on that second style you can slow it down or speed it up even more and it’ll still act like a breathing pulse across a single or across a string of LED’s. See what the end of the blade’s doing? Just edit the INT values.

1 Like