RGB External Strip Current Working Example

I am really struggling with your RGB controls framework, and how vague the current documentation is, regarding best practices in the real world, and am hoping, someone who has a working example I can look at the wiring diagram on, and figure out where I am going wrong here. Not a single strip I have tried can be powered off the 5v input for device without major issues, and am having to resort to barrel connector which is 12V.

My question regarding this, is why not add provisions to the all of your future shipping controllers, so they are not plagued with this issue, as its cost me quite a bit of time already here? The controller should be able accommodate a decent size array of RGB LEDS out of the box. It can’t even handle a small strip of 6 out of the box, using the 5V pin for power.

This a bit ridiculous to me, but ok, we work around it, but that is where I am running into constant issues, a ton of conflicting information, and not one of the tutorials I have attempted, has led to a working strip with RGB controls. I am hoping one of you can help me determine what I am doing wrong here.

Can anyone provide me, a working wiring diagram example using an Argon or Boron and an RGB 4 wire style strip, or even a single control wire one, would work at this point, as I am not attached to either one, as long as it works?

I have tried using the neopixel libraries and single wire RGB controls and have struck out their too. I can change the onbaord LED color no problem, but it is not working using the mirroTo, or changeHandler.

My current iteration is using A0(R),A1(G),A2(B) Pins. The documentation states they are PWM capable pins.

The strip will light up fully, as I am running 12V in from the barrel connector to the power in pin on the LED strip, and connecting the ground wire off the the barrel connector to the same ground as the device, BUT it is stuck white.

The issue is with RGB pins, as they are not generating enough voltage, for whatever reason, when changing the RGB values in code. I have a cheap bluetooth RGB controller, that I am testing this against, which is even smaller than the argon, which works great with this strip, so I know this possible using the same barrel connector to power it.

The off brand controller, that works, is putting out approximately 1.5 volts on each RGB pin, but the Argon is only generating approximately 0.5mV, by comparison, and where I believe the problem to be originating from. I have 3.3V regulators, and a wide array of capacitors and resistors available I can use here, but nothing I have tried, is working at this point. Theoretically the correct size capacitor and voltage regulators, combined with the correct resistor size on each RGB pin, should allow each pin to deliver that same 1.5 volts, but nothing I have tried has worked, and want to make sure there isn’t something else I am missing here, or there isn’t a simpler more efficient way to accomplish this.

Also, if I pull the RGB pin jumper wires out, it changes colors when the jumper wires are pulled out, but not when it is changed in code, which makes this even more confusing as to what is causing this issue.

Any ideas??? Any working examples??

The default configuration of the mirrored RGB LEDs is common anode. In other words, the + side of the LEDs is connected to the + external power, and there’s an appropriate current limiting resistor to connect to the Particle device GPIO.

However, the problem you are experiencing is probably not the voltage, but the current. The default maximum drive strength is 2 mA. This is far below anything other than a SMD low-current RGB LED.

It’s possible to use pinSetDriveStrength to increase this to 10 mA, but this is still half of what you’d need even for a standard T 1 3/4 RGB LED, which is often 20 mA per color.

In order to drive anything of size you’ll need three drivers, typically a transistor.


Using a NeoPixel often will require a level shifter, because GPIO are 3.3V, not 5V. On some WS2812s this works, but it’s out of spec and often does not work.

Also beware of using a NeoPixel from a LED change handler. The LED change is called as an ISR and I don’t think changing a pixel color can be done from an ISR with the NeoPixel library.

Thank you for your response. I really appreciate it.

Unfortunately, your response only further illustrates my point, in that the current Libraries and hardware limitations of the Argon create a ton of problems here. Because at no point in your answer, did you provide me a currently working example, and your suggestions only paint half the picture to getting this to work. The bluetooth controller I mentioned is like a $20 amazon cheapo controller and has no issues running this led strip off of the same barrel connector and 12V input.

Changing the pin drive strength does not appear to have made any difference either unfortunately.

What you are saying, it sounds like, is that there is not enough current delivered to the pins even when they flooded, due to the micro USB power supply not generating enough voltage or current for the device as well as to drive the pins with that much current, and in order to boost the current, you need to use transistors to accomplish this.

In the next version of argon/boron, please run them off of usb C and this will be a non issue, as you will have more than enough voltage and current coming in, to make this a thing of the past.

In the meantime, I only have 3.3V regulators available, and will need to order some transistors for this.

Do you have any, that you recommend using here, to achieve that 1.5V 20MA requirement on each pin, with the least amount of parts?

Could I use high drive strength, on those pins, and use a capacitor and resistors to achieve the necessary amperage, or would I still have better chances with a transistor still?

In an ideal world, I would really like to be able to use the 12V power source to drive the RGB pins, as they are pretty pointless, without this capability.

You could, theoretically, just dedicate an additional input pin to this, and then use the controller to proxy the neccessary voltage and current from the 12V input source into those PINs, but this would likely be a change you guys need to make on your end for this to work, so when an additional input pin is setup for the RGB control pins in the firmware, it works correctly with everything else, will use the 12V input pin voltage and current, to drive those pins, and then eliminate a boatload of these issues on the next version of these, or even an update to the current version. This would be so much simpler, and easier, than all the extra work I had to do here. Then I could run almost any RGB Strip off this, and the only components I would need to buy, would be barrel plug and adapter. You may even able to pull this off with software alone, depending on if the onboard components of the argon and boron are capable and can tolerate this.

If a typical RGB strip requires 20mA to drive the strip colors, then I really don’t understand why you haven’t provided a better built in way around this issue, as its clearly an issue.

Again, thank you for your help and time here!

Hi, you can drive the LEDs with 12V, and for that, you need external help like a Darlington transistor array.
I think in the past I've used the uln2803, but there are many similar ones.

Best

(What happened is that I answered the post, then when I came back later, I decided that I didn’t actually answer the question, so I deleted my post, but the original poster read it and responded after I deleted it, so I undeleted it to reduce confusion.)

1 Like

Thank you very much for the proposed solution! If this works, it will definitely make this process much simpler to execute, and get me through this issue!

Just so I am clear, on what you are proposing here, is that I can run the 12V power and GND into the ULN2803, and then run RGB pins through separate channels of the ULN2803, and the output on the other side where they come out of the ULN2803, should output a voltage and current, that should be adequate to control the colors of the strip correctly. Is that correct?

If yes, I will give this a shot, and let you know if it works or not. Thank you!

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.