3.5b4 LED control issue

[skrotz]

I have some alitove 5v ws2812b led strips I am experimenting with on my railcore (has duet2 wifi and duex 5, 3.5b4). These strips seem to work ok using 3.3v to control (maybe?) as I can get a small 13 led strip to work when using the following setup:

M950 E0 C"connlcd.5" T1 U13

when hooking up the control line to connlcd.5, and the power of the strip either to 3.3v or 5v (both get same results). However, the first led always has green full on whenever I command anything (even all off), but otherwise all other leds on the strip works fine and do as commanded (and the R and B components of the first led control fine also, it just always has full G on).. I was trying to find a 5v pin I could use to see if it was a 3.3v/5v issue on the control line, like pson or duex.gp1, but those don't seem to work at all (and I'm not sure if they really are 5v or if they should be expected to work with led strips.. nothing happens at all when using them but I don't get any errors on the M950 command setting things up using them) .

My question is, in my setup is there a pin I can use that should be 5v, either on the duet2 wifi or the duex5, to control the strip?

Also.. it kind of just feels like a general bug that the first led doesn't command properly, as everything else seems ok at 3.3v... the specs I can find for my strip seems to indicate it should run ok at 3.3v for power and control, and it basically does except for that pesky first led. I can hook this strip up to an arduino and the first led (and others on the strip) works fine and does as commanded, either at 3.3v or 5v for power, however of course the arduino control line would be at 5v I think. At least I know it's not a hardware issue with the first led, though, as it commands fine on that setup.

Any help is appreciated.

[deckingman]

@skrotz This might or might not be of help but I once had similar problems with the first one or more LEDs of string acting strange and turning on at some strange colour even when the string was supposed to be off. It turned out that the data line was picking up noise. The solution was to move the controller closer to the string, thus shortening the data line.

Personally, I wouldn't bother using a Duet to control addressable LEDs - I'd use something like an ESP32 possibly with wled. In fact that's what I've just installed on my new build, although I elected to use plain daylight white LEDs. But the ESP32 means that, in conjunction with homeassistant, I can turn the strips on and off with motion (if there is no one standing in front of the printer, the lights go off), I can dim them either manually or automatically with sunset/sunrise and I can switch them selectively (i.e. the lower lights automatically come on if the build plate is more than a certain distance below the nozzle).

[dc42]

@skrotz most likely it is because you are using a 3.3V control signal with LEDs that need more to work reliably. Try using a silicon diode in series with the 5V supply to either the whole strip or just the first LED, to reduce the supply voltage and hence the required drive voltage.

Alternatively, assuming you are not using all the heater outputs on the DueX, use one of the 5V PWM outputs of the DueX to drive the strip.

[skrotz]

@dc42 Thanks for the response.. I tried hooking the strip up to duex pwm 1 and it does work, but has the same issue with the first led always being on full green.

To be specific, I hooked up 5v for the led strip to duex pwm1 5v aux, led strip gnd to pwm1 gnd, and the led control line to e2_pwm. Used

M950 E0 C"duex.pwm1" T1 U13

to define the lights. I'm happy it actually worked as my other attempts using something other than conn_lcd ports all failed, but same behavior and seems like if everything is properly 5v this should work, based on my Arduino tests with the strip. Only other thing I can think of is the Q frequency and playing with that, but I did a little previously and it didn't seem to yield any positive changes, but I'll try a bit more on this current setup as it seems most correct. I suppose it could be interference, I might try making a better and shorter cable for things, but the same cabling setup works on the Arduino tests. Seems a little too reliable in how it goes wrong to be interference.

I assume the first led on the strip is probably the last data sent and the closing data, so it seems like it could be a bug with ending of the data send to the strip, if there was a software bug causing this. Makes my software engineer spidey sense tingle.

[dc42]

@skrotz I'll try an LED strip with a DueX when I get time.

[gloomyandy]

@skrotz All of the signals pass through the first LED in a strip, but the timing is regenerated by that LED before it is passed on to the next (for more details see: https://wp.josh.com/2014/05/15/going-nsa-on-pixel-conversations/), so if there is going to be a problem it often happens with the first LED. It is certainly worth trying to vary the Q values to see if that helps things.

[skrotz]

@dc42 If there's a code bug it's probably not duex specific, I have the same issue when running the strip from the duet2 wifi.