Fan-Out Capability of the APA102C

Our victims for the day

While playing with APA102C addressable LEDs, I found myself thinking about the various hypothetical lengths of various hypothetical strings of them and how DC has to be carried down to the end of the string, and how you’ve got some amount of propagation delay for the logic that runs through every LED…. And I started wondering about the viability of running the parts in parallel with regard to the logic.

“But Pete, why would you do that? The whole point behind them is to have control of every pixel with a minimum of wiring.” Well, this would be applicable in only certain sorts of installations, I’ll grant you that. I mean, the DC benefits are clear: what would have been a longer, daisy-chained string would be split up into something closer to a star configuration of smaller strings, reducing the number of LEDs that need to be fed per string and giving that last LED in each chain just a little more juice. Propagation delay is also reduced to the end of any given string. But because each parallel string gets the same data, all of the parallel strings display the same patterns. So this trick would lend itself best to installations with repeating, or maybe radial patterns.

How many inputs can you attach to a single output before it goes wonky? To put a label on it, it’s called fan-out, and it’s a spec you just might come across in a datasheet for a digital part. Does the APA102C datasheet tell us anything? Eh… not so much. No spec for output drive capability for CO or DO, no input impedance for CI or DI, and no mention of the term “fan-out”. This isn’t particularly surprising, as they’re only meant to work in a single string and you shouldn’t need to know those specs, right? But one thing the datasheet does say is that it’s a CMOS part, so the input Z for the clock and data lines should be really high (like many megs worth), and the outputs probably can’t source that much current.

Let’s dig a little deeper. I’ve got a bunch of Lumenati boards left over from the prototyping phases of those boards, but I’ve plugged them together into a light fixture for my work bench so I’ll have to separate them all to use them for this test. Tools: scope, meter, brain. I give myself just slightly better than average chance of learning something.

After busting them apart, I put 4-pin headers on all of them and plugged them into a breadboard, shown in the pic at the top of this post. The idea is to get a baseline of performance of the clock and data lines at the output of one board using my Analog Discover 2, then adding boards onto the first board’s output and watching the change in performance, ultimately to the point of failure. Small caveat: I’m not using the scope probe adapter for the AD2. So between the jumper-wire probes and the breadboard everything’s plugged into, I’m probably adding a fair amount of stray capacitance and my measurements won’t be accurate. But that’s fine, as I’m doing more of a comparison and not an absolute measurement.

10k view of the start of the data transmission

The first read of the scope is what you’re seeing above. The blue trace is clock, the yellow is data, the vertical scale is 1V/div and there is no load. What we’re looking at is the start of the data transmission from my ProMini. Each of those blue chunks (that are about 3uS) is 8 bits, so from the left you see the 4 start bytes, followed by 4 bytes for each LED on the 8-Stick that’s going to be feeding the other boards. After those first 8 LEDs get their respective marching orders, the data line goes active with the clock. Both signals are going 0-4.5V-ish. FWIW, my code is sending data for a long string of LEDs because I had them all attached in series originally, so it should easily be sending enough data to light up all of the parallel boards.

Close-up of the data

Getting a little closer in, we see a couple of arbitrarily chosen bytes about 397uS from the trigger point. We learn a couple of things from this capture. First, those leading edges are not sharp, most likely from my jumper-wire probing that’s adding capacitance to the circuit. It also looks like there may be some interaction between the clock and data drivers, given the peaky-ness of the data line during clocks… or that might also be an artifact of my janky probe. Last, the data line stays high between those 2 bytes. That’s my sloppy code at work. Bad dog.

In the heat of the test. It’s much worse to look at than this lets on.

I’ll spare you some of the more boring details of this test. Suffice it to say that I added progressively more boards (14 of them) and the signals got worse, but it never quit. Check out the scope below.

14 boards attached and all’s mostly well

From the above capture, it looks like some more capacitance has been added to the line (which we expect) and the signals are achieving a lower top value (around 4.2V). Again, that charge time is certainly augmented by my jumper-wire probes and the breadboard, but it looks to be increasing. Still, this functions with 14 boards in parallel. But where does it fail?

I don’t have any more boards I can attach, and clearly it’s going to take a bunch more. So… we cheat. I put a 100k pot on the data line and dialed down the value until the parallel board section started reading weird values (as indicated by colors other than white, or LEDs being entirely off).

Failure achieved

The condition that produced the above plot is an additional 180 ohm load on the data line. The data line rises to about 2.3V, making the current sourcing capacity of the output driver about 12.8mA. But check out the clock line when the data line goes high. We’re clearly loading the driver supply, as well as the driver itself, in the APA102C as indicated by the reduced peak voltage of the clock line when both lines are high. Further testing (a second pot on the clock line) showed that the combined output currents of the clock and data lines is limited to that 12.8mA, they can’t both drive that much independently. So each line can’t be loaded with more than about 360 ohms, assuming the loads will be equal from x-number of boards attached to the output, making its max drive current 6.4mA.

OK, so… how many boards can we feed from a single APA102C output? Can I measure the input current on either the data or clock line and divide that into 6.4mA? Turns out… nope. Those inputs are definitely CMOS, which means no DC current path. Oh sure, there’s got to be some leakage current there, but not enough to keep those inputs from floating around 4.5V when not attached to an output that’s actively driving it to some value. I even read the floating value with all 14 boards in parallel, thinking at least one of the inputs would have to be out of spec and pull it down, but no dice.

That makes our answer ALL THE BOARDS! No, not really. But lots, certainly. If you can keep the lengths between boards sufficiently short to reduce capacitance, reflections and such, I’m sure the number is quite high. At some point you would need to start thinking of this spaghetti monster as a really bad transmission line, but small-scale operation looks promising. Admittedly, I didn’t have to run all of the boards off of a single APA102C output. I could have used the ProMini directly, or an op amp as a buffer/driver. But part of my interest is in radiating and repeating light installations using Lumenati boards, so this was the data I needed to verify that operation.

As I mentioned at some point, the desk-lighting setup I had these previously involved with was a series string like you would normally expect. But adding lights in this setup becomes a pain because you have to change the code to accommodate more LEDs. After a year or two, I may not be able to find the code that runs my workbench light. When I put them back together this time, they’ll be in parallel.

comments | comment feed

Via Westline T2B http://www.rssmix.com/