Hi Particle community,
I have looked up if a similar issue was already reported and I didn’t find any. Therefore I create a new thread…
For my distributed home automation system, using a dozen of Photons, I would like to use a Raspberry Pi 3B+ as the “conductor” of my Photon orchestra:
It should collect the live data from all “musicians” and show the home systems status on a panel using about 100 neopixels.
When one of the musicians does not respond, it should hard reset it with a short power cycle. (Seems to be needed for some on a regular basis, even without memory leak…
I have tried out the “Particle Pi”, using the GPIO’s available and they work fine.
Now I want to connect a string of Neopixels to test this but I run into compile errors shown below:
adafruit has an article specifically about using neopixels with a RPi:
Note in the first paragraph this key statement which will apply to running within the Particle Agent:
Because the Raspberry Pi runs a multi-tasking Linux operating system it doesn't have real-time control over its GPIO pins and can't easily drive NeoPixels.
I would assume the easiest way to get this going is to figure out how to run NeoPixels on the RPi separately from the Particle Agent and then figure out a method of communication between the Particle Agent and your RPi code running the NeoPixels.
Not a solution for your NeoPixel problem, but there are other smart LEDs that are way less timing dependent than NeoPixels.
APA102 (aka DotStar) are my choice - a bit more expensive but definetly a lot easier to drive (no library needed at all)
Thanks @cyclin_al and @ScruffR for your quick tips!
I will study these resources and hope to find a way to make this work...
I read the article about the special library but this is exceeding my programming experience, I'm afraid...
For this application, I suppose the APA102 (aka DotStar) will be a solution.
This was one of the simplest ways I could come up for controlling an APA102 strip of virtually any length.
I’m not sure whether HW SPI is supported by the RPi Particle Agent, but if it isn’t pushing the data out in a synchronous fashion via shiftOut() should be just as simple.
As soon as I receive this strip, I will test it with below sketch.
Can you check if it should work with the commands after " // setup your pixels"
(It does compile for RPi...)
#define LEDCOUNT 300
uint32_t pxBuffer[LEDCOUNT];
// actually for the APA102 protocol you need some extra bytes for leadin/leadout
//uint32_t pxBuffer[1 + LEDCOUNT + LEDCOUNT/16 + 1]; // element 0 (leadin) ... LEDs ... 1 leadout clock per 2 LEDs (ceil)
bool needRefresh;
volatile bool canRefresh = true;
void setup()
{
SPI.begin();
SPI.setClockSpeed(8, MHZ);
//SPI.setDataMode(0);
SPI.setBitOrder(MSBFIRST);
}
uint32_t setAPA102Color(int px, uint8_t r, uint8_t g, uint8_t b, uint8_t brightness = 31)
{
uint32_t color = 0;
// due to big endianness in revers order
color |= (brightness << 0) | 0xE0; //top 3 bits must be 111
color |= (r << 8);
color |= (g << 16);
color |= (b << 24);
pxBuffer[px] = color;
return color;
}
void refreshDone()
{
canRefresh = true;
}
void loop()
{
// setup your pixels
setAPA102Color(8, 30, 100, 40, 100); // = Approx. "Set LED #8 to 15% RED, 50% GREEN and 20% BLUE"
setAPA102Color(67, 40, 0, 0, 100); // = Approx. "Set LED #67 to 20% RED"
setAPA102Color(88, 40, 0, 140, 100); // = Approx. "Set LED #88 to 20% RED and 70% BLUE"
if (needRefresh && canRefresh)
{
canRefresh =
needRefresh = false;
SPI.transfer(pxBuffer, NULL, sizeof(pxBuffer), refreshDone);
}
delay(2000); // Slow down loop...
}
That’s a feature of the APA102 LEDs that makes it easy to dim the LEDs without having to recalculate the RGB ratios.
The dimming is also achieved differentyl. While the RGB values are created with a higher frequency PWM signal (19.2kHz) the dimming is done via a superimposed 582Hz PWM. So the actual color stays exactly the same, it’s just not displayed all the time.
This makes things like a breathing effect really simple, since you just need to modulate the one brightness value without needing to adapt the RGB values which is - when considering the human psycho-optic perception - not as straight forward as just linearly scaling it down the RGB components (not that this would matter for the average use tho’).
I haven’t found a lot of info about the low level workings of the WS2813 but one thing I found was that it seems the WS2813 has a lower RGB PWM frequency (2kHz vs. 19.2kHz)
For more detail I’d have ot order some WS2813 and have some signal analysis - if I ever find the time
Hi @ScruffR, I have received my strip of 144 WS2813 “SPI-addressable LEDs” some time ago but I only found time yesterday to try your test sketch with the Photon.
My objective: If that works, I want to make a 100-LED status panel with the RPi…
The sketch compiles fine and I flashed it to the Photon, but I can’t see any response…
Possibly this stip is not compatible with the 3v3 data pulses, contrary to the classic addressable chips…
So, I can test it with an Arduino Nano if you believe I can use the same sketch…
Any suggestions meanwhile?
(I’ll be out till sunday…)
What is the exact type of that strip?
The wording “IN Backup Data” sounds puzzling. The CLK line does not carry any data (backup or not) but only provides the timing.
Update:
So I now found a datasheet of the WS2813 and as it turns out they are not comparable to the APA102 when it comes to protocol. These LEDs are still using a time critical protocl like the original NeoPixels but feature a sort of bypass feature where one broken LED in the chain shouldn’t affect the following (hence the naming “Backup Control data signal input”) http://www.world-semi.com/DownLoadFile/136
So I’m afraid, my simple code won’t work on these but only on APA102 LEDs and compatible ones (WS2813 aren’t).
Thanks for yr quick reply!
I am travelling and will try to respond from my iPhone:
I understand that “Backup data” sounds confusing… but the terminology for both datalines comes from the eBay seller.
If you want, I can send a screenshot when I’m back home…
Update for the “wrong DOTSTAR strip” (WS2813) I bought earlier:
indeed, using any of the 2 data wires, it works with the traditional “Neopixel” library.
Q: Any idea how we are supposed to connect both wires to a Photon? Both in parallel?
In that case, they could as well do that on the flexible PCB and let only one wire come out…
