NeoPixels, 3.5.0 RC3

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!