Hi, i'm trying to control 160 APA106 leds (LED Clock) with the Espruino Pico and the neopixel library.
In general, controlling the leds work (as in the addressed ones are lit up) but the brightness (an a bit of color shifting) occurres intermittently and gradually worse further along the 'strip' towards the end.
I first thought about hardware issues (because gradual issues tend to be signal/noise related), so i've replaced the power supply, added a 330 ohm resistor on the data line, added a large capacitor on the power rail, tried the af_opendrain state with pull up resistor, added a cheap transistor based buffer (which was too slow) and so then ordered a SN74HCT125N buffer (instead) to increase the data signal van 3.3 to 5v. Then i added 100nF decoupling capacitors on some leds to see if that made a difference (even if the APA106 datasheet mentions no external components are needed). But none of these measures fixes the issue.
So that got me wondered and i bought a scope (good excuse to do so, haha). I've scoped the dataline and noticed that the signal looks quite clean and (apart from the amount of data) the same in the beginning and the end of the loop. So with the signal/data beeing fine, i measured the periods of the data and noticed that the short period is about 0.42μs and the long period is 0.85μs which is in spec for the WS2812B (and to be expected probably), but the APA106 requires a long period of 1.36μs. Even with a tolerance of .15μs the 0.85μs is too short. This probably results in some bit shifting and increase of the rgb values?
A possible solution would be to change the neopixel source code and compile/flash a complete new firmware, but that is way out of my comfort zone. And this won't allow for easy firmare updates (which i'm doing since the first kickstarter).
Perhaps it is an idea to add an additional property to the require("neopixel").write() with 3 timings or just a led type (like the NeoPixelBus Arduino lib, which has fixed this issue also)? Not sure if that is possible for compiled code. Otherwise a 'custom' APA106 function would be nice.
Or is there something other i can do (apart from changing the hardware)?
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.
Hi, i'm trying to control 160 APA106 leds (LED Clock) with the Espruino Pico and the neopixel library.
In general, controlling the leds work (as in the addressed ones are lit up) but the brightness (an a bit of color shifting) occurres intermittently and gradually worse further along the 'strip' towards the end.
I first thought about hardware issues (because gradual issues tend to be signal/noise related), so i've replaced the power supply, added a 330 ohm resistor on the data line, added a large capacitor on the power rail, tried the af_opendrain state with pull up resistor, added a cheap transistor based buffer (which was too slow) and so then ordered a SN74HCT125N buffer (instead) to increase the data signal van 3.3 to 5v. Then i added 100nF decoupling capacitors on some leds to see if that made a difference (even if the APA106 datasheet mentions no external components are needed). But none of these measures fixes the issue.
Having searched the internet, i found out that the APA106 has different timings than the more common WS2812B or others, where the neopixel library is mainly setup for.
So that got me wondered and i bought a scope (good excuse to do so, haha). I've scoped the dataline and noticed that the signal looks quite clean and (apart from the amount of data) the same in the beginning and the end of the loop. So with the signal/data beeing fine, i measured the periods of the data and noticed that the short period is about 0.42μs and the long period is 0.85μs which is in spec for the WS2812B (and to be expected probably), but the APA106 requires a long period of 1.36μs. Even with a tolerance of .15μs the 0.85μs is too short. This probably results in some bit shifting and increase of the rgb values?
A possible solution would be to change the neopixel source code and compile/flash a complete new firmware, but that is way out of my comfort zone. And this won't allow for easy firmare updates (which i'm doing since the first kickstarter).
Perhaps it is an idea to add an additional property to the require("neopixel").write() with 3 timings or just a led type (like the NeoPixelBus Arduino lib, which has fixed this issue also)? Not sure if that is possible for compiled code. Otherwise a 'custom' APA106 function would be nice.
Or is there something other i can do (apart from changing the hardware)?