WS2812 and EMC

[artag]

Has anyone here used WS2812 or similar LEDs in a product that needed to conform to EMC standards ?
There's bot a long wire with a 800kHz data ilne and a bunch of PWM'd LEDs.
They're probably a nightmare to suppress. Has anyone tried ?

[srlevitt]

I'm having similar woes. See https://electronics.stackexchange.com/questions/660535/radiated-emissions-from-ws2812-leds
Did you get anywhere?

[artag]

Due to production needs my led array is now 13 strings of 11 leds instead of one string of 140 leds. This is unlikely to help the EMC situation but I'm only now starting to make measurements. Unfortunately although I have measurement equipment I don't yet have a calibrated baseline from a test lab.

I read your piece on stackexchange with interest. As I understood it one guy had built a system with no problems but the leds are in an aluminium envelope with holes around each led. I can't afford that, though some sort of aluminium foil housing might be an option. The mechanical designer's face when I ask her to replace a painfully developed plastics superstructure with tinfoil will be a picture thought it might actually be quite good.

[langwadt]

you can probably vary the 800kHz to spread it out if that helps

[SiliconWizard]

you can probably vary the 800kHz to spread it out if that helps

Yes. The datasheet gives a rather wide tolerance on timings (each low/high state +/-150ns), so at least according to the DS, you should have +/-300ns max over one period (1.25µs), which is +/-24%. That's quite a span for spread spectrum.
Of course, that will complicate the code a little bit.

[langwadt]

you can probably vary the 800kHz to spread it out if that helps

Yes. The datasheet gives a rather wide tolerance on timings (each low/high state +/-150ns), so at least according to the DS, you should have +/-300ns max over one period (1.25µs), which is +/-24%. That's quite a span for spread spectrum.
Of course, that will complicate the code a little bit.

at what timespan does the spreading need to happen? maybe just change the frequency slightly every reset period?

[T3sl4co1l]

Filtering on any signal outputs, and probably ESD protection, is an absolute minimum.  An MCU pin toggling regularly has harmonics up into the 100s of MHz.  An LC lowpass made from a ferrite bead (30 to 1000 ohms at 100MHz, depending), and a C0G say 100 to 1000pF, is a good start.  Clamp diodes for ESD are also a good idea.

Just ferrite beads might well address the linked question, or at least afford considerable reduction.

If the LEDs themselves produce noise (what are they, PWM once set? I forget), there's not much you can do about that.  Preferably they would be made on a two-layer strip (one side ground plane), with frequent supply bypass capacitors, but if they're just parallel traces on a single layer, you're a bit screwed, short of a mesh screen over the whole damn thing.

Tim

[spostma]

Add a resistor so the output impedance is at lease equal to the line impedance,
thus making a series termination like the PCI bus used to do.

Generally, try to minimize writing to the WS2812 strings, as they keep the last-writen RGB PWM value.
They all run on their own local free-running 5.25MHz oscillator, so they tend to become spread-spectrum alltogether.

[DavidAlfa]

Exactly, each led actively relays the input to the output, but not instantly, so you don't really have 10ft antenna radiating the same signal, only the traces going between leds.

[artag]

My cable is FFC and fairly short as are the LED strips - all within the same container. However it needs to be translucent so shielding is awkward.

What I'd really like to find is a set of voltage-converting buffers that have slew rate limiting on them. However that's more the area of line drivers than bus buffers, and rarely more than one or two per package.

[langwadt]

My cable is FFC and fairly short as are the LED strips - all within the same container. However it needs to be translucent so shielding is awkward.

What I'd really like to find is a set of voltage-converting buffers that have slew rate limiting on them. However that's more the area of line drivers than bus buffers, and rarely more than one or two per package.

just add a series resistor, but that only affect the signal to the first LED, each LED will driver the next in the strip

[SiliconWizard]

I can't give any particular guarantee, as there are tons of compatible WS28xx LEDs on the market and who knows which you'll get and whether they actually match the datasheet (which is not that obvious to find curiously).

But according to the DS I have, looking at the switching characteristics, I think you're probably overthinking the digital data signal EMC issue. Each has a buffer to forward the data line that is relatively slow. They're meant to be mounted each close to one another rather than very distant (even if the total strip length can be long), so they don't need beefy buffers. (So OTOH, don't expect these LEDs to work very well without extra buffering if you had several meters of cable between each.)

If you have gathered evidence that the digital signals themselves could cause EMC issues, you would have to add a series resistor... between each LED. Annoying.

Now what may be more concerning is the noise coming from the power rail. The DS is not particularly explicit about what the controller does. It states that it uses contant current driving, so we can assume they're at least not PWM'ing. But who knows. How much can you again trust those datasheets since you may get ahold of compatible LEDs that are not "genuine" (the original vendor making these is Worldsemi), but I wouldn't be surprised if they had been endlessly cloned with varying characteristics.

But even if the LEDs are not PWMing, obviously the current draw from the power rail will vary with the RGB control pattern of the LEDs, so beware of your own power supply first. That's what I would personally focus my concerns on.

[artag]

I think they do PWM. All the ones I've ever used have the characteristic dot pattern if you move them whilst partially illuminated. The normal strips you buy have 100-180nF on each LED but additional bulk capacitance is often recommended, apparently because it reduces failure rate - possibly due to the data signals being greater than the sagging power lines.

[Northy]

Are you actually using the flexible tape or are these on your own PCB?

I got a product through that had a few hundred on flexible tape, I thought they would be an issues, but didn't seem to be. The product had HDMI in it and that was a total PITA.

I've also used 14 or so of the side firing type on another design in the past on my own PCB. I added an R/C between each one, just incase there was any problem at EMC. I'm not sure if that ever made it to testing....

We also got custom tape made that was easier to bend round corners and had a 'data return' the full length of the tape at one point, it actually wasn't that much extra than the off the shelf stuff. So if you do struggle, you could have something similar made with an R/C between, or more decoupling, or whatever was needed?

G

[cziter15]

Hello, I just created an account to respond because I encountered the exact same issue.

The problem occurred while I was using a 1-meter LED strip controlled by an ESP8266 (ESP-12E) and scanning the ~200MHz region with an RTL-SDR. I noticed a pattern that resembled a woodpecker signal (DUGA like ).

I was particularly surprised to see how short the WS2812 signal pulses were:
T0H around 0.4µs and T1H around 0.8µs, resulting in approximately 1.25µs per bit.

Initially, I was able to replicate the issue by simply connecting a wire from the 'breadboard set' to the DOUT pin on the PCB I had designed. Since I forgot to add a level shifter and was driving the strip directly, I experimented with various resistor values to get the strip working. I even tried a 4.7k resistor between the pin and DOUT, but it didn't help much. Likely due to some parasitic effects, it still emitted RF. I also added a 47k pullup resistor between 5V and DOUT to raise the signal and drive the strip properly. It started to work, but there was no improvement from RF point of view.

Next, I tried different capacitors between GND and DOUT. Currently, I have a 220-ohm resistor in series, a 1k pullup resistor on the data line to 5V, and a 470pF capacitor between the data line and ground. With this setup, there are no emissions with a straight wire connected to the DOUT.

Unfortunately, the problem reappeared when I connected the LED strip. It seems that the strip itself is radiating. After doing more research, I learned that there are different types of flex-PCBs used in these strips. Single-layer laminates tend to radiate much more because they effectively create antennas — one per LED! The signal regeneration at each LED has a slightly different radiation pattern adding another harmonics into the mix, spreading the noise effectively thgough VHF range.

SUMMARY

• When purchasing a WS2812 strip, opt for one with a solid ground plane.
• Leave some place for a DOUT low-pass filter on your PCB (a resistor in series on the data line and a shunt capacitor to ground).
• Since WS2812 regenerates the signal, apply the same design considerations for each individual LED, especially if there is no continuous ground plane.
• Perform differential tests (or, in general — identify the source of RF emissions).

[artag]

Thanks for the extra info, especially that note about strips with a better ground layout.

Something else I'll add - if you need level shifters, DON'T use TXB0104 devices. They're quite convenient to use with 4 per pack and pretty cheap but have hideous characteristics due to their bidirectional feature (not needed here). If driving even quite short lines with data on adjacent strips, they'll cross-couple and an edge on one line will create a bit-flipping edge on adjacent lines. Very difficult to stop even with series resistors, intervening shields etc.

[cziter15]

It's also a good idea to make the timing of individual signal bits distinct to avoid stronger harmonics.
Since the receiving side has some timing tolerance, we can exploit that fact.

Here's how I modified the NeoPixel library to make the period time for each signal bit different from the next.

[DavidAlfa]

If you don't get it sorted with spectrum spreading, there're clear EMI shielding films, did you check them out?
Though completely covering the strips in isolating plastic might cause overheating issues. Maybe you can find them with perforated patterns, or make your own.

A very thin metallic mesh will barely affect cooling and light output, so it's another possibility.
Or, measure the led spacing and get a thin metal tape laser-cutted so only the leds protrude, shielding everything else.
EMI certification is a real PITA!

Normally digital circuits become slower at lower VDD (Reduced slew rate), so another possibility is to try reducing VDD just for the transmission, i.e. lowering to 3.3V 1ms before starting the transfer.
This would only be possible for static pictures or very low framerates, and I have no idea if this will work at all, or cause massive glitches and/or terrible visual artifacts.
But I would try just for knowing!

[T3sl4co1l]

More subtle version of that: you could put down metal (Cu, Al) tape, then tape the LED strip onto that. Reduces the trace loop area at least.

Ideally the tape would be periodically bonded to the electrical ground inside the strip, making it basically a bad two-layer ground-plane design.

After that, mesh on top would be the best, yeah (wrap around and bonded to the shield foil).

Tim

[Geoff-AU]

I'm having similar woes. See https://electronics.stackexchange.com/questions/660535/radiated-emissions-from-ws2812-leds
Did you get anywhere?

Looking at that plot, the 40-50MHz area is easy to count peaks.  I'm seeing 13 peaks (counted the missing one too) in a 10MHz span, which works out at one peak approximately every 0.77 MHz.  Since the WS2812 protocol runs at 800Kbps, your EMC plot strongly suggests it's seeing radiated emissions from the data line.