These are chat archives for Makuna/NeoPixelBus

20th
May 2018
kopierschnitte
@kopierschnitte
May 20 2018 05:36 UTC
Hi! Can anyone tell me, why my 160 LEDs SK6812 Strip (RGBW; connected to an ESP8266 using DMA mode) is showing random colors every 10-20 minutes, even if it should be completely "black"?
Michael Miller
@Makuna
May 20 2018 06:35 UTC
Are you using the UART at all? Do you have it connected to a PC for power? The RX pin for the normal Arduino connection is the same pin.
r1dd1ck
@r1dd1ck
May 20 2018 13:03 UTC
@kopierschnitte could be interference or static build-up on the data line (how long is it, and is it twisted-pair with gnd?) , or something fishy going on in your code which causes unexpected output on the data pin (crash/reboot, buffer overflow, etc.)
kopierschnitte
@kopierschnitte
May 20 2018 13:18 UTC
Yes, I'm using the UART pin (RX on my NodeMCU). The data line (I'm using a loudspeaker cable for 5v, GND and data) is roughly 2 meters away. It's not twisted yet but the ESP8266 shares the same GND with the strip. I also did not include a resistor or capacitor anywhere yet.
The code doesn't do anything at this time. I can ping the device constantly (yes, I'm using Wifi). The strange thing is, if I just issue a strip.show() command, the LEDs remain lit. But if I first set every pixel black, it will turn off... Could it be a memory corruption?
r1dd1ck
@r1dd1ck
May 20 2018 13:39 UTC
@Makuna
the latest commit on espressif/esp-idf#517 looking fairly good already, have you checked it?
Tested it on Arduino IDE (including output/timing analysis) and so far found no apparent issues. Can provide latest binaries+headers (libdriver) from IDF master (with cherrypicked RMT commit) - if you want. I have made a couple of suggestions in the corresponding issue thread which I think could help with library implementation, but seeing how long it took them to get at least to this point, it's rather hard to guess if/when those suggestions even get considered :-D
r1dd1ck
@r1dd1ck
May 20 2018 13:59 UTC
@kopierschnitte Hard to tell, really. Depends on alot of factors, and also on what exactly you do in your code. I have not noticed such behaviour yet, and can back it with thousands of hours running time, so a fault on your side (either electrical or in code) is more probable. As a temporary solution I would suggest to set up a timer and have it periodically mark the strip "dirty" + call show(), so when strip corruption occurs, it gets overwritten immediately. If this does not help, then it could mean that the memory holding the pixel data itself somehow got corrupted, and needs to be re-written first.
kopierschnitte
@kopierschnitte
May 20 2018 16:29 UTC
Thanks for this suggestion. As I'm just an excited beginner, it's good to know that you haven't seen something like this before. I'll check the setup and the code and will see what happens...
Michael Miller
@Makuna
May 20 2018 17:32 UTC
@kopierschnitte Just calling show() won't do anything unless you called something changed a pixel, like clearto or setpixelcolor. As r1ddick stated, you have to call dirty then show.
You mentioned you are using the RX, do you mean you are using for the NeoPixels or that you are using it for something else? If you are using the normal method, then of course your neopixels MUST be on the RX pin as its the only pin supported. If you are using it to be connected to something, and they send you data, it can effect the neopixels.
If you aren't actively "updating" the pixels and they are changing colors, the resistor may help but the cap not being used wouldn't be the problem. Either your code (bug) or something else (noise, external source) is causing the problem.
@r1dd1ck I noticed the update, I just haven't had the time to do a deep dive with the changes yet.
I have been working with them on another solution using the i2s (like my esp8266 method) that is working really well; but I can't publish until they give me the go ahead. The esp32 is nice in that the hardware support doesn't limit the pin use like the esp8266 does!
r1dd1ck
@r1dd1ck
May 20 2018 19:37 UTC

@Makuna :+1:
Yes I was wondering myself why no I2S-based LED driver surfaced yet for the ESP32 as I know the hardware is there and quite capable. Just not sure whether it is worth the trouble now that there is a fully functional RMT approach with native 8-channel parallel output (routable to almost any GPIO) available. Or well, as soon™ as the changes get pushed to master & crawl into the Arduino-ESP32 package :smile:

@kopierschnitte
Don't understand me wrong - I've seen pixel corruption happening. Just not in cases where the power/data & code parts were done properly, and the hardware was not faulty. That however does not rule out freak-cases where for example some strange packet exposes a hidden bug in the WiFi driver & causes memory corruption, but I deem that rather less likely.

kopierschnitte
@kopierschnitte
May 20 2018 20:54 UTC
@Makuna No, I'm using the RX0 pin exclusively for the stripe. Maybe there's a problem with other parts of the code. I'll check this. From time to time I'm also completely unable to change or power off the last part of my strip (LED 100-158). @r1dd1ck I really hope it's not a hardware fault. For the moment, I'll randomly read out the pixel buffer, just to make sure it isn't corrupted at the time, this effect occurs. That would be an explaination...
r1dd1ck
@r1dd1ck
May 20 2018 21:06 UTC
@kopierschnitte Umm, at how many places do you inject power to the strip? With 160 pixels, I hope it is not just at the beginning. It would not explain the erratic idle/black corruption, but is certainly worth a consideration if the strip is acting weird past some length, like you describe.
Ash
@ashthespy
May 20 2018 21:30 UTC
Quick question -- what the 'best practice' when using the Rx pin with the esp8266 to avoid the strip blinking away while flashing firmware?