Sometimes those little jumpers develop an OPEN connection under the rubber overmolding on the pin. It LOOKS like it’s fine, but it anything but fine. Looks like you have the PREMIUM jumpers though, so I’m not sure what it could have been.
Here’s a picture of my neopixel strip… notice the cap is right up close to the strip power input. This is ideally where you want it, but it’s arguably more of a pain to get it there. The reason is when the pixels turn on they will draw current abruptly and IR voltage drops ( current multiplied by resistance = voltage ) will form across all of your wiring and connection back to the point where current is sourced from. In this case it’s the big cap, for all of the instantaneous current requirements. It just means if the Core is powered from a tapped off point between the cap and the strip, it may see power spikes which could reset (brown out reset) the STM32 processor… this is probably not happening in your case, but these are just design principles which are good to know about and follow.
Ah, got it. Thanks! As you can probably tell, I'm pretty new to electronics
I'll see if I can move the cap closer to the strip power input. I'm using a 4700uF / 10V cap and I see that yours is 1000uF / 10V. Is there harm in having too much capacitance?
Also, what's the resistance on that resistor you have going into the strip? I'm planning on adding a 300 Ohm one to be safe (per the Adafruit "best practices" page - Best Practices | Adafruit NeoPixel Überguide | Adafruit Learning System), but I'm not understanding the second sentence... wouldn't a resistor add the same resistance at either end of the wire? Can I just add it to the breadboard?
Place a 300 to 500 Ohm resistor between the Arduino data output pin and the input to the first NeoPixel. This resistor must be at the NeoPixel end of the wire to be effective!
4700uF should be fine… more is usually ok, up to a point. The larger the capacitance, the longer it will take to charge up initially when you plug in your power. This is probably not going to be an issue here. And also if you have a really large cap, you might want to limit the amount of in-rush current that it sees with a constant current pre-charge circuit (also not needed here). Just slap on 1000uF+ and you’ll be fine!
I used a 430 ohm resistor. I just added mine to the cable so I’d always have it attached This is my gen-purpose debugging strip. The resistor can be at either end, but depending on how it’s being driven and the application, there may be advantages to placing it closer to the transmitting side or receiving side. It’s kind of a good long debate that you have when you really dive deep into transmission line theory and EMI/EMC testing. For NeoPixels I can’t see it mattering much which end of the cable it’s on, although I tend to always put these resistors closer to the receiving side.
So something i’ve been trying to get to for some time is making a simple neopixel hookup shield for the Spark core. Had a go at it tonight. This is where i’m currently at.
I’ts based on BDub’s suggested schematic which was backed up by some googling on the subject.
So it’s DC in on a standard DC Jack and three pin header to your neopixles, usually soldered to a JST lead.
I’ve also included a pushbutton for useful “mode” changes in your code.
Anybody interested in this kind of thing as a kit?
Hi. I’m using the Adafruit Library, but i can’t solve following problem:
I have 3 stripes 144 leds each. If i start my program or standard test i have always the same problem (170 or 180 led)
The program begins to show another colors and begins to flash. i tried with different platforms Uno and Mega but i have always the same problem. I am using adapter - 20A. I tried to use another library - FastLED, but there i have the same problem. I can’t have that all leds have the same color. I tried to reduce the brightness, but it does’t solve the problem.
If someone had the same problem and solved it, please answer.
@andybu sorry for the late reply, did you get this sorted?
it may be a power issue, are you powering each new strip with separate wires or just feeding the power all from one end? the volt drop may be causing the problem.
###Just updated the NeoPixel library to support the Photon for all pixel types!
The Spark Core is still supported as well
Important:
If you have an old app in Build that you are migrating to a Photon or Core, please remove the NeoPixel library from your app and re-apply it to update the included library to v0.0.6. If you are creating a new app for a Photon or Core, simple add the NeoPixel library to your app and you will have the latest v0.0.6.
added a new type of pixel WS2812B2 which is just a different timing method I wanted to explore for WS2812B pixels using the DWT timer. It’s good and works, but assembly instructions are still more accurate.
Notes:
Don’t use getPixelColor() to move pixel data around when you are also using setBrightness(). When the brightness is set, all setPixelColor() calls will end up scaling colors to dim them before they are stored in memory. When using getPixelColor() the stored dimmed color is rescaled back up to the original color. However, due to some loss of precision with the math, it is not possible to recreate this color data perfectly. This is especially true with low brightness values. If you get and set color data repeatedly with a dimmed pixel, it will eventually continue to decrease in value until it is equal to zero.
When changing the brightness, always call setPixelColor() first with fresh un-dimmed color data, then call setBrightness(), and finally show().
Hi BDub,
Great work on the Sparkcore Neopixel library. It works great with the RGB WS2812 strip. However, I am now trying to run a RBGW strip (half the LED is a warm white LED). Do you have a explanation of your code so that I can modify it for 4 LEDs as opposed to 3? I am a beginner coder, and don’t especially understand the assembly part. Do you have any suggestions?
Hey @Rakesh thanks! First question is which strip exactly do you have? If it’s like this one https://www.adafruit.com/products/2439 then it appears the whole strip is controlled all at once with high voltage and mosfets (driven via PWM). So you may not need a library to drive it, but just some good old PWM outputs. Check out Adafruit’s tutorial on how to wire and code these types of strips: https://learn.adafruit.com/rgb-led-strips
If I’m totally off about what you have, please point me to the datasheet for your LED strip and I can give you some better advice
Hi BDub,
The LEDs I have are similar to the link posted by Hootie81, just a lower pixel density(60/m)
They are like the adressable SMD5050 RGB LEDs. The RGBW LEDs I have work with the current Arduino neopixel library+Arduino, as there is support for RGBW there. I was looking through the code and the inline asm code is different from the neopixel library for the photon.
I am just trying to understand how the current neopixel library for photon works, and if I can do something simple to add a 4th pixel to the current code and have the setpixelcolor function accept 4 input values.
It looks like it’s as simple as adding a 4th byte for the white LED on all pixels. Currently there are only 24 bits sent per byte, and now there needs to be 32 bits. The timing may be different, I haven’t compared yet. The assembly part of the library is really simple, it’s just NOPs that add 1 cycle of delay time. It’s nearly impossible to calculate the number of NOPs required though. What I usually do when supporting a new type of strip is just hand calibrate the delays with an oscilloscope, and iterate until it’s as close as I can get it. Looks like I need to order one of these strips to make sure it’s working with the neopixel library Looks like you’ll be attempting something now, so good luck!
###Just updated the NeoPixel library to support the P1 and Electron
Important:
If you have an old app in Build that you are migrating to a Photon, P1, Electron or Core, please remove the NeoPixel library from your app and re-apply it to update the included library to v0.0.8. If you are creating a new app, simple add the NeoPixel library to your app and you will have the latest v0.0.8.
Has anyone checked the stability of this library over many hours? I am still experiencing many lockups of the photon when I am trying to run this for many hours. I am driving 21 LEDs that are daisy chained at around 20hz refresh rate (ideally I want to get this higher).
I have implemented a watchdog reset library and I am recording upwards of 20 reboots over 24 hours. From my print statement debugging, it seems like the code is freezing on the strip.show() command. Whenever it locks up, I am receiving the print statement before the strip.show() but never the one after. I am unable to debug deeper than this since any internal print statements disturb the Neopixel library’s time sensitive code.
Is it possible that the fast IRQ interrupt detaching and reattaching is causing issues? Any ideas on how I can explore this? I am running the photon with system thread enabled and have tried with both system mode in manual and automatic but neither removes the lock up issue.
Hey @sdinnu, I’m thinking there must be some series of things in your code that’s leading to this instability. I built a 24 pixel advent calendar that was hanging on my xmas tree for all of December and it was very consistantly connected. I just happened to have an IFTTT service hooked up to that Photon monitoring my online/offline status and it was only down when it was deep sleeping from 1am to 7am (power save mode), or if my internet was down (due to Comcast or my router needing a kick in the pants).
I’m sure I’m not doing the same things you are though… are you using attachInterrupt()? The Neopixel library disables all interrupts in the show() routine to keep 100% focus on bitbanging the output pin. If you are using Multi-threading with this, there are bound to be other issues. First try disabling multi-threading and go from there. If that’s the issue I bet there’s a way to fix things in the Neopixel library to play well with system threads.
I had not altered the Neopixel library but I did recently add the Photon-WDGS timer library since I was getting system lockups and I needed the Photon to reset automatically. I know that the WDGS library is attaching interrupts to check if the photon is locked up. In the next couple days I will completely strip down the code until I can figure out whats causing the issue.
I understand that in the show() routine, all interrupts are disabled, but should that impact the system thread? I assumed it would only impact the user thread and the interrupts involved in that. Ill try going into single thread mode, but I really would like to have a separate user thread as the code polls from many sensors and writes to the flash-EEPROM and I dont want it hanging because of Wifi commands.
In terms of general code instability, are there things I should look for while debugging to figure out lock ups? I checked the system free memory and it doesnt seem to be changing so I dont think its a memory leak. I guess best thing is to just comment stuff out until it stops locking up. I unfortunately cannot replicate the lockup nor is the frequency happening at a fixed rate so its a fairly long debug process per change.
Yeah intermittent lock ups are quite fun You could run your application via GDB debugger via JTAG and Particle Programmer Shield, and when it locks up it’s most likely in a tight loop somewhere… so then just break and step debug to see what the issue is.
Is there any debugger shield for the P1? My project uses all the pins of the Photon and its going to be hard to add JTAG pins without not being able to utilize all my pins.
I would like to know the same thing, jamesarm97. I purchased a spool of the RGBW Neopixels but I am not advanced enough to determine what needs to be changed to allow it to work with the Photon. I currently have an Arduino Uno with a Bluetooth module controlling them for under cabinet lighting in my kitchen, but it’s a pain to control. Would love to get one of my Photons running the lights.
This is my gen-purpose debugging strip. The resistor can be at either end, but depending on how it’s being driven and the application, there may be advantages to placing it closer to the transmitting side or receiving side. It’s kind of a good long debate that you have when you really dive deep into transmission line theory and EMI/EMC testing. For NeoPixels I can’t see it mattering much which end of the cable it’s on, although I tend to always put these resistors closer to the receiving side.
Looks like you’ll be attempting something now, so good luck!