This product went red! You can continue to order it as a normal SparkFun product.
The Qwiic LED Stick features ten addressable APA102 LEDs, making it easy to add full color LED control using I2C. Write to individual LEDs to display a count in binary, or write to the whole strip for cool lighting effects. You can even add more LEDs to the end if you need to1. We’ve written an Arduino library that takes care of the I2C and communication to the LEDs so all you have to do is decide what color each LED should be.
The LED Stick has a default I2C address of 0x23 but can be changed with a simple command, allowing you to control up to 100 LEDs (10 Qwiic LED Sticks) on a single bus1! The address can also be changed to 0x22 by closing the solder jumper on the back of the board.
This board is one of our many Qwiic compatible boards! Simply plug and go. No soldering, no figuring out which is SDA or SCL, and no voltage regulation or translation required!
We do not plan to regularly produce SparkX products so get them while they’re hot!
NOTE: The I2C address of the LED Stick is 0x23 and is jumper selectable to 0x22 (software-configurable to any address). A multiplexer/Mux is required to communicate to multiple LED Stick sensors on a single bus. If you need to use more than one LED Stick sensor consider using the Qwiic Mux Breakout.
1: Using a lot of LEDs can draw a lot of current. Make sure to consider the power limits of your setup. If adding an external power supply, cut the trace on the back of the board from VLED to 3.3V. If you expect more than 1A of current, connect your external supply directly to VLED. Closing the jumper from VLED to VCC will add a 4.7uF decoupling capacitor.
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
Based on 3 ratings:
This works well with the I2C coming out of the REV Expansion Hub (for FTC). I just wish it had the pigtail plug in it so you could easily plug a strip into the end!!
These are amazing little LED devices. I've used them to make visualizations of all sorts of data. Highly tunable and great example in the github repo. I've used them with ESP32 and Pro Micro devices.
So stoked that are available.
This LED stick is unusable on a busy I2C bus and crashes the whole setup.
I really hope if this becomes a real product, the FW is fixed/rewritten.
There is a bug that if for some reason the stick does not like the message it see, it holds the SDA line low preventing the i2c bus from operating any further. only a power cycle fixes the issue.
I would be happy to provide example code and logic analyzer captures of when this breaks if there is any chance of fixing the issue. Thank you,
Hey there, if you still have the example code and logic analyzer captures... I'll try to look into this once my workload lightens up.
Hello, a somewhat similar situation arose for me too. On a quiet bus, the LEDs worked great. On a busy bus, some would randomly become full white and then go back to the programmed color, eventually halting all i2c traffic.
Putting the LED stick behind a qwiic mux board seems to have solved that fail mode. LED is fading at 50ms update interval, with no flickering to white, and the traffic upstream of the mux board is functioning normally.
Hope this helps. The form factor is cool, but this i2c bugginess makes using it challenging..
That is curious... I wonder if it is because the
CLK
andDI
lines for the APA102's aren't connected to the atTiny85's designated SPI pins. Otherwise, maybe the I2C traffic is waking up the atTiny85 and causing it to write to the LEDs; however, the constant traffic is causing an interrupt when it is in the middle of that process.Do you have a setup and example code to make this issue repeatable. I am, currently, bogged down with a bunch of projects, but if I get a chance... I'll try to replicate what you users are seeing.
It's actually unusable even on an empty i2cdriver bus with only 3 of these connected and doing nothing yet.
I second this. I've seen this same thing. I changed my whole lineup just to work around it thinking it was the RPI's crappy bus, only to find it's the perfect storm for both.
Looks like a few of you have run into some issues... I'll try to look into this when I get a chance. (*I'll also make a note to see if I can create a Python package, if I get a chance as well.)
Would love to see some Raspberry Pi code for this...
Unfortunately, this is currently a SparkX product. If it transitions to a SparkFun product, we may add development resources for that.
I was able to get it to work by cribbing off of your library with some other RPI i2c code i found, thanks! Now I'm working to see if I can hook more than 2 of these to one device.
Judging from the firmware, I can plug one in, change its address in software once and that will be written in firmware. The other I can just jumper with solder.
I just wanted to provide an update that we transitioned this product to an official SparkFun product:
That is correct, the address should get stored in the EEPROM when modified by software. If you solder the jumper, then on power up, the device will default to the modified jumper address (regardless of what was configured in software previously).