Max 339 LED chain on Pi5

[mundo1979]

I think there is an SPI buffer issue occuring on the Pi5.

I ran the code from here: https://docs.circuitpython.org/projects/neopixel_spi/en/latest/examples.html

The lit LED stops after 339 LEDs.

Increasing the SPI buffer size from default 4096 to 32768 does not help: https://stackoverflow.com/questions/16427996/increase-spi-buffer-size-in-raspbian

[caternuson]

Have you driven the LED chain with another device to verify it's not a bad pixel at the 339th-ish location and that all LEDs of the chain can be successfully lit?

[mundo1979]

I don't have another device unfortunately. I have swapped out the last set of 50 LEDs with another one and the issue occurs in the same place so I am confident it isn't a break in the chain.

[caternuson]

OK, try setting an individual LED beyond 339 in case it is power related. All other LEDs off.

pixels.fill(0)
pixels[340] = color
pixels.show()

[stephinson]

I'm also experiencing a similar issue on the RPI 5. I have only 250 WS2811 pixels (5 x 50), connected to GPIO 10. The data line is chained, and strands are powered separately. It is able to correctly handle about 175 LEDs; the remaining may or may not light up (they light up in the first 1 or 2 iterations of the animations). Below is the code that I'm using,

import time
import board
import neopixel_spi as neopixel
from itertools import cycle
from sys import argv

NUM_PIXELS = int(argv[1])
PIXEL_ORDER = neopixel.GRB
COLORS = (0xFF0000, 0x00FF00, 0x0000FF)
DELAY = 0.1

spi = board.SPI()

pixels = neopixel.NeoPixel_SPI(
    spi, NUM_PIXELS, bpp=3, brightness=0.1, pixel_order=PIXEL_ORDER, auto_write=True
)

def rainbow_effect():
    color_cycle = cycle(COLORS)

    for color in color_cycle:
        pixels.fill(color)
        time.sleep(DELAY)

if __name__ == "__main__":
    pixels.fill(0)
    try:
        rainbow_effect()
    except KeyboardInterrupt:
        raise
    finally:
        pixels.fill(0)

Any help with this issue is much appreciated.

[mundo1979]

Sorry for the delay. My lights are still up on the tree. However, I will perform a proper test once we take them down.

I can confirm I experienced similar issues to @stephinson

[stephinson]

Sorry for the delay. My lights are still up on the tree. However, I will perform a proper test once we take them down.

I can confirm I experienced similar issues to @stephinson

Did you make any specific changes to the code to fix the issue ?

[mundo1979]

I was unable to fix the issue.

I wrote test code to light each of the LEDs in sequence (not extinguishing previous lights).

A test on a single colour (green) lit around 100 lights then went back over the first 100 but brighter then continued to around 339 where no more lights were lit.

I wanted to get the lights back off the tree so I can provide exact details.

[mundo1979]

I can confirm that the latest version of the code works great for 750 lights on the pi 5 now. Thank you!

[caternuson]

There has been no new release of this library since your 12/30/2023 post and this most recent post. So not sure what "latest version" refers to here.

Also - just FYI - this library has no relation to the rpi_ws281x library. Seeing that library repo's issue getting linked here for some reason.

[mundo1979]

In which case it must have been the type of LEDs I was using. They had a clock line which I had not connected. The new set of LEDs has no clock line.On 23 Feb 2024 16:56, Carter Nelson ***@***.***> wrote: There has been no new release of this library since your 12/30/2023 post and this most recent post. So not sure what "latest version" refers to here. Also - just FYI - this library has no relation to the rpi_ws281x library. Seeing that library repo's issue getting linked here for some reason. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[davidwernhart]

I have also tested this and I can confirm that this library generally works for driving WS2812 leds on with a Raspberry Pi 5 (afaik this is the only working implementation for the Pi 5 right now). However, I have stumbled upon the same issue as @stephinson where LEDs after the index 175 or so are simply not lit anymore, no matter how many I state in the initializer. Does anyone have ideas on why this could be the case?

[otibsa]

I have the same issue on my RPi 5 that I can light exactly 126 RGBW SK6812 LEDs (should be equivalent to 168 RGB LEDs, 168 * 3/4 = 126). If I turn on LED number 127 (pixels[126] = (50,50,50,50)) it lights up the first LED again, so it loops around.

@mundo1979 did I understand correctly, that your fix was a new LED strip? If so can you reopen this issue?

[mundo1979]

@otibsa let me give you all the info I have to try to get to the bottom of this.

Here is my test code:

import board
import neopixel_spi as neopixel
import random
import numpy
import time
from time import sleep

count=750
pixels = neopixel.NeoPixel_SPI(board.SPI(), count, auto_write=False, bpp=4, brightness=1, pixel_order=neopixel.RGB)
r=255
g=255
b=255
curpixel=0
#curtime=round(time.time() * 1000)
while True:
pixels[curpixel]=(0,0,0)
pixels[(curpixel+1) % count]=(r,g,b)
curpixel+=1
if(curpixel>=count):
curpixel=0
if(r==255 and g==255 and b==255):
g=0
b=0
elif(r==255):
r=0
g=255
elif(g==255):
g=0
b=255
elif(b==255):
r=255
g=255
#sleep(0.001)
pixels.show()

Each of the 750 LEDs light sequentially in white then red, green, blue as expected.

These are the LED strips that worked:

https://www.aliexpress.com/item/32490396753.html

A previous test with an older set of LEDs showed the issue you had. I assumed this was due to a library update in the intervening time but @caternuson informed me this was not the case. Therefore I assume the difference might be the LEDs themselves.

One difference is that the previous LED set which did not work had an extra clock line which I left disconnected (see image with red/green/blue/white wires).

The newer set do not have a clock line.

Hope this helps.

Cheers,

Ray

[mundo1979]

Here are the connected pins on the pi 5

[caternuson]

NeoPixels do not have a clock line, so not sure what those LEDs may have been.

People experiencing this behavior should try the suggested test of lighting only one NeoPixel beyond where the issue is appearing. This reduces the chances it is power related. Do not try to light up every NeoPixel, directly, in a loop, etc. Just do something like (color is not important):

pixels[N]=(255,0,0)

where N is the specific pixel. If you have 500 pixels and only 300 are "lighting up", then set N to something 301, or 367, or 421, etc. and see what happens.

[bellena]

Hi,

using a RPI 5, trying to get a neopixel ring to work, but nothing works.
`import time
import board
import neopixel_spi as neopixel
from itertools import cycle
import busio
from sys import argv

NUM_PIXELS = int(argv[1])
PIXEL_ORDER = neopixel.GRB
COLORS = (0xFF0000, 0x00FF00, 0x0000FF)
DELAY = 0.1

spi = board.SPI()

pixels = neopixel.NeoPixel_SPI(
spi, NUM_PIXELS, bpp=3, brightness=0.1, pixel_order=PIXEL_ORDER, auto_write=True
)
`

keeps getting error as :
File "/home/FGD/POC/LEDS.py", line 13, in
spi = board.SPI()
^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/board.py", line 427, in SPI
return busio.SPI(SCLK, MOSI, MISO)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/busio.py", line 365, in init
self._spi = _SPI(portId)
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/adafruit_blinka/microcontroller/generic_linux/spi.py", line 25, in init
self._spi = spi.SPI(device=(portid, 0))
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/Adafruit_PureIO/spi.py", line 149, in init
raise IOError(f"{device} does not exist")
OSError: /dev/spidev0.0 does not exist

[caternuson]

@bellena you need to enable spi in rapi-config. this it totally unrelated to this issue thread.