dotnet / dotnet/iot

WS2812b (WS28xx?) does not work on Raspberry Pi 4B - bad colors

Open
#1,901 10 comments 0 reactions 1 assignee Claimed by @Ellerbach View on GitHub
bug Priority:2
Dominant language
C#
Stars
2.4k
Forks
630
Avg merge
11d 3h
Merged PRs (30d)
2

Description

**Describe the bug**

Colors are not what they should on Raspberry Pi 4.

It seems Raspberry Pi 4 (more?) introduce a one (1.5?) cycle delay between bytes. This mess up the timing of BitmapNeo3 format that send SPI 3bits per Neo pixel bit. 0b110 for one and 0b100 for zero. So when sending Red:
```
0b110_110_11, 0b0_110_110_1, 0b10_110_110,
0b100_100_10, 0b0_100_100_1, 0b00_100_100,
0b100_100_10, 0b0_100_100_1, 0b00_100_100,
```

the 3rd and 6th triplet gets split over a byte boundary. The 0b110 become 0b1x10 and the x-delay is sent as 0, so we get 0b1010 instead of 0b110. This is out of spec and most likely interpreted by Neo as one or two 0s instead of a 1.

A workaround is to utilize the inter byte delay as a hardcoded 0 and for example send the following to get red:
```
0b110_110_11, 0b110_110_11, 0b110_110_00,
0b100_100_10, 0b100_100_10, 0b100_100_00,
0b100_100_10, 0b100_100_10, 0b100_100_00,
```

I'm not sure if the driver in Linux can be tweeked to skip the inter byte delay. There is a .pad in the ioctl struct, but I'm not sure if the kernel driver use it. It does not seem like dotnet IoT use it which should mean it is set to 0.
I have not tested any other HW, just the Raspberry Pi 4B

**Steps to reproduce**

Run WS2812b sample and hardcode color to red.

**Expected behavior**

Red color on Nep pixel

**Actual behavior**

Orangish color on No pixel

**Versions used**

dotnet 6 - but probably irrelevant.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.