Crosstalk when pwm dimming is on

93 views
Skip to first unread message

newxito

unread,
Aug 13, 2026, 11:52:48 AM (7 days ago) Aug 13
to neonixie-l
Just wanted to check with "humans" if that all makes sense before I start with the modifications :-)

The problem: since I implemented nixie dimming (pwm 20kHz using the blank line), I'm having flickering leds which should be off on a device with a 30cm (1 foot) long cable between controller and leds. The device has 16 nixies and 16 leds. No problems with devices with shorter cables and no problems without dimming.

I asked claude and here is the answer:

- Slow the noise source: add a small RC snubber (resistor + small cap, e.g. 100Ω + 1nF) right at the transistor driving the blank line — this rounds off the switching edge so it radiates far less into the neighboring wire, without touching cable routing.

- Harden the receiver: add a pull-down resistor (1k–4.7k) directly at the first WS2812's data input — WS2812 idles low, so a pull-down resists noise trying to pull the line high between real transmissions. Small part at the display end, not a full rewire.

- Use a shielded cable. A few things that matter for it to actually work well in your setup:
Use the shield as a return path too: run the data line and its ground return twisted together inside the shield (shielded twisted pair), not just the data wire alone with ground elsewhere in the bundle. That also shrinks the loop area, cutting magnetic coupling, not just electric-field coupling.
Ground the shield at one end only — controller side. Grounding both ends risks a ground loop between controller and display that can inject the very HV switching noise you're trying to keep out, especially since the blank-line noise source and the data line will share a common ground reference over that cable run.
It won't fully eliminate coupling if the shield's return is poor or floating, so keep the pull-down resistor and 100nF caps in place as a backstop.
Since it's a single wire replacement inside the existing tube rather than a full harness rework, this is one of the more practical hardware options given your routing constraint. Worth trying before or alongside the pull-down resistor.

gregebert

unread,
Aug 13, 2026, 1:06:40 PM (7 days ago) Aug 13
to neonixie-l

I'm suspecting noise is causing false clocking. When there are no problems with a shorter cable, it points to a problem with coupling or ringing.

If you have a scope, start probing around for noise. The blanking line will cause a lot of electrical noise because it's switching loads on-and-off; the signal itself isn't nearly as noisy. My guess is that false clocks are getting generated into your LED modules.

David Pye

unread,
Aug 13, 2026, 3:00:23 PM (6 days ago) Aug 13
to neoni...@googlegroups.com
One other thing - what voltage are you driving the neopixels with? 5v or 3v3? 

Driving them at 3v3 can lead to unpredictable behaviour especially in noisy environments.

David

--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/neonixie-l/016bd55f-025d-4852-a5f2-85167942e8c5n%40googlegroups.com.

Martin Černý

unread,
Aug 13, 2026, 3:25:05 PM (6 days ago) Aug 13
to neonixie-l
More information is needed. Schematic is the absolute minimum. What power supply, what HV supply, what is used for dimming. Otherwise we can only give you the same answers as AI which are mostly trash.

Dne čtvrtek 13. srpna 2026 v 17:52:48 UTC+2 uživatel newxito napsal:

newxito

unread,
Aug 14, 2026, 3:00:48 AM (6 days ago) Aug 14
to neonixie-l
I'm using a level shifter to drive the data line at 5V. 

newxito

unread,
Aug 14, 2026, 3:05:22 AM (6 days ago) Aug 14
to neonixie-l
You can find the schematics here: https://github.com/axtar/Nixie-Calculator/tree/main/Schematics
Having the problem with the IN-12 version.
Dimming is done with PWM at 20kHz on the blank line.

Martin Černý

unread,
Aug 14, 2026, 9:40:27 AM (6 days ago) Aug 14
to neonixie-l
You have the led level converter output disconnected and instead you drive the leds with 3.3V directly from the ESP32. I don't know what library you're using to control the addressable leds but Neopixelbus supports inverted logic. So you can use a fet, a 1k pullup resistor as a uni-directional level converter.
Screenshot 2026-08-14 151821.png

Dne pátek 14. srpna 2026 v 9:05:22 UTC+2 uživatel newxito napsal:

Dekatron42

unread,
Aug 14, 2026, 9:47:45 AM (6 days ago) Aug 14
to neonixie-l
I tinkered with the WS2812/B some years back and found that using a level shifter with the BSS138 didn't work properly, I had to change to TTL-ic's.


/Martin

newxito

unread,
Aug 14, 2026, 9:55:14 AM (6 days ago) Aug 14
to neonixie-l
Sorry about that, the schematic is inconsistent...
These are separate boards. LEDCTL5V connects via cable from the controller board to LEDCTL of the LED board. 

newxito

unread,
Aug 14, 2026, 10:05:27 AM (6 days ago) Aug 14
to neonixie-l
Many thanks for the information and the link... i will try changing the firmware to NEO_KHZ400 first.

Martin Černý

unread,
Aug 14, 2026, 10:07:41 AM (6 days ago) Aug 14
to neonixie-l
you can try to replace the pullup resistors with 1k, it could speed up the edges.

Dne pátek 14. srpna 2026 v 16:05:27 UTC+2 uživatel newxito napsal:

gregebert

unread,
Aug 14, 2026, 10:44:30 AM (6 days ago) Aug 14
to neonixie-l
All of my projects over the past several years use a custom serial interface (10-conductor ribbon cable I call IOLINK), and I bring the end of the chain back so I can have software (or hardware, if I'm running the interface faster with an FPGA) run diagnostics.

Making sure the chain is intact proves-out the most UNreliable part of the design --- wiring errors and bad connections. It also allows software to autoconfig your design by measuring the length of the chain in terms of the number of bits, and I also have software adjust timing to make sure there is adequate margin. You would be surprised how many obscure software and hardware bugs I have found chasing-down every last bit error. No, I'm not talking about the easy ones where there is an error every few bits; there should be zero errors even after billions of bits and they can take months to find.

Reply all
Reply to author
Forward
0 new messages