Possible Gremlin...?

ProffieOS
1

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:

StylePtr<IgnitionDelay<3000,Layers<Rgb<180,20,0>,InOutTrL<TrConcat<TrFade<5000>,Rgb<2,0,0>,TrFade<4000>,Rgb<30,4,0>,TrFade<4000>,Rgb<80,10,0>,TrFade<3000>>,TrConcat<TrFade<1500>,Rgb<80,10,0>,TrFade<2000>,Rgb<40,4,0>,TrFade<2500>,Rgb<5,0,0>,TrFade<3000>>>>>>(),

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.

:slight_smile:

1 Like
2

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:

3

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.
https://fredrik.hubbe.net/lightsaber/style_editor_beta.html

Curiouser and curiouser.
:confused:

4

@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.

StylePtr<IgnitionDelay<100,Layers<Rgb<180,20,0>,InOutTrL<TrConcat<TrFade<200>,Rgb<2,0,0>,TrFade<300>,Rgb<30,4,0>,TrFade<400>,Rgb<80,10,0>,TrFade<300>>,TrConcat<TrFade<1500>,Rgb<80,10,0>,TrFade<200>,Rgb<40,4,0>,TrFade<100>,Rgb<5,0,0>,TrFade<100>>>>>>(),
5

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

StylePtr<InOutHelper<White,300,800>>()

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

6

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

StylePtr<IgnitionDelay<3000,Layers<StripesX<Int<50>,Int<135>,RotateColorsX<Variation,Black>,RotateColorsX<Variation,Black>,RotateColorsX<Variation,Rgb<180,20,0>>,RotateColorsX<Variation,Rgb<30,4,0>>>>>>(),
7

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:

8

@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
9

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…

10

Thanks @A_Rogue_Child - 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…
:slightly_smiling_face:

11

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
12

: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
13

I have a bit of an update on this one. Last time I put it down to incompatible LEDs strung together as a sub-blade, but I now think that was wrong. And as always, the Prof’s original theory that it would be power-related has, I believe, turned out be correct…

I’ve just had another hilt exhibit this problem. Similar setup - a string of LEDs split up into sub blades, with the middle blade flashing and banging.

Bizarrely it worked right when I first built it, then the problem started later on.

Tried to load the identical config onto my test rig and added the same components, but couldn’t recreate it.

So tried writing the rotating plasma gate motor out of the config on the hilt. The problem went away. Wrote it back in, the problem returned.

So what’s the common factor?

In this case, and the case first mentioned at the top of this thread, motor and sub-blade LEDs were all wired hard off the battery positive. So I moved the LED positive to a regulated 3.3 volt pad. In this case it was the SD pad, as I thought I’d try that first before unpicking my 3.3 volt pad which was in use by other stuff. (And given the conversation recently on another thread, 3.3 volt and SD power are, to all intents and purposes, interchangeable up to OS 7.x).

Re -wrote the motor in, and lo and behold, problem solved.

So the moral of the story is don’t power sub-blades from the same positive source as your rotating motor. That’s one rule I’ll have to remember in future.

:slight_smile:

14

Motors create a lot of electical noise. A filter circuit (which can be as simple as a capacitor) might be helpful to fix these sort of things.

1 Like
15

It does occur to me that as motors are generally wired with positive hard off the battery, and since the main blade must be likewise, that there is scope for interference to the main blade with the motor running, though to date (touching lots of wood!) I’ve never seen it. So far I’ve only observed it upsetting sub blade arrays.

But if one were to add a capacitor, I assume we’d wire it between the positive leg of the motor and the main board ground, is that right?

16

I think the most effective place would be between + and - on the LEDs that are experiencing a problem actually. However, having a capacitor between + and - on the motor itself would reduce noise for everything in the saber, so that might be good too. Maybe do both?

I’m not sure what size capacitor would be needed though. The frequencies involved aren’t super high, so it’s possible that the capacitors would need to be fairly large. If that’s the case, then it might be helpful combine the capacitors with ferrite beads, which also cuts down on noise in the system.

Of course, all of this is just theory, it’s entirely possible that the problem something completely different…

1 Like