TL;DR: It turns out to be an electrical issue after all.
Perhaps the timings for this type of LED are not optimal and makes the LED more sensitive to interference or something. But more likely the seller cheaped out on me and did not sell APA106 LEDs but P9823 or some other clones that require external components, but i can't say for sure. In the end, soldering decoupling capacitors on all LEDS (not only a couple as i tried before) fixed the issue.
Long story:
I first tried the latest espruino_2v17.23_pico_1r3.bin, but that did not fix the issue. I had to add the SPI2 setup to make it work in the first place, so that is probably not a good change (for other users) and i would suggest to revert that?
So then i started measuring again, and noticed that the signal mostly stayed the same. Then i remembered i had ordered a cheap logic analyzer in the past, but misplaced it somewhere. After finding that, i've hooked that up and started logging.
When measuring this way (and decoding as WS2813, because decoding as 2812 did not work), i saw that the values in the start where always correct (except for the first data signal after powering up, but thats ok).
So i hooked up the other chanels further along the string of LEDS. Then, after a few tries i noticed that the values changed sometimes (from 141414 which is 20 to 282828), which should not happen of course. This made me beleive that the LEDs where not functioning properly and messing up the data signal (as the signal itself looked clean on the scope).
After that, i started adding (more) decoupling capacitors on the LEDs and slowly saw that the issue was going away. As the datasheet for APA106's states that no external components are needed, i was looking the wrong way..
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
TL;DR: It turns out to be an electrical issue after all.
Perhaps the timings for this type of LED are not optimal and makes the LED more sensitive to interference or something. But more likely the seller cheaped out on me and did not sell APA106 LEDs but P9823 or some other clones that require external components, but i can't say for sure. In the end, soldering decoupling capacitors on all LEDS (not only a couple as i tried before) fixed the issue.
Long story:
I first tried the latest
espruino_2v17.23_pico_1r3.bin
, but that did not fix the issue. I had to add the SPI2 setup to make it work in the first place, so that is probably not a good change (for other users) and i would suggest to revert that?So then i started measuring again, and noticed that the signal mostly stayed the same. Then i remembered i had ordered a cheap logic analyzer in the past, but misplaced it somewhere. After finding that, i've hooked that up and started logging.
When measuring this way (and decoding as WS2813, because decoding as 2812 did not work), i saw that the values in the start where always correct (except for the first data signal after powering up, but thats ok).
So i hooked up the other chanels further along the string of LEDS. Then, after a few tries i noticed that the values changed sometimes (from 141414 which is 20 to 282828), which should not happen of course. This made me beleive that the LEDs where not functioning properly and messing up the data signal (as the signal itself looked clean on the scope).
After that, i started adding (more) decoupling capacitors on the LEDs and slowly saw that the issue was going away. As the datasheet for APA106's states that no external components are needed, i was looking the wrong way..
My apologies for wasting your time!
1 Attachment