Requesting a sanity check on issues with 4536 "NeoPixel Mini

EL Wire/Tape/Panels, LEDs, pixels and strips, LCDs and TFTs, etc products from Adafruit

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Requesting a sanity check on issues with 4536 "NeoPixel Mini

Post by fasteddy516 »

I've been having a brutal time trying to figure out some crazy flickering issues on some custom control panels I'm building using NeoPixel Mini Button PCBs, and am hoping someone can sanity-check my findings. I apologize for the lengthy post, but I wanted to make sure I provided all of the relevant details about the circuit, code, issue and test procedure up front. Feel free to assume I've tested thoroughly and skip to the "Sanity Check Please!" section waaaay below, which is where the interesting bit is!

Boring Details (This is the part you can skip!)

The circuit I have been testing with is shown below:
test_circuit.jpg
test_circuit.jpg (188.52 KiB) Viewed 547 times
I believe I've followed all of the best practices - 1000uF cap across the power supply which is regulated 5V/2.5A, 74AHCT125 for level shifting, and a 470ohm resistor in series with the data line (though I'm not entirely sure that's necessary after going through the level shifter). I've disabled the unused buffers on the 74AHCT125 with 47k pullups on the active-low enable inputs, which also may not be necessary but doesn't hurt. For testing, I've been using the string of 8 NeoPixels shown in the diagram, which are driven by digital pin 7 on a Metro M4 Grand Central. Everything is powered by the same, single 5V/2.5A supply, so the Grand Central and NeoPixels most definitely have a common ground.

As far as code goes, I'm currently using CircuitPython 6.3.0, using the stock demo code straight from the NeoPixel UberGuide (it displays each color for 1 sec, then does the rainbow dance, then it all repeats), but I've added the following to the end:

Code: Select all

    for _ in range(10):
        rainbow_cycle(0)

    ranges = ((0, 256, 1), (255, -1, -1))
    for start, stop, step in ranges:
        for i in range(start, stop, step):
            pixels.fill((i, i, i))
            pixels.show()
That makes the "rainbow dance" last much longer, then follows it with a fade up to full white (all three LEDs at equal intensities), then back down to black, and it's in this section where things go sideways.

When the code runs, the flashes of solid color work perfectly and look great, as does the rainbow dance. No flickers, no artifacts, no issues at all - it looks fantastic! But then the fade up to white starts, and the LEDs start flickering like crazy throughout the entire fading process. I've double- and triple-checked the wiring and soldering, made a second chain of 8 LEDs to test with, tried running without the "best practice" pieces (no big cap, no level shifter, no data line resistor), and even switched to a 5V Arduino Uno using the fastled library in C, and it always behaves exactly the same way - everything works great until the fade at the end. I cut an 8 pixel section off of a 60 LED/meter (Product 1461) strip, and hooked it up in place of the original chain, and everything worked perfectly, including the fade. I connected an 8x8 NeoPixel Grid (Product 1487), and the first 8 pixels worked perfectly as well.

In trying to figure out the difference between the NeoPixel arrangements that worked and the one that didn't, I noticed that all of the various NeoPixel formats have a 0.1uF decoupling capacitor per pixel, and the 8x8 matrix has a single series resistor on the data line, but *only* the individual pixel boards had a 75ohm resistor per pixel. I assumed this resistor was on the DIN on each pixel, which makes sense. On closer inspection, it appeared to be in series between the 5V input pad and Vdd on the NeoPixel, which makes significantly less sense to my limited understanding of DC circuits.


Sanity Check Please (This is the part you should read!)
I sacrificed a single NeoPixel board by removing all of the components in order to meter out the pads/connections and verify the odd location of the resistor. (I couldn't find a schematic for this particular part anywhere, but could very well have just missed it.) I have tested, re-tested and confirmed the connections shown below in the left scribble, which I believe translates to the circuit shown in the right scribble:
pencil_sketch.jpg
pencil_sketch.jpg (154.34 KiB) Viewed 547 times
I cannot for the life of me figure out why that 75ohm resistor would be located where it is. I took some voltage measurements and found:
- When an LED is powered but dimmed to full off, I get 5.247V at the "5V" input pad and 5.192V at Vdd.
- With an LED powered and at full brightness, I get 5.171V at the "5V" input pad and 3.119V at Vdd. That doesn't seem right.

So I did some precision destruction, removed the 75ohm resistor from 8 pixel boards, replaced it with a solder bridge, and tried it out. It works perfectly. No issues whatsoever. More voltage measurements got me exactly what I expected:
- When an LED is powered but dimmed to full off, I get 5.247V at the "5V" input pad and 5.247V at Vdd.
- With an LED powered and at full brightness, I get 5.158V at the "5V" input pad and 5.158V at Vdd.

With a bit more testing (on unmodified pixel boards), I found that the flickering only seems to be an issue during particular types of lighting, most notably when doing rapid fades in fine increments that involve all three colors. A crossfade from (255, 0 ,0) to (0, 255, 0) to (0, 0, 255) works perfectly fine, but crossfading from (255, 255, 0) to (0, 255, 255) is all kinds of flickery.

So at this point I'm trying to decide if I'm crazy or not. I can't possibly be the first one to run into this if there really is an errant resistor on these boards, but I can't think of any reason why it would be where it is. Either way, removing it from the equation most definitely makes the problem go away, and creates a circuit that matches what I see on the strip and matrix NeoPixel form factors. I'm hoping someone more knowledgeable than I can possibly provide some insight as to what's going on here.

If you made it this far, I truly appreciate that you took the time to read through my ramblings!

Best regards,

Edward

User avatar
blnkjns
 
Posts: 963
Joined: Fri Oct 02, 2020 3:33 am

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by blnkjns »

What happens if you run the Arduino Neopixel test file on it?

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

I didn't use the default 'standtest' example because it uses a bunch of intentionally flickery effects, which makes it less than ideal for troubleshooting flicker issues. However, since you asked, I gave it a shot.

Running 'strandtest' from the Arduino NeoPixel library with no modifications whatsoever looks ok for everything *except* the White theatre chase effect, which appears more like a pastel rainbow chase. 'standtest' uses some pretty conservative brightness levels, though, so I ran it again after changing all the 127s in the theatreChase() line to 255s, and also changed the setBrightness level in the setup() section to 255. With the brightness cranked up, the white theatreChase() is completely screwy (half of the pixels don't even light up), and there are occasional glitches in the final theatreChaseRainbow(). This makes sense to me, because higher brightness = higher current draw = trying to pull more current through that 75ohm resistor whose purpose eludes me.

Again, when I switch the chain of stock neopixels out with my chain of 8 modified pixel boards, everything works fine. Everything also works fine on the other strip and the neopixel matrix that I mentioned testing with in the first post.

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

For clarification, the product I'm having issues with is 4356 (https://www.adafruit.com/product/4356, not 4536 as it says in the title. Wish I'd caught that before the editing time limit expired.

Also as an update, I've looked though the schematics shown at the end of the NeoPixel Uber Guide, and the only other design I could see that has a resistor for anything other than the data line is on the "Breadboard-Friendly Neopixel Breakout", but that one uses an older WS2811 with a separate Vdd for logic (which has a resistor on it), and LEDVdd for actually powering the LEDs (which does *not* have a resistor on it.)

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by adafruit_support_mike »

Measure the resistor value.

NeoPixels use up to 60mA, and that much current through a 75 Ohm resistor would cause a 4.5V drop. A single LED would draw about 20mA, which is enough for a 1.5V drop.

I don't have a schematic for those on hand, but I'll look for one.

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

The resistor is definitely 75 ohms - the SMT resistor code printed on it is 750, and I metered it to verify. With brightness set to max (1.0) in the neopixel.NeoPixel(...) line of code, I get the following measurements for red (255,0,0), green (0,255,0), blue (0,0,255) and white (255,255,255):

(PAD = 5V input pad on the back of the mini PCB, VDD = straight off of the VDD pin on the NeoPixel.)

R: 0.0121A / PAD=5.2604V / VDD=4.3312V
G: 0.0121A / PAD=5.2604V / VDD=4.3319V
B: 0.0121A / PAD=5.2604V / VDD=4.3362V
W: 0.0285A / PAD=5.2562V / VDD=3.0972V

At full brightness (and ignoring momentary peak currents that my meter won't even register), these NeoPixels are only drawing around 28.5mA at full brightness. Running that through the 75ohm resistor should get around a 2.14V drop, which lines up with the measurements taken.

I ran the same tests on one of my modified pixel boards (with solder bridge in place of resistor) and got the following:

R: 0.0141A / PAD=5.2604V / VDD=5.2604V
G: 0.0134A / PAD=5.2604V / VDD=5.2604V
B: 0.0133A / PAD=5.2604V / VDD=5.2604V
W: 0.0389A / PAD=5.2537V / VDD=5.2537V

Again, I have no idea what purpose this resistor is supposed to be serving. With it in place, logic and a basic (but possibly flawed) understanding of electronics tells me that the more current we pull through that resistor to power the NeoPixel, the lower the voltage left over at Vdd will be. I assume that whatever the NeoPixel spits out of its Dout pin can't have a voltage any higher than what it's getting at Vdd, which means as brightness (and current draw) increase, that signal on Dout gets closer to the "70% of Vdd" threshold where the next pixel in line won't be able to interpret it properly. That 3.0972V is definitely under the 70% mark. That would explain the flickering I'm seeing, as well as my observation that the flickering only comes up when all three LEDs are active and there is a lot of traffic on the data line.

Does any of that logic hold up in your estimation?

User avatar
adafruit2
 
Posts: 22144
Joined: Fri Mar 11, 2005 7:36 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by adafruit2 »

hi, can you post a photo showing clealry where the 75 ohm resistor is located?

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

Here is a closeup shot of one of the NeoPixels in the same orientation as the "pencil sketches" from my original post. 75ohm resistor is on the right side of the picture, 0.1uF capacitor is on the left.
neopixel_closeup.jpg
neopixel_closeup.jpg (516.29 KiB) Viewed 446 times

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

I got a bit carried away with the sandpaper, but here are the exposed traces on the PCB that confirm the connections on my pencil sketch:
neopixel_traces.jpg
neopixel_traces.jpg (344.06 KiB) Viewed 427 times
And here it is with the populated circuit overlaid on top:
trace_overlay.jpg
trace_overlay.jpg (232.93 KiB) Viewed 427 times
For what it's worth, all three sets of 50 pixels that I have came in baggies that say C14001-001 P4356A, and are dated 2019-08-22.

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

I'm not sure if anyone has been able to look into this on your end, but in the meantime I grabbed some oscilloscope traces comparing Din and Dout while running the following CircuitPython code:

Code: Select all

import board
import neopixel

pixels = neopixel.NeoPixel(board.D7, 2, brightness=1.0, auto_write=False, pixel_order=neopixel.GRB)
pixels.fill((255, 255, 255))

while True:
    pixels.show()  # near constant data stream to give the scope something easy to measure
The following traces show Din on channel 1 (blue) and Dout on channel 2 (red). The top trace is with the 75ohm resistor in place, and the bottom trace is with a solder bridge in place of the resistor:
neopixel_with_resistor.png
neopixel_with_resistor.png (5.18 KiB) Viewed 246 times
neopixel_without_resistor.png
neopixel_without_resistor.png (5.21 KiB) Viewed 246 times
At this point I have disassembled my control panels, modified 69 LEDs to replace the 75ohm resistor with a solder bridge, and put it all back together. It was tricky business, given that all of the LEDs were hot-glued in place, and trying to undo that without damaging them (or the 3D-printed parts they were mounted in) was a slow and careful process. With all of the resistors replaced, everything is now working perfectly.

I would still very much appreciate hearing back regarding this issue. I've got another 80 of these LED boards that eventually need to be installed in other projects, and I would like to know if that resistor is an oops, or if it serves some purpose beyond my understanding. I would hate to see anyone else put in the time required to solder a bunch of these together (69 boards = over 400 surface-pad-to-wire solder connections, and that's not counting the resistor modification!) only to find that they don't work reliably under certain standard operating conditions.

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by adafruit_support_mike »

Get traces of the voltage at the VCC pad while the pixel is showing the following colors please:

(255, 0, 0)
(0, 255, 0)
(255, 255, 0)
(128, 128, 128)

The DIN-to-DOUT difference is odd, but the data signals use almost no current. I'd like to see what effect the LEDs have on the supply pin.

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

Requested traces are below. Channel 1 (blue) is on the 5V input pad, channel 2 (red) is directly on the Vdd pin on the neopixel.
5V vs Vdd for (255, 0, 0)
5V vs Vdd for (255, 0, 0)
neopixel_255-0-0.png (5.25 KiB) Viewed 236 times
5V vs Vdd for (255, 255, 0)
5V vs Vdd for (255, 255, 0)
neopixel_255-255-0.png (5.15 KiB) Viewed 236 times
5V vs Vdd for (128, 128, 128)
5V vs Vdd for (128, 128, 128)
neopixel_128-128-128.png (5.69 KiB) Viewed 236 times
I didn't attach the (0, 255, 0) trace as it put me over the "3 attachments per post" limit, and was virtually identical to the (255,0,0) trace anyway.

Things get a bit spicy with the (128, 128, 128) trace, presumably because of the PWM dimming coming into play. I believe the WS2812B PWM is somewhere around 400khz, but an SK6812 is in the 1khz range, which fits the bill here, and the ~50% duty cycle lines up with our (128, 128, 128). Once again, the more current we try to pull through the mystery resistor, the lower the voltage left over at Vdd.

I think the Din-Dout difference from my previously posted traces makes perfect sense here, as the internal "signal reshaping circuit" mentioned in the WS2812B/SK6812 datasheets will be capped at whatever the pixel is receiving at Vdd.

For what it's worth, I did all of the same measurements with one of my resistor-free modified boards, and didn't get any traces worth posting, as they're all just two lines right on top of each other - no difference between 5V pad and Vdd, which is what I would expect.

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by adafruit_support_mike »

Yeah, the last set of traces probably show the effects of aliasing.. sampling a fast repeating sequence at a rate slower than the sequence itself. It's the same thing that makes wheels seem to rotate backwards in old movies.

It definitely looks like there's a significant voltage drop. I'll need to talk to the folks on the product team about it.

User avatar
fasteddy516
 
Posts: 19
Joined: Wed Apr 12, 2017 10:38 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by fasteddy516 »

That would be awesome, thank you!

I'm confused about the aliasing bit, though. I'm using a 100MHz, 1GS/s oscilloscope, and didn't think I was measuring anything with a high enough frequency for aliasing to be a concern.

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: Requesting a sanity check on issues with 4536 "NeoPixel

Post by adafruit_support_mike »

Ah.. that's my mistake. I read the '1.00ms' timebase as 'one millisecond', and didn't pay attention to the frequency count below it.

If that's a one microsecond timebase, yeah, that look like solid evidence of a voltage drop when the LEDs get current. To really nail it down, try (64,64,64) and (192,192,192).. those should have 25% and 75% duty cycles at the same frequency.

This is obviously related to the hardware as it comes out of the bag though, and the testing you've done is valuable to us. Send a note containing a link to this page and your order number to [email protected]. The folks there will refund the cost of the pixel/buttons you have.

Locked
Please be positive and constructive with your questions and comments.

Return to “Glowy things (LCD, LED, TFT, EL) purchased at Adafruit”