Connection diagram WS2815 to Pico

[2m]

I am building rustmas christmas lights and was not able to find how the WS2815 LED strip should be connected to Pico. Is it possible to control WS2815 LED strip with pico-w-neopixel-server?

Such LED strip has four wires: VCC, GND, Green data line and Blue backup line.

[krzmaz]

Hi, great to see someone using Rustmas! 😁
As for the connection: the pin on which the Raspberry Pi Pico sends the data is set here: https://github.com/krzmaz/pico-w-neopixel-server/blob/main/src/bin/tcp.rs#L58 and is currently hardcoded to GPIO2.

As for WS2815 lights - I haven't used them personally, but according to some info I've found it seems that you should connect your strips data line to GPIO2 and backup line to GND.
Also, make sure that the GNDs on the Pico and LEDs are connected.
I don't know how experienced you are with electronics, so if you have any further questions, feel free to ask! 😄

[2m]

Hi, great to see someone using Rustmas! 😁

Thank you for a quick response! I follow Matt Parker on Youtube and really enjoyed his original video on the Christmas lights. Especially when he was running the code he got as submissions on his Christmas tree. Great stuff! :)

As for your connection suggestion - it looks like eventually I have arrived at the same wiring.

However my LED strip still does not start up. When I choose TEST pattern in the Web app, I see the following in the rustmas logs:

[2023-12-19T19:32:18Z INFO  rustmas_animator] Trying to switch animation to "manual-sweep"
[2023-12-19T19:32:18Z INFO  rustmas_animator::factory] Trying to start plugin app 'manual-sweep' from directory '"plugins/manual-sweep"'

Also pico-w-neopixel-server prints out the following to the console:

Listening on TCP:1234...
Received connection from Some(Endpoint { addr: Ipv4(Address([192, 168, 86, 20])), port: 6245)

BTW, I did not yet run the calibration. I am just using the original CSV file trimmed to 300 entries.

I hope that I did not fry anything, because I have tried to start up rustmas with a couple of different wirings:

• once with DI and BI connected together to GPIO2
• once with DI and BI connected together to GPIO0, as I have mistakenly thought this controls which GPIO pin to use.

[krzmaz]

Since you're seeing the logs from the connection I think your hardware is fine. The issue is probably the difference between WS2811 that we are using and your WS2815.

Unfortunately since this seems to be hardware dependent, I most likely won't be able to help much...

Here are some thoughts though:
According to the datasheet of the WS2811 that we're using, the logic voltage should be ~6V, and the Pico uses 3.3V so technically Pico has too low voltage to drive them, but in my experience this causes artifacts (flashing LEDs, missing frames) rather than complete unresponsiveness on the WS2811.
WS2815 datasheet on the other hand requires logic voltage closer to the 12V power supply, so you probably need a logic shifter...
Also I've found this thread which mentions the difference in timing (it's also visible in the two datasheets):

WS2811
T0H : 0.5us , T0L : 2.0us
T1H : 1.2us , T1L : 1.3us

WS2813
T0H : 0.37us , T0L : 0.2us
T1H : 0.87us , T1L : 0.2us

WS2815
T0H : 0.3us , T0L : 1.1us
T1H : 1.1us , T1L : 0.3us

I'd recommend confirming that you can drive your LEDs successfully using your Pico, for example using Micropython
It has a nice API to tweak the timings: https://github.com/micropython/micropython-lib/blob/d8e163bb5f3ef45e71e145c27bc4f207beaad70f/micropython/drivers/led/neopixel/neopixel.py#L17-L23

Once you are able to control your lights, we can work together on editing this project to have different values for the timings:
https://github.com/krzmaz/pico-w-neopixel-server/blob/main/src/ws2812.rs#L39-L42

[2m]

Thank you very much for the pointer to Micropython. I was able to play around a bit in the Micropython terminal and made it work!

So the following code turns first three LEDs to blue, red and green:

from machine import Pin
from neopixel import NeoPixel

pin = Pin(2, Pin.OUT)
np = NeoPixel(pin, 8, timing=(300, 1090, 1090, 320)) # h0, l0, h1, l1
np[0] = (0, 0, 255) # blue
np[1] = (0, 255, 0) # red
np[2] = (255, 0, 0) # green
np.write()

For the timings I looked at the WS2815 datasheet and put the middle timing values:

[krzmaz]

Awesome, great to hear that there's progress!
Now comes the hard part 😅 We need to edit the timings in ws2812.rs to get your lights to work 😁
I took the example from embassy and honestly I haven't had a need to dive too deep into it - it just worked on WS2811 and WS2812.
If I understand the PIO assembly correctly, the code is using high speed mode, as the code uses the frequency of 800kHz. This means it uses half of the timings in the datasheet:

Alternatively we could stop using PIO and drive the LEDs using the main core, but that might bring a performance impact...
I will try to look into it further, but my free time is heavily limited this week.

EDIT:
Found the pico SDK example with some more inside into how the PIO assembly works:
https://github.com/raspberrypi/pico-examples/blob/master/pio/ws2812/ws2812.pio#L20-L25

[2m]

PIO sounds really cool! I will try to wrap my head around the current implementation. Then adapting it to WS2815 should not be too hard.

[2m]

I have some progress of a kind. It turns out that the same algorithm as implemented here for controlling WS2812 is described in great detail in Pico C++ SDK document.

Over there is a very helpful diagram, that explains what T1, T2 and T3 mean:

So by changing T1=2, T2=5 and T3=2 and keeping ws2812_freq = 800 as it was (WS2815 datasheet mentions that Data transmitting at speeds of up to 800Kbps) I get clock_divider as 17.36.

So every PIO state machine instruction executes every 17 or so Pico system clock tick.

Pico system clock tick takes 8ns, so now we can calculate what would be the timings that drive the WS2815 chip with the rust code:

T0H = 8ns * 17.36 * 2 = 278
T1H = 8ns * 17.36 * (2 + 5) = 972
T0L = 8ns * 17.36 * (5 + 2) = 972
T1L = 8ns * 17.36 * 2 = 278

These values fall into allowed timing values according to the WS2815 datasheet. And indeed if I use these timings with Micropython Neopixel library - it works.

However pico-w-neopixel-server does not work with these still. Will need to dig more. :)

[2m]

Actually just realized that even if not changing T* values, timings should fall according to WS2815 spec with the current pico-w-neopixel-server implementation.

[krzmaz]

Nice find! I keep forgetting how good the Raspberry Pi documentation is 😅
Okay, lets check things one by one:

• we know that you can control your LEDs using the main core (you were using the same GPIO port for all tests, right?)
• we know the TCP connection is made when using the neopixel server in this repo

I think the next things to test would be:

1. make sure that you can drive your WS2815 LEDs using PIO code at all
2. make sure that you can drive your WS2815 LEDs using PIO in Rust
3. make sure the color data is send to the Pico properly, when using Rustmas

The next steps I'd suggest would be:

• Try running the micropython example that uses PIO: [link] - make sure to use the same GPIO number during all the testing
• If that works add some hardcoded instruction to turn on a single LED in the main function, before the TCP reading loop (around lines 110-120: ws2812.write(0, 128, 0); - remember that unless you changed it, the code in this repo defaults to GPIO2
• If that works as well, then it's a connection issue rather than LED driving issue. Try sending 3 bytes of data to turn the first led to blue, the data looks like this: 03 00 00 00 7F - the first two bytes determine the length of the packet and the rest is the data. To send it easily I use netcat: printf '\x03\x00\x00\x00\x0F' | nc -v 192.168.86.xx 1234
  • you can add some logging in the read_with future in L137, e.g. log::info!("Got bytes: {:?}", x);

Sorry for all the trouble, I didn't bother documenting a lot of this, as it pretty much worked first try for me on both WS2812 LED matrix for testing, and the WS2811 Christmas lights for actual Rustmas deployment...

[2m]

Thank you for the tips! Really helpful. Good news is that sending control bytes via nc actually works! So now the only thing remaining to figure out is the webapi and webui. :)

[2m]

I got it working! I missed the fact that I need to build animations separately. So after running cargo build --release -p animations it now works! And I have to say, animations look amazing. :) In the next couple of days I will try the calibration process.

Thank you very much for your help with this. We debugged the whole stack. Which in the end even if it was not completely necessary, it was nevertheless very fun. :)

[krzmaz]

That's great news! And a lesson learned for me to add more logging to the debug build 😅
Will do that soon