A while back I was having problems with fried LEDs and then disappearing code. Not sure why but it would be great to understand more.
The situation - Multiples of addressable Fairy Lights, up to 800 in a single series string, describing a random-ish crisscrossed pattern in 3D; well-balanced injection; and “pretty good” ( I don’t exactly remember) attention to grounding. But I may have missed something.
While running a patterns on the PB3, the pattern would go all wonkers, colors, pattern and brightness off the map, trending toward blue-white. Then strings would burn out, at least downstream of a single point LED. Costly in time and materials.
One event fried most of the string and somehow deleted the code I was running from the PB, as well as another pattern I had loaded but was not running at the time.
Another event, I was showing the string array to a friend reached out toward an LED and voilla static discharge to the LED across about an inch of free space. this promptly set that LED to buzzing then bursting into flames. Yeah, flaming plastic LEDs… not so much a desirable situation.
Question is: How does this happen?
Static/bad grounding?
Array acting as an antenna?
Quantum fluctuations in the weave of space-time?
Well… seriously now, it would be great to understand this better. I’d like to feel that one can build stable systems with components in hand. Any comments or insights would be greatly appreciated. Thanks!
Those wires aren’t well grounded in general… They are open ended at both ends of each pixel, so a spark can happen, for example. I’m sorry to hear about the troubles.
It OK. I’ve learned to not reach in while operating the matrix, and have rewired everything with full attention to grounding, in particular. These issues are why I am going to either find another product, order something custom ( 1/2 the spacing, larger “lenses”, no bare wire ends and etc.) or modify this product to suit for now.
Am still curious as to how this feedback can delete code from the PB, but I suppose all kinds of magic can happen…
You don’t by chance have the +5V sides of the two power supplies connected, do you? I’m assuming everything has a common ground, but you’ve divided your serial run into two sections when it comes to the positive side of the power supplies.
The fire… I just… I just wish I was there to bear witness.
Regarding deleted code: Not saying this is what happened to you, but I’ve experienced a couple times where what actually happened was that the WiFi connection to the Pixelblaze was spotty or went out while I was hacking on some huge pattern. Sometimes my huge pattern was making the board reboot; typing new code would restart the pattern so I thought everything was live and all good, but then my click on “Save” must’ve happened in the middle of a reboot or bad wifi, so I lost entire patterns or lots of work. There’s not a great confirmation in the IDE that a pattern has successfully saved. In addition, rarely I’ll find I’m in a state where previews will not generate, and so you can’t actually hit save. It’s now become almost muscle memory that after a lot of work, I copy patterns out to a text editor just in case they didn’t really save.
Last thought, but I think we can rule this out: I think you confirmed you’re NOT using the mysterious fairy lights that seem to have some sort of field-programmable address setting ability, right? I wondered if you cut these off a crappy controller and they actually have some weird magic sequence you accidentally hit with PB.
I believe that must be what happened, since I was actively messing with code to see what happens… finding it both instructive and super-enjoyable. And, I was dealing with a weak Wi-Fi signal, that worked pretty much reliably for my PC but not for the PB. Now I have a really good signal booster installed in the shop. It works great! At the time of code disappearance it sure weirded me out, tho!
I wish I had it on video. It was a mini-Fourth of July. Fireworks. Arcing internal to the px then spitting out burning plastic and flame. Memorable for sure. Ooo and ahhhh, but damn, there goes another string!
So, there I am working with patterns, editing them on the fly. and things go wonky, like some hand reached into the code and started f’ing with it. Out of my control. This you may already know. Colors went funny, pattern no longer from the source code… then pixels burn toward high intensity, toward white, then burn out. Like some "hand-o-god’ was messing with the controls and hashing my code, burning my strings. It seemed as if the whole string network was getting charged up with power. Freaky for sure.
Anyway, That along with my recent computer crash… made me a whole heaping bit o paranoid about my efforts and their integrity in the work space. And, admittedly that concern was very likely super irrational.
Point is, per the above, the more transparent, reliable and fail safe this system is the better. And for that I am most thankful.
Well, that was quite the diatribe above so here is a more reasoned look at the issues of led burnout and code loss/disruption -
Plastic may not be your friend - Plastic-y frameworks/assemblies certainly can, and Do in my case develop big problems with static build-up. My test-frame that caused so much trouble is a 1 meter PVC tube cube frame with lots of criss-crossing light strings) I can develop significant static charge. I am actually not sure about what to do about this except ground everything (see below). Of course static can destroy LEDs pronto. And if editing code on the PB, delete the code. Likely static buildup is just really “annoying” to running code, causing all kinds of weird effects for a while before actual burnouts start to occur.
Grounding IS your friend - Diligent and thorough. Well thought out and carefully executed. Do it. (Talking to self also)
Working hot, or not - Working with a hot network of LEDs is probably not the best idea unless you are totally Zen and careful about it. The slightest mis-wire and zap!, there you go, stuck pixel, or worse.
Fairy Lights as Antennae? - I’m not sure about this either but the LED strings I’m using BTF Addressable 2812B Fairy Lightssure look like prime candidates for acting like antennae - I mean there you have parallel data power and ground conductors running the whole string length. And I’m running upwards of 350 px per channel.
Here’s a pic of the randomized mess. Not sure what channel, but it sure looks like I could tune something in with it -
This second pic more clearly shows where I Twisted the conductors together somewhat for strength and handling improvement (perhaps antenna suppression) … but I found the twisting behavior to be unpredictable and risked breakage of the string
Three more brief observations, I think pertinent to the apparent static and grounding issues/weird behavior/LED death -
Neutral and hot turned out to be reversed at the outlet in my vintage 60s shop. Now fixed. I do not know if this would have an effect. ?
I did not run ground back to source ground at the power supplies. Is this a thing?
All this nonsense was more or less coincident with the death of the nominally OpenGL-capable NVIDIA card in the operative laptop. This followed shortly by the laptop’s complete crash. So, weird behavior not necessarily having anything to do with our friend the Pixelblaze! But grounding and polarity contributing… perhaps.
