Need verification on schematic ...

yup, I saw the stills - looks fun.

Have you seen the Buugeng lessons on youtube ?

http://www.youtube.com/watch?v=Kd1LQnmZxS0 - there is a whole series

Anyway, please let me know how you get on with this project

Good luck

Mark

markaren1:
DATA and CLK possibly need buffers (HC050 spares gates), and 8 x 100R between the buffer and each DATA and CLK to the LED chains.

Coming back to this … how is the lower voltage going to affect the signals? Considering the amount of drivers being used, I figured I’d stick to sending 5V signals down the line. If I use the HC4050, it will drop the voltage to 3.3V.

Also, from the uP, there’s only one pair of DATA/CLK coming out. That attaches to a star-configuration PCB onto which the string then attach. I know the schematic I originally drew has four separate pairs, four separate connectors and what not. But the final design will have two VCC, two GND, and one each of DATA and CLK. Each VCC/GND pair gets split onto two strings. This is why I want to use a higher rated P-FET so I can actually pull the needed amps through it for both strings. I found some dual P-FETs that say 8A, but I don’t know if that’s 8A each channel, or 4A … so I don’t know if I’m using two or just one (for all four strings.) Need to do some more research.

you should be able to drive an LED string powered in the range 3.3 to 4.2V using a 3.3V logic signal without issue.

Include 100R in clk and data of each string, this will slow down edges and reduce current transients in the power supplies.

In terms of selection of P-FETs etc. that is your call, I don’t have enough information to help any further.

-mark

And the N-FET doesn’t need the high amps, correct? It’s just turning the other on.

correct

OK, cool. I think the only two pieces that still need resolving then are the P-FETs and the VBUS line (whether I’m using the same master switch to cut it off, or another P-FET/N-FET combination, which I kind of like better.)

I’ll do some more research tonight and see what I can come up with. Adding the 100R resisters on the DATA/CLK lines on each LED strip sounds like an excellent idea, it saves having to cram them on the tiny controller board. I should see if I can make some room on the strips themselves for the P-FET/N-FETs too … Hrm. Then I’m not running a high current from the controller board, but straight from the battery instead. Might be better that way too.

If you can include power control on each LED strip then you might be able to add 2 x SOT23 per LED strip and bring back a single /enable line - that is an excellent solution.

-mark

markaren1:
If you can include power control on each LED strip then you might be able to add 2 x SOT23 per LED strip and bring back a single /enable line - that is an excellent solution.

That’s exactly what I’m thinking. Haven’t had a chance to sit at the computer yet, celebrating with the kid who received her first college acceptance letter today.

Alas, no go … The strips are very tightly packed already. I’ll figure something out, even if I have to use the four separate SOT23s. Any bad effects if I tie the outputs of two of them together?

Any chance of splitting the strips and feeding each half from a SOT23 x 8

not a fan of // FETs

-Mark

There’s no room to add anything to them, split or not. The only way to do that is to make them longer to accommodate anything. And right now they’re already 288mm long. I need them shorter, not longer.

stacked PCB on the main board, carrying the FET switches ?

Yep, that’s what I’m trying to work towards right now. Although the idea of having the fets on the strips would make more sense. If the strips are to be used for something else, everything will already be there. I think I’m going to sleep over it and see what I can figure out. Hey, thanks for all of your help these past few days. It’s much appreciated. I’ll post back when I come up with an idea of what to do and go from there.

Please see the attached image. Why would one choose one way over the other? markaren1, you suggested the setup on the right, with resistors on each string and I’m not questioning that. What I’d like to understand is why one over the other? (For the record, I followed your suggestion and I have resistors on each LED strip.)

Pls excuse what might be an already answered question but what LED strips are being used ? I ask because when I see data and clock lines going to a strip I think full blown individually addressable, “smart”, probably RGB, LEDs each of which has it’s own WS28XX type controller IC. If so what’s the purpose of the FETs in the strip’s power line ? Why not just command each LED to off ?

Also (if true) does the OP realize that by putting the 4 strings in parallel, all sharing the same clock and data lines, that all 4 strips will look the same ?

Lastly (if true) does the OP realize the problems of using PWM control (to set brightness and/or color) of RGB LEDs in a POV display ? Let me point to Adafruit’s advice re: Neopixels and POV.

http://learn.adafruit.com/adafruit-neopixel-uberguide

Can I use NeoPixels for POV (persistence of vision) displays?
Not recommended. The refresh rate is relatively low (about 400 Hz), and color displays in fast motion may appear “speckled.” They look fine in stationary displays though (signs, decorations, jewelry, etc.). For POV use, LPD8806 strips will look much better (they have about a 4 KHz refresh rate).

Yeah, you are coming in late into this. However, any question is better than no question at all and it can be beneficial to others in the future.

Mee_n_Mac:
Pls excuse what might be an already answered question but what LED strips are being used ? I ask because when I see data and clock lines going to a strip I think full blown individually addressable, “smart”, probably RGB, LEDs each of which has it’s own WS28XX type controller IC. If so what’s the purpose of the FETs in the strip’s power line ? Why not just command each LED to off ?

You can set the LEDs to an RGB value of 0,0,0, however that does not turn off the drivers themselves. They still draw current and when you’re working off of a battery, every little bit counts.

Mee_n_Mac:
Also (if true) does the OP realize that by putting the 4 strings in parallel, all sharing the same clock and data lines, that all 4 strips will look the same ?

That’s the whole point of this design.

Mee_n_Mac:
Lastly (if true) does the OP realize the problems of using PWM control (to set brightness and/or color) of RGB LEDs in a POV display ? Let me point to Adafruit’s advice re: Neopixels and POV.

http://learn.adafruit.com/adafruit-neopixel-uberguide

Can I use NeoPixels for POV (persistence of vision) displays?
Not recommended. The refresh rate is relatively low (about 400 Hz), and color displays in fast motion may appear “speckled.” They look fine in stationary displays though (signs, decorations, jewelry, etc.). For POV use, LPD8806 strips will look much better (they have about a 4 KHz refresh rate).

Myself and others discovered that problem long before Adafruit posted that information. I’ve been working with POV before those NeoPixel LEDs were being made. None, I repeat, NONE, of the WS28x series strips are capable of doing fast POV. An LPD8806 can refresh with 0 delays between each update, taking advantage of the actual time it takes to update the string itself as the needed delay. In my case, I’m updating somewhere around 300usecs per column. I can push that well into the sub-100usecs if I don’t use an SD. With the SD, I purposely slow it down because a buffer read takes about 1100usecs.

Sounds like you’ve got a good handle on it ! I do wonder if the power savings from killing the drivers quiescent current is worth the hassle you’re having. I assume there’s some on/off switch that kills all power. So killing the drivers when On but Idling (no display) saves what expected % of the batteries life ?

Just a thought …

So I’m going to rewind way back here (it wasn’t discussed before, just implied that I wanted to do this.) The reason I want to be able to shut them off isn’t only for battery saving (while keeping the MCU running for programming.) In testing, both with factory made strips as well as my custom ones, if the units aren’t used for a long time, they seem to reset to a ‘default’ state of 100% duty cycle on all three channels, resulting in a blinding display for a few seconds before the MCU takes control of the signal lines and sends an RGB::Black to them. And every so often (more often than less), whenever I turn the unit on, a few of the pixels will light up, sometimes just a few, sometimes as much as the full string in whatever random color. And again, it sits there till the MCU kicks in.

So what I’ve been doing on my test rig, is to keep VCC disconnected from the strings while leaving GND/DATA/CLK connected. I’ll wait for the MCU to come up and has a chance to send that RGB::Black and then apply VCC to the strings. I realize technically this shouldn’t work but amazingly enough, it does. In fact, I can remove VCC at any point and as far as the MCU is concerned, it just keeps moving and sending signals, as if nothing happened, and when I reconnect VCC, the drivers simply pick up wherever the MCU is.

So the plan is to do the same in the final design, have the MCU turn the strings on, as opposed to connecting them to the same main ON/OFF switch. When the master switch is thrown, the MCU comes up, and once it’s able to send an RGB::Black signal, then it turns on the FETs that applies VCC to the strings. This works beautifully on the test rig, so I’m crossing my fingers that it will indeed work like that once the custom boards are made. Otherwise it’s back to square one.

I’m also still hoping for an explanation on the schematic I posted earlier with resistor locations on the signal lines. Why should one do one over the other …

basically it depends on the capacitance that each load presents. As a rough guide < 200pF total, 2 resistors will probably be fine.

-mark