SDK • Re: Problem with WS2812_Parallel example past 7 rows

I think you misunderstood me about my power distribution plans.
The strips will be powered by a dedicated power feed. Not a dedicated PS, but rather 6 18Ga pairs about 10ft (3m) each from the 40A supply to the display.
I originally planned to power the Pico (and 74HCT245) back from the display but I could instead power it directly from the 40A PS. Current around the data wires would be minimal since the Pico and HCT draws perhaps 100mA, mostly dependent on the what it is doing with the WiFi.

Yes, but if you run wires from the PSU to the Pico you've now got a triangle of ground wires: from PSU to display, from PSU to Pico (for power purposes) and from Pico to display (for data return purposes).

You hope that most of the DC return current from the display will go down the 18Ga wires direct to the PSU - and probably it will, due to the lower resistance. But if you get a momentary break in one of those cables (easily done while setting up) then that return current will instead flow down the data cable ground, through the Pico, and back through the Pico's supply wiring. That might not matter, depending on the details of how you've done the wiring at the Pico, but the other arrangement means you don't need to think about it.

I already figured out the data input to the strips is of rather high impedance since if:

• I don't drive channels but have them connected to the corresponding lead in the 10ft (3m) cable, it picks up data from one of the driven channels.
  If I don't connect a strip to the cable, I can get a response if I bridge the strip's input with my finger to a driven strip.

That's why I was thinking even 1K resistor from strip input to ground might be helpful. Challenging to retro-fit into my current wiring harness but doable if it would help.

When connected properly, the cable presents much less than 1K. So if you are concerned about external influences, then the cable is going to have much more effect than your 1K; conversely, if you are concerned about pickup on the cable itself, then the 1K isn't going to be strong enough to tame it. The one merit of your 1K would be to stop things going crazy if the cable gets broken/disconnected - which might be a good enough reason if they were easy to fit, but since you say it's challenging then I wouldn't bother.

While scoping the disconnected but finger-bridged strip input, it seemed to respond with pulses as low as 2v, which is much lower than many have said it should when debating about direct driving from 3.3v controllers.

There's a big gap between what is guaranteed to work and what is guaranteed to not work. Datasheet just says 0.3*Vdd (1.5V)for logic zero and 0.7*Vdd (3.5V) for logic 1, leaving everything from 1.5V to 3.5V undefined.

So I'd expect a simple connection direct to the Pico at 3.3V would probably work most of the time - with a short cable, without considering change in temperature, dips in the supply voltage etc. But it wouldn't be reliable.

If you read the beginning of this thread, you may have noted that I had problems even before I introduced the 10ft (3m) cable that the 330R in series with the data seemed to solve.

OK, and in my previous post I gave a theoretical analysis that might be the reason for that behaviour (though hard to be sure) - same problem, but the 3m cable takes it beyond what the 330R can fix.

At that time, total lead from Pico/HCT was maybe 0.25m if I consider the 16 wire ribbon cable, and the wires from the Dupont style female header to accept the ribbon cable to the strips on my test board and was driving more than 7 strips. Funny thing was that if I pressed my finger across the copper pads of a few of the strips, the erratic behavior went away. I tried substituting my finger with resistors across V+ or gnd to data input with no effect.

It was probably the capacitance of your finger that was doing the trick. If you wanted to persue that line of fixing it, you could keep the 330R (or make it a bit bigger) and add some extra capacitance in parallel with the strip input where you are currently relying on the capacitance of the chip to cause the effect. Maybe 1K and 22pF? Since it's relatively close to working, I dare say you could kludge it into success, but it will take experimentation to find the best values and if you go too far you stop it working for different reasons (you are trying to squash the reflections, end up squashing the whole signal).

Placing my finger across pads AFTER the first pixel would even help even for other rows or pixels before my finger which surprised me since the pixels reconstruct the data passed on to the next pixel.

That is a bit surprising. Maybe affecting the power? Or perhaps more likely the ground (diverting some of the high-frequency component through the capacitance of your finger and so shifting the ground reference used by the upstream chips.

Note too that my problem using the cable (and even before and not using the 330R) the problem would show past the first pixel. If the problem only affected the first pixel, I probably wouldn't have cared as much

That much is unsurprising - as you say, the first pixel repeats the data to the next pixel, so if that data is corrupt to start with it isn't going to get any better. I believe the pass-through is a simple buffer - so it will clean up the edges, but doesn't do anything about the format of the data (like removing glitches or re-timing the pulses if they have got stretched/squashed).

Statistics: Posted by arg001 — Sun Feb 04, 2024 11:06 am

---