Arduino Nano and a ton of LED strips...

I am using a considerable amount of LED strips in my current project and am supplying the power via a hacked desktop PSU... It's using ~10m of 5050 RGB LEDs and will be powered/dictated by an Arduino Nano, hosted/powered by an RPi sending serial commands via USB. Once I tie the GND from the 12v rail of the PSU to the Arduino's, I'm wondering if I need to take any safeguarding measures to protect the RPi when the Arduino's circuit is pulling >2A for all 10m being on full-blast white. This is one of what will eventually be several different components (each with a bunch of LEDs, relays, etc.) and I'm not sure if I should use a seperate power supply for each Arduino circuit or..? I'm not sure if all that power could backfeed into the RPi and blow up the host USB controller or something of the like. Any help would be greatly appreciated. Thanks!

I'm wondering if I need to take any safeguarding measures to protect the RPi when the Arduino's circuit is pulling >2A for all 10m being on full-blast white.

The Arduino's I/O pins can only handle 40mA maximum. You need transistors or MOSFETs to drive more current.

My apologies, I should have clarified; The arduino is running 3 shift registers that output to tip122 transistors (GND tied to the 12v PSU rail, along with the arduino's) that then drive the LED strips.

No do it right and there will be no problems. You will need power supply decoupling capacitors both 0.1uF ceramic on each chip and something big like 470uF on the power supplies.

I don’t have any decoupling capacitors, are they absolutely mandatory? I’ve included a picture of the copper etching printout:

I’ve now run into a new issue… Strangely, the following code results in all transistors being on full-blast, always. yet the voltage changes both before and after the resistor (en route to the gate of the transistor) in accordance with the code loop turning all register pins off and setting a color via ShiftPWM’s HSV function; Voltage shift from 1.63v ~ 1.74v (.3 ~ .4 after). The gate is apparently always open, so the transistor is simply on. I’ve checked continuity extensively, there are no shorts or open lines between the Arduino’s necessary 3 pins, the shift registers, their following resistors or the transistors that ultimately drive the LED strip.

const int ShiftPWM_latchPin=10;

const int ShiftPWM_dataPin = 11;
const int ShiftPWM_clockPin = 12;
const bool ShiftPWM_invertOutputs = false;
const bool ShiftPWM_balanceLoad = true;

#include <ShiftPWM.h> // include ShiftPWM.h after setting the pins!

unsigned char maxBrightness = 255;
unsigned char pwmFrequency = 75;
int numRegisters = 3;
int numRGBleds = numRegisters*8/3;

void setup() {

void loop() {
// Turn all LED’s off.
Serial.println(“Turning all LEDs off…”);
Serial.println(“Setting custom color…”);
ShiftPWM.SetHSV(0, 128, 128,255);

And apparently that image doesn't want to show... Sorry, I thought DropBox would have worked. Alas, perhaps some info may be able to be obtained with what I posted above. Thanks for your help, in advance :-)

are they absolutely mandatory


I don't have any decoupling capacitors

Then buy some or give up now.

And apparently that image doesn't want to show

Hit the reply button, not the quick reply. Bottom left corner you see an additions triangle click that and attach your image. Make sure is is no wider that 1000 pixels, if you want people to be nice about it.

I've now run into a new issue..

Can't help without a schematic of your setup.

As an aside, a TIP122 transistor is an NPN transistor, not a MOSFET. It has a base, a collector, and an emitter. It does not have a gate.

I think the problem you outlined in the last post has to do with how you're trying to do the PWM - if the output is PWM'ed, you'll see a voltage that is somewhere in between ground and Vcc. You should first see how it behaves when you keep it simple, and try to just turn on and off the transistors. Once you get that sorted, and make sure your hardware is working, then try to get the PWM to work.

You should really post that image though, so we can see how you've got things set up.

And yeah, you need the decoupling caps. They're critical in almost any circuit you'll ever make.

Ok, the image seems to be working now. All resistors are 220o, except for the ones just above the RJ45 ports, which are 1M. It seems I was mistakenly using base/gate interchangably, thanks for pointing out my error. Minus the shift registers (74HC595), I had 3 ports (instead of the 8 seen above) performing essentially the same function as this circuit on a breadboard with tip122s as well and it worked flawlessly. My suspicion is that the cheap tip122s (10/$2.50) I got for the PCB version of this may have, for some odd reason, a reversed pin assignment that is resulting in the transistor being stuck "on"... I will check into this when I get home tonight, but other than that, logic leads me to believe that the problem lies with/at the transistors: Please correct me if I'm wrong ---

1.) Debug messages are displayed as expected in the serial monitor, so we know the uC is working as it should. 2.) The shift registers are wired correctly, since the voltage off the first few output pins changes as the code turns all off and then (theoretically) sets the first 3 outputs high in a loop.

  • There is a possibility that, noting the clarification between MOSFETs and NPN, I may have inflicted the suspected pinout error on myself by placing FETs instead of NPNs in Fritzing... I shall check into this, as well.

I've also done thorough continuity checks to make sure there are no shorts to GND or otherwise and that all solder points are sufficient and connect to the appropriate traces.

If I may ask a secondary question, as I've not run into them before now; What trouble would the decoupling capacitors prevent and/or what is the purpose of using them?

Ok, DropBox is being an uber %#$^ about this, so here’s the damn URL… God that’s annoying.

And it seems I just found the problem… Stupid here used MOSFETs in the board layout instead of NPN, which means I can’t just desolder and reverse them, I get to find a screwed-up-ass twisted way to reverse the base/emitter pins so I don’t have to desolder and refabricate my entire board. scream

UPDATE: Noting the above error, I desoldered all of the transistors and re-implemented 3 in the correct pin configuration (base to register output pin through 220o resistor, collector tied to GND and emitter to the LED channel tracer.

I tried a brute-force method of hopefully just enabling all outputs without PWM, but the voltage/current don't seem to change throughout the loop of the code, on any of the pins. I do get 4.6v at each register's VCC/MS pins as expected, though. Could this have anything to do with the lack of decoupling capacitors? In varying examples I've found online, capacitors are generally (but not always) used with 8-bit shift registers, so I'm not sure if this hacked up example code is the problem as well, but as I stated earlier, all but 3 tip122s are now removed, so now the board only consists of the arduino, 3 registers and 1 channel (outputs 0,1,2) chained together (register -> 220o resistor -> tip122).

//Pin connected to latch pin (ST_CP) of 74HC595
const int latchPin = 10;
//Pin connected to clock pin (SH_CP) of 74HC595
const int clockPin = 12;
////Pin connected to Data in (DS) of 74HC595
const int dataPin = 11;

void setup() {
  //set pins to output because they are addressed in the main loop
  pinMode(latchPin, OUTPUT);
  pinMode(dataPin, OUTPUT);  
  pinMode(clockPin, OUTPUT);

void loop() {
    registerWrite(0, HIGH);
    registerWrite(1, HIGH);
    registerWrite(2, HIGH);
    registerWrite(3, HIGH);
    registerWrite(4, HIGH);
    registerWrite(5, HIGH);
    registerWrite(6, HIGH);
    registerWrite(7, HIGH);
    Serial.println("Setting high");
    Serial.println("Turning off.");
    registerWrite(0, LOW);
    registerWrite(1, LOW);
    registerWrite(2, LOW);
    registerWrite(3, LOW);
    registerWrite(4, LOW);
    registerWrite(5, LOW);
    registerWrite(6, LOW);
    registerWrite(7, LOW);

void registerWrite(int whichPin, int whichState) {
  byte bitsToSend = 0;
  digitalWrite(latchPin, LOW);
  bitWrite(bitsToSend, whichPin, whichState);
  shiftOut(dataPin, clockPin, MSBFIRST, bitsToSend);
  digitalWrite(latchPin, HIGH);

miryokuteki: Ok, DropBox is being an uber %#$^ about this, so here's the damn URL... God that's annoying.

Oh for **** sake post a schematic not a physical layout or just go away, you are a time waster.


Can you please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png or pdf?

[u]Use the REPLY button, not the Quick Reply,[/u] there will be an Attachments button that will allow you to attach your cicuit image.

Not a fritzy diag, but a schermatic diagram.

Tom..... :)

miryokuteki: Ok, DropBox is being an uber %#$^ about this, so here's the damn URL... God that's annoying.

That's Dropbox for you!

Still an absolutely useless waste of pixels. It is not a schematic.

miryokuteki: If I may ask a secondary question, as I've not run into them before now; What trouble would the decoupling capacitors prevent and/or what is the purpose of using them?

It's pretty damn close to one, if you follow pin layouts. I will draft an actual schematic up later tonight, the harsh response was unnecessary. Thank you for the link on explaining decoupling, however.

It's pretty damn close to one, if you follow pin layouts.

No it is nothing evenly remotely like one. In order to get at a schematic you have to lable all those pins with the function rather than just the pin number. It is irrelevant the physical order of the pins on the chip, it matters what the pin function is.

I will draft an actual schematic up later tonight


I know it’s kinda convoluted, but hopefully it keeps everything as clear as it is in my head… My apologies, I guess I just assumed the PCB etch was as simple to follow to anyone else as it is to me (who has spent tens of hours tweaking it). :grin:

*** It’s probably worth noting that the “to Ext.” leads at the top are for future shift register/port expansion without re-fabricating the entire board.

EDIT: I stand corrected… Found the parts and updated accordingly. Aside from the RGB LEDs actually being RGB LED strips, this is the complete circuit.

Got your transistors drawn the wrong way up!

Not really sure why you have diodes across your piezos. Or 1M resistors.

Need to lose that yellow, too!