NeoPixels, 3.5.0 RC3

DonStauffer

Since I upgraded to RRF 3.5 RC3 the first in my strip of 10 NeoPixels turns green at startup, when as far as I can tell, these lines in config.g should turn all 10 off:

M950 E0 C"connlcd.5" T1	;	NeoPixel RGB
M150 E0 R0 U0 B0 P0 S10 F0		;	Off

(I changed "connlcd.np" to "connlcd.5" in attempting to fix this.)

It used to turn them all off. Now that one green LED stays on no matter what. Nothing I do short of disconnecting wiring changes that. I have a spare NeoPixel strip, so I tried that one. It behaves exactly the same, so I conclude it's not the strip.

Lots has been going on around now, so I'm not positive the firmware upgrade did it, but it seems like it to me.

Any suggestions are appreciated. I'm out of ideas.

Edit: Google found a discussion not relating to Duet but with a similar situation, which someone with an oscilloscope identified as "first high pulse is too long for representing a 0 bit according to the WS2812B spec". The consensus seems to be this is a timing error in the signal, and some have mentioned that any timing errors from the buffer used to pull up the voltage are additive with the source. So, the question becomes, from 3.4.6 to 3.5.0 RC3, were any changes made to the LED part which might affect the timing? I've also seen more than once comments that WiFi may be somehow related; I don't really see how, but people say it.

Additional info:

Executing M150 R255 U255 B255 P64 E0 F0 S10 turns the offending (first) LED aqua, and the remaining 9 white, as expected. Interesting that it seems like the green component remains at a higher level than the P64 would "want", in addition to what the white asked for. This suggests to me some sort of odd signalling problem on the Duet (and from what I've read, some other platforms as well).

I wonder if this might have to do with adding support for RGBW strips; is it possible the new firmware switches things to RGBW NeoPixel mode even if you tell it "T1" (RGB NeoPixel)?

gloomyandy

@DonStauffer What output do you get if you run M950 E0

droftarts

@DonStauffer connlcd.5 pin is 3.3V. Are you using a level shifter? How long is the LED string? What RRF version did it last work correctly with?

When I updated the LED wiki page, I tested pretty much all boards and quite a few firmware versions, and I remember the first LED on a strip always having problems on a 3.3V output. However, I don’t think I tested firmware versions before RGBW support was added.

Ian

DonStauffer

@droftarts M950 E0
NeoPixel_RGB strip on port "(connlcd.np,connlcd.db7,connlcd.5)" uses bit-banging, frequency 400000Hz, max strip length 28

(The "400000" is left over from my trying to solve the problems by changing clock frequency, which didn't change the behavior. The length of 28 is a 10 LED strip and an 18. I've been experimenting with connecting 2 strips in "series")

DonStauffer

@droftarts I have a CMOS buffer pulling the voltage up to 5V.

gloomyandy

@DonStauffer What does it report if you get rid of the Q400000 you added? I'd like to see the base frequency.

DonStauffer

@gloomyandy M950 E0
NeoPixel_RGB strip on port "(connlcd.np,connlcd.db7,connlcd.5)" uses bit-banging, frequency 2500000Hz, max strip length 28

DonStauffer

@droftarts I'm also seeing occasional random flashes of a few of the LEDs during changes. Not a major problem, but not right and it wasn't happening before the firmware update.

gloomyandy

@DonStauffer I'd try changing the frequency either side of the default say from 2000000 to 3000000 if even a little wider see how it changes things. You may only need to change it by a small amount so try 100000 steps. I know you tried a different frequency before, but that was around 400KHz, which is actually ok for the Neopixel bit update frequency, but in this case the frequency being specified is the clock used by the underlying hardware which uses multiple clocks per neopixel bit, hence the default is much higher at 2.5MHz.

DonStauffer

@gloomyandy I'll try some more frequencies. I think I tried 3200000 and 3000000 and 800K & 400K, as well as whatever the default is.

dc42

@DonStauffer if it was working OK before the firmware update then changing the frequency is unlikely to fix it. If it's a Duet then the frequency is ignored in bit-banging mode anyway.

Please test whether he problem still exists using the updated firmware at https://www.dropbox.com/scl/fo/yzchzlyxmxlzywjawqflu/h?rlkey=tl7dfs75yozhfgpze0jnkn32n&dl=0.

I think the board you are using is a Duet 2 - can you confirm that?

Do you have a level shifter connected between the Duet output and the LED strip? Neopixel and similar LEDs need 5V drive but most outputs on the Duet only provide 3.3V. See https://hackaday.com/2017/01/20/cheating-at-5v-ws2812-control-to-use-a-3-3v-data-line/.

DonStauffer

@dc42 RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-rc.3+ (2024-03-18 09:34:21) running on Duet WiFi 1.02 or later + DueX5 (after installing the file you linked to)

The results are now about 1 in 5 times the first LED is green at power on until it reaches the 2 lines in config.g:

M950 E0 C"connlcd.np" T1 U28
M150 E0 R0 U0 B0 P0 S28 F0 ; Off

That would be fine if it always was like that, but the rest of the time it's the way it was, and M999 never fixes it.

The level shifter is as you described: The Duet CONN_LCD pin 5 feeds the input of the buffer, and the output goes to the NeoPixel data line.

The only other thing is I would swear this time that when I gently nudged the wiring the green light went out once. I doubt I touched the conductors, and all connections are crimped, plugged in, or soldered. So it isn't like I interrupted an alligator clip connection or something. I would guess static electricity or capacitance had something to do with it. The buffer chip is a hex buffer (ON Semiconductor MC74VHCT50A) and I've tried 3 of the 6 buffers with identical results.

dc42

@DonStauffer thanks for reporting this. I have reproduced it and fixed it in the RRF 3.5 source code.

droftarts

@DonStauffer @dc42 has fixed this issue. Latest binaries are here: https://www.dropbox.com/scl/fo/wrp6hvr39vjxjlep89p5x/h?rlkey=hzka49sxnsqjpwsvy46m26ms0&dl=0

Ian

DonStauffer

@droftarts Thanks! I downloaded and will report results later today.

DonStauffer

@droftarts Looks perfect. I haven't done extensive testing, but absolutely no issues so far. Still random before the configuration lines get hit, but that's fine. After, everything behaves beautifully!