Thinking about those batteries in the context of a really big LED tail light for a bike leads to wondering about the variation in LED forward voltages; it’s possible to drive LEDs in parallel if they’re well-matched for forward voltage. A quick-and-dirty test is in order to get some first-pass numbers… and I have bags of nominally identical red and amber LEDs.
Applying a fixed voltage that produces 20 mA through 14 randomly chosen LEDs of each color, then measuring the voltage across each diode:
LED | Red V | Amber V |
1 | 1.895 | 1.939 |
2 | 1.893 | 1.921 |
3 | 1.903 | 1.918 |
4 | 1.895 | 1.921 |
5 | 1.891 | 1.918 |
6 | 1.935 | 1.906 |
7 | 1.891 | 1.926 |
8 | 1.904 | 1.930 |
9 | 1.901 | 1.923 |
10 | 1.894 | 1.927 |
11 | 1.901 | 1.914 |
12 | 1.894 | 1.939 |
13 | 1.901 | 1.933 |
14 | 1.903 | 1.925 |
Minimum | 1.891 | 1.906 |
Average | 1.900 | 1.924 |
Maximum | 1.935 | 1.939 |
Pushing 20 mA through the five lowest voltage red LEDs requires 9.54 V. Applying that voltage to the five highest red LEDs produces 18.2 mA.
Putting those two strings-of-five in parallel with 9.52 V produces 40 mA total: 16.6 mA in the low string and 19.9 mA in the high string, all measured with a fancy Tek Hall effect probe. No, those aren’t reversed and, yes, I did check twice: it makes no sense at all.
Temperature matters a lot in such measurements and I wasn’t controlling for that, plus I didn’t have a constant-current supply. Better numbers await better instrumentation, but I think binning a couple bags of 100 LEDs based on forward current should be straightforward.
I’d probably try tracing the I/V curves of the two highest and two lowest voltage ones. Given the unexpected results of running strings of them, I’m guessing you’ll find at least one curve that isn’t like the others. On the other hand, I also have sacks of LEDs, I could do this too.
As long as they’re not hand-plotted, count me in. I briefly thought about modifying the MOSFET tester, but, given the low currents and higher forward drops, I think a breadboarded one-transistor tester with cannibalized firmware is in order.
Must. Not. Build. Robotic. LED. Handler.
Dang, another project…
Over the last half-year, I kept hoping for an “aha” moment explaining the bizarre I/V behavior of the strings. Plenty of entertaining reading on how to to generate and plot the curves, and plenty of data on LEDs from those bags, and I didn’t see anything unexpected in it. I suppose this is just going to be one of those mysteries. Granted, I haven’t bothered trying to assemble a pessimal set of data from the plots and trying to regenerate the conditions above, but since the data looks well-behaved, I don’t think that would work anyway.
Nothing that can’t be explained by a total screwup: it certainly wouldn’t be the first time I’ve measured something that wasn’t there. [sigh]
Mostly, I’ve been poking those LEDs with a long stick, waiting for something to leap out at me. Hasn’t happened yet, so I may actually be forced to build something. After I finish pestering them for more data, of course…
Did you ever consider whether you might not be better served selling the Wouxun batteries to someone who actually needs them on Craigslist and using the proceeds to buy something standard and easier to work with? Less fun, I know. :)
Trust me: that thought never crossed my mind… [grin]
I can still assemble a complete radio from the parts, which could be a Good Thing.
Back when the ICOM Z-1A HTs still had functional battery packs and I didn’t realize how delicate their jacks were, we would sometimes ride to a public service event and turn into pedestrians-with-a-radio. The Wouxun has lithium cells that should last longer and the jacks have a protective plug plate, so maybe that’s less of a terrible idea than it was with the ICOMs.