So simply removing the resistor didn’t solve it.
Can you clarify the transistor wiring you suggested? I’m not positive what Vdd refers to, the data pin? I have this wired currently so I’m getting 5v --> Vin and also 5v --> to + on the strip. You’re saying go from my 5v to the NeoPixels data pin as well as from D0 to the data pin? Just wanted to make sure I have this right before I short something ><
Ok, forget about the resistor… that was a shot in the dark.
The “diode” (not transistor) will drop 0.7V across itself and serve to lower the voltage to the + input of your strip. Vdd typically refers to the high side digital power input of some device. I guess I should have just said the + input of the strip.
Now that we’re on the same page, if you are powering your strip from the VIN pin on the spark core, break that connection and add a 1A or higher rated diode in series, like this: VIN on the Spark Core ---- a--|>|--c----- + input of the NeoPixel Strip
Hopefully this is really clear:
If one is not enough, try 2 in series. (2) will effectively lower your power supply to your strip to 3.4V - 3.6V, but I would think 1 diode should work.
Would the Neopixel library work for the Adafruit LPD8806 strip?
thanks…
It looks like it's done with SPI, so it should be doable on the Spark Core, but not with this NeoPixel Library. I'd say the library should be pretty easy to convert, but you'd need one of those strips to test it on.
The Adafruit library for the LPD8806 strip works, you should just add applications.h to the files you are getting an error.
I know the guys at FastLED are planing to port their library too, it has some nice features. Check it out
Just as a quick FYI, I wanted to confirm that the 5mm PIXELBIT LEDs work just fine with this library (as included in the IDE). They work in both WS2811 and 12/B modes of the lib, though it’s GRB format so the colors won’t be right unless you use the former.
This is basically the only place I’ve found diffused 5mm PTH style NeoPixels for sale (I know Adafruit carry the clear versions now, but diffused is much better looking for general use). I’ve got a couple of projects where I’d like to use RGB LEDs to show the status of things and these are going to dramatically cut down on my I/O requirements! My original plan was to use a TLC5940, but that would still require a ton of extra wiring to hook up.
When lit up they look like little pastel M&Ms! I bet the pins would hurt on the way through (or out)…
Just updated the NeoPixel library to support Radio Shack Tri-Color LED Strips that use the TM1803 800kHz controller. Also fixed a bug with the way it was decrementing the number of pixels information to send, which means it was sending 3 times as much as it needed to. I’m surprised no-one caught this, but it’s fixed now.
##Live in the Spark Libraries - NeoPixel v 0.0.4
https://www.spark.io/libs/53b38dff1b345ac05500010f/tab/a-rainbow.cpp
@timb, I’ll have to add mention of that PIXELBIT the next time I update the docs which should be soon as I’m planning on adding support for the TM1829 strips. They look sweet enough to eat 
Also I’ll probably add the RGB/GRB selectable mode back in… initially I just pruned it out so I wouldn’t have to deal with it. Now it seems useful to maybe put a few types in there, RGB, GRB and BGR (this is the color pattern of the Clearance’d out Radio Shack strips… in case you were wondering why they were giving them away for $6.99 per meter, that’s why!)
Hi, BDub, did you even looked on my code, which transfer to ws2811 data thru DMA? Is it possible to make library wich using DMA ? 
Yes it’s still on my plate of things to do. One concern I have is supporting the timing for all of these different pixels with DMA. Hopefully it’s possible, because it would be a great solution. I’m also thinking of other ways with possibly interrupts and/or just timers to do things as well, and then we can just enter the bit times.
@BDub Awesome work extending out the library! I'm curious if this might be something you could use?
Disclaimer: I have not implemented or tried out this algorithm
This guy claims to have an in-place algorithm for driving NeoPixels so memory requirements don't scale with the number of pixels being driven.
Also, I am working on a color lookup table for the LEDs in WS2812 strips (and presumably for any similar LEDs); this enables people to pick color values from their computer screen and send those values directly to the drivers. This will make it easier to encode darker colors, grays, and whites as (r,g,b) values from a color picker, and avoid having such a whited-out gamut to choose from.
Looks like it should work and is overall a very nicely documented post. It does take some shortcuts based on derived facts though, so you may not just be able to type in timing numbers for other pixels that you want to support. The Spark Core has enough processing power that with the right method, could have this dynamic timing ability. So far I've just been kind of hacking out the timing somewhat as an exercise in patience 
I know of at least 8 different ways to control neopixels now, 2 of them were ways I came up with. There is definitely always going to be a better way to do it, depending on your application.
Looking forward to see what you come up with for your color table 
Happy 4th of July, everyone!
I started out with @luz’s drivers from his messagetorch project. Because at maximum PWM duty cycle the brightness of the LEDs is ordered as blue > red > green you end up with magenta tinting with all three set to 255, so the red and blue are scaled down proportionally to estimated radiant intensity.
I ended up taking the values from gamma.h in the NeoMatrix library and scaling them like so. This reproduces grays, and duller colors without magenta tinting, as well as white and cream colors very well. It feels rather kludged together, but hopefully it works on other WS2812/WS2811 strips. Here’s the new tables:
static const byte _G[32] = { 0, 2, 4, 7, 9, 12, 14, 17, 21, 25, 29, 34, 39, 44, 51, 57, 64, 71, 79, 88, 97, 107, 118, 129, 140, 152, 165, 178, 192, 206, 221, 237};
static const byte _B[32] = { 0, 1, 3, 4, 6, 7, 9, 11, 14, 16, 19, 22, 25, 29, 33, 37, 42, 46, 52, 57, 64, 70, 77, 84, 92, 100, 108, 117, 126, 135, 145, 155};
static const byte _R[32] = { 0, 1, 3, 6, 7, 10, 12, 14, 18, 21, 25, 29, 33, 37, 43, 48, 54, 60, 67, 74, 82, 91, 100, 109, 118, 129, 140, 151, 162, 174, 187, 200};
Hi All
Apologies for the noob question. I have WS2812B LEDs that worked perfectly using Arduino Uno. I followed Uber guide, followed best practices and got it working perfectly on the Uno. I did the Arduino strand test from the Neopixel library.
On the Uno, I had ground, and Pin 6 connected.
On the spark, do i just swop ground for ground, and Pin 6 for D3 (as an example) ?
If yes, i tried this using the spark neo library and its not lighting up. Am i missing something?
I found a note in one of my projects that suggests using pin A5 for your NeoPixel data. But offhand, I can’t say whether D3 would still work okay or not.
EDIT: Nevermind, I think that was just my personal note to make it match up with a different library, so I didn’t have to swap pins when I switched between project code.
Drat. Thoughts/advice from anyone else?
You will use A5 (MOSI) on the core which is the default.
It can however be changed to probably any pins!
Sorry for the delay in replying
Ok, will try on A5, thanks
(no stress about delay - better late than never)
Have you had any luck or seen anyone else port the OctoWS2811 library for Spark yet?
Hi all
Little help needed. See image below. This setup (5M LED Strip) was working perfectly with an Arduino Uno (5V), but struggling to get it to work with the Spark (yes, total noob). I understand some pins are 5V tolerant but still doesnt seem to work. As you can see im powering the LEDs through separate 5V power supply and only connecting the ground/signal from Spark.
I read the Neo Pixel uber guide and think i need a logic level shifter but not sure how to hook it up.
Long story short, can someone help me update my hookup as per image so that spark is supported?
Vin --> 5V
A5 --> Data pin
GND --> GND
It looks correct on yours though… did you use the Neo pixel library in the Web IDE?
Or which pin did you define for the Data pin?