To add to what Blinky said, the LED is still seeing 350 mA for the ON part of the duty cycle, so it is not going to as efficient as when actually driven at a constant 1 mA.
Or, if the PWM frequency is very low, it would be too… Blinky :bigsmile:
Thanks for your helpful answers!
I know that at 1mA-average through PWM i have to look at the led efficiency at 350mA.
That’s the reason why i want to design a driver that dims via PWM but uses only as many AMC7135 as neccessary for the brightness.
So when ramping up, it would increase the duty cycle of one single 7135, and when it reaches 100% duty cycle, it stays there and another 7135 ramps up. This should be the best efficiency you can get out of a multiple-7135 driver.
@texaspyro:
that couple of milliamps is very interesting information… this means i have to rethink some ideas that looked good on paper :~
PS:
i don’t think 1mA is too “Dim”. An XM-L at 350mA has more than 100 lumens per watt. so at 1mA average i’d expect 100/350 ~= 0.28lumen. That is a reasonable moonlight mode, there are flashlights that go even lower than that.
Yes, it causes a lot of parasitic battery drain if your light does not have a physical power switch to the batteries.
Good news! This is not true. Maybe other parts of the driver do have this drain, but i measured the current through a “off” 7135 to be exactly 0. (My DMM has a micro-Ampere range and even that stayed at 0.00).
If it were a few milliamps, this would even show up at the led, because you can definitely see that an led is on when there is a milliamp or to going through it.
So as long as i get the rest of the circuit right, the 7135 do not cause me a headache due to parasitic drain.
My idea might still work 
Did you have an LED connected to the driver? Will Quiles first mentioned this to me. I checked it with a bare 71355 chip and LED (no other driver circuitry to get in the way) and saw the same thing. The chip had a low parasitic drain until an LED was in the circuit, then the OFF current went way up. I believe that PilotPTK also ran into this little stinker of a feature.
Sure did. I ditched the exact type of design you’re working on because of that ‘feature’.
Here was a forum thread about it… Custom AMC7135 Driver
I see your numbers, I just don’t think there’s such a thing as a “reasonable” moonlight mode! 
Sorry, not trying to start THAT fight! :zipper_mouth_face: I’m just still trying to replicate that “First SureFire In A Dark Room” sensation.
I really do like your “gear-shifting” idea… If you only had 6 or fewer “gears”, the ATTiny MCU family might be useful, but I’m just speculating. They’re small, cheap and widely understood. Maybe, depending on your “top speed”, to keep the “gear changes” orderly, you could switch in more than one 7135 at a time…
1st = 1 = <350
2nd = 1 more for 351-700mA
3rd = 2 or 3 because brightness and current don’t change at the same rate -> 1400 or 1750
4th, 2 more gets you to 2100mA, not much difference there, which is why I suggested multiples in the first place…
If you let “Pin n” switch in “n squared” number of 7135s, you could hit Angry Blue XM-L pretty easily, on “just” those six pins… (in fact, that would free up a couple for Inputs)
I’m just sayin…
I’m not trying to pun or steal your thunder, just hoping you’ll write more about this neat idea.
Dim
Thanks for your input! Seems my ideas have been thought before
I’ll take a look at your schematics and maybe take parts of it.
I will still stick to a soft-button interface, if i at all can make it work.
That’s exactly what i planned! First i thought of 1, 1, 2, 4 7135’s (so doubling the max current with each new 7135).
But that would take up 4 of my precious pins (in contrast to PilotPTK, i want to stick to a 8-pin MCU, if possible).
I want to have a soft-button (1 pin), battery voltage monitoring (1 pin), and a thermal sensor (1 pin).
(Yes PilotPTK, this is very similar to your design!)
But that leaves me with three pins for controlling the 7135’s, so maybe it’ll be 1, 3, 4 or 2, 2, 4.
My target number of 8x7135 is also quite fixed.
Also i will use a PIC instead of an Atmel, because i already have a PICKit2 programmer + prototype board,
and also it seems from datasheets that the PICs draw less current.
Regarding moonlight mode: everyone’s entitled to his own opinion i like the possibility ramp the brightness down to ridiculously low levels, so that’s what i will allow my driver to do.
Hey! I’m the only Dim one here! As long as you don’t make it blink, I will love it and you for making it!!
You probably already know you don’t have to leave pin 1 on to turn on pin 2, etc. I used to like building gearsets for bicycles, which seems a lot like this…
If it’s 3 bits I think Octal. The hard part will be fitting all the code on the chip. Bitwise operators? Please do keep this thread going!
Dim
About blinking/PWM: I think i see PWM more easily than some other people, so i’ll keep the frequency high enough.
I have a PALight V60, that is nasty PWM. I even think that my Zebralight on lowest mode uses PWM.
With a Nanjg 101AK i could not notice any PWM, and when i hooked it up to my oscilloscope, it turned out it PWMs at 4.4kHz. So if my PWM frequency is somewhere close to that, it won’t be a problem.
About my 3 bit/8 different state control: I know that, but the problem is the logarithmic nature of our eyes.
So the brightness increment when going from 1mA to 2mA will be quite noticeable, but from 700mA to 701mA you will
not see a difference at all.
For the best use of 3 pins you could use them for 1, 2, and 4 7135’s, respectively. Then you can use any number of 7135’s from 0 to 7. But if i have already 6 of them going 100%, that means 0.35 * 6 = 2.1A. Adding the next 7135 i’d get another i.e. 8-bit, 256-step PWM ramp-up from 2.1A to 2.45A, which is totally unneccessary.
It would be best if i could make a perfectly exponential-growing PWM ramp. Maybe i’ll do that. But even if the PWM ramp will be linear, i can keep some of the exponential growth by always adding as many 7135’s as there are already running at 100%.
Anyway, thanks for your supporting feedback! I hope i can get back soon with some further investigation of the 7135-quiescent-current (non?)problem.
I did another measurement. I hooked up a circuit like this:
Li-Ion (+) -> XM-L -> 7135 -> GND (Li-Ion -)
The Vdd (power supply) pin of the 7135 was left open.
I measured the forward voltage of the XM-L, and this is what i got:
At time 0 i closed the circuit.
So there is a current pulse, but a very small one. Direct-driving the same XM-L from an alkaline (1.57V) gives a current of 0.19µA, and the current pulse in the diagram is even smaller. My oscilloscope confirmed that there is no high-frequency nastiness going on.
I’ll benchmark that quiescent current again in a more driver-like circuit (MCU, maybe multiple paralleled 7135’s), but for now i still can’t see any bad quiescent current.
Would anyone who measured that “couple of milliamps” please share their schematics for the measurement?
Essentially the same as yours except for
A) the VDD pin of the AMC7135s was pulled low (to Battery Ground) rather than left floating
B) there were multiple AMC7135’s in parallel.
PPtk
I can’t confirm that effect either, though I didn’t measure it directly.
I setup a driver (NANJG101 with added AMCs; one with 8 AMCs, one with 16 AMCs) with 4 separate control lines, each line had it’s own LED. In that setup I doubt that that quiescent current flows through the VDD since VDD is grounded by the MCU (when that line is off), and I also doubt that that quiescent current flows through the LED, since a couple of milliamps through the LED should yield a visible glow for that LED.
I also made some drivers with an electronic switch, one LED, power always connected to LED and AMCs in series, MCU holding VDD low - no glow.
How exactly did you measure the quiescent current?
I might not totally understand it, but why is the parasitic such a big issue?
/edit: [quote=DrJones] one with 16 AMCs with 4 separate control lines, each line had it's own LED. [/quote]
Yup.. that little beauty is truly a masterpiece. I hope to get my build finished today..
I just measured one of my custom firmware NANJGs in an electronic switch light: 164µA quiescent current in soft-off mode, with or without LED connected. And most of that comes from the voltage divider for battery monitoring.
I meant the OTHER blinking! :zipper_mouth_face: But I don’t even like PWM, unless the light source can do the “persistence” part. (Yes, I’m still hooked on the hot wire…)
But I’m weird that way.
I work on machinery & tools that move dangerously. Take your PWM light & watch a running car engine at night… Scares the daylights out of me, no pun intended!! It’s SUPPOSED to look like it’s moving in a dangerous manner, the better to remind you “DON’T PUT YOUR HANDS IN THERE!!”…
(Ironically, the other blinking actually is useful around automobiles, but in a whole different regime!)
Well, of course it’s going to leak. There’s that big, fat FET sitting right there between Out and GND…
But I was thinking the MCU would drive relays (transistors or big, flappy brass reeds — but you’re not building a sailboat motor controller, are you?) which would power 7135s off as a switch would… Maybe I missed that part. You’d drive VDD directly from your ~25mA output pin? Now I wonder about batches… In parallel, would you be able to turn them all on (the 200uA would be easy, but what about that ~2.7v min. VDD?)? In series, I would LOVE to see the propagation delay scoped out!!! If you (say) doubled your pulse width due to the time it takes all the 7135s to “see” the current, what would that do to your OTF? (See, it’s not the PWM I dislike, but the way the LED presents it…) You’re flipping the (x-number) of 7135s on/off with each pin, right? So the “blip” of current would have to propagate through the batch each cycle? What if you could use that to control the LED?
Just spitballing here, but I was thinking you would need another layer, which would allow you to fully power-off the 7135s and their LED ( s ) … (Yes, as you can see, I see the 7135 as a magic Ilim resistor( s ) dedicated to an LED… But seeing the package like that seems to work for me.) Anyway, if you cut power to the whole 7135, where would your quiescent current go? I think the answer is “away”, but I’m still playing catch-up here…
Dim
Because i want to make a driver with a soft-button, so this parasitic current will drain the battery even while
the flashlight is “off”.
See for example the zebralights:
They also have this drain, but they managed to keep it so small that it doesn’t matter. This is exactly what i need, too.
This looks very promising, thanks for the measurement! At 164µA an 18650 will still last over a year, so this is probably good enough. Also the NANJGs use an ATTiny13A, which according to the data sheet, draws 24µA at 1.8V and 1MHz (idle mode). One chip that i might use, the PIC12F675, has a standby current of 1nA at 2V, and can even operate at 8.5µA at 32kHz. What those datasheet values mean for a led driver we will see, but using a PIC might lower the parasitic drain a bit further.
I’ll measure that configuration, too, but i’m starting to think that maybe you had a faulty 7135 in your batch? Did you perform the measurement only on one batch of 7135’s or different ones?
EDIT: found out by accident that “at” signs change the font instead of showing up as themselves
That’s an interesting thought, the PWM making you not see the movement. But this would only be a problem at very low settings, and in an area where stuff moves dangerously, i would never go for moonlight mode
As soon as i give more than (average) 350mA to the LED, it will always be on, and just vary in brightness.
It might leak more than an open relay, but anything less than a few microamps i can happily ignore
Lets see if i understand you correctly: you are discussing whether i put the 7135’s in parallel or in series?
Series does not make any sense for a constant current chip. You’d get a constant current of 350mA like with a single chip, and also the excess voltage is probably burnt off to heat in a single one, while the others put their FETs in full-on mode. Also, then you’d have to have higher voltages to supply those that do not sit at GND.
The chips will be connected in parallel. Then i do not need higher voltages for their supply. 2.7V min is no problem, as the cutoff voltage for a li-ion should be at 2.8, and as far as i know, the digital output can swing rail to rail.
Regarding the blip of current: That might be a problem at GHz frequencies, not at a few MHz. Also it is not important when a 7135 switches on or off, it is only important for how long it stays on, and that does not vary. So even if the “last” 7135 got the on-pulse very late, the brightness you see would be exactly the same.
If i cut power to the chip, there can be no quiescent current. Current can only flow when there is a voltage driving it.
I can post schematics when i get around to drawing them, maybe those will clear things up a little further.
Replace “i” with “MCU by way of the Output Pins” and you’ll have it all in one sentence!
I was actually thinking of caps (or something) between the 7135s to extend that propagation delay… but I can’t remember now why that was so interesting…
I apologize for the dalliance re: driving them, as I confess when I went to the Datasheet for the smallest PIC I could find, the DC Characteristics table listed the voltage on the Output pins minimum Vdd of 0.7 seemed low enough to be a problem, for batches of 7135s. Their minimum is 2.7v each, but only require 200uA. I just went back & found the PIC’s Maximum is not even listed, and the notes mention an IOH of 3ma, Vdd=4.5, which would drive enough 7135s to make us both silly, so I’ll just go back to paying attention now, and try to stop wandering into RF territory (good catch) anymore…
Dim
(PS: if you replace “LED” with “Industrial DC Motor” you may find another field of opportunity to plow…)
edit due to total brain f#rt in the one sentence that mattered
Another thought about efficiency:
I am going to use this with Nichia-219 LEDs, which have a higher Vf. That means the LEDs are less efficient than XM-Ls, but i don’t
have to worry about efficiency issues with a linear driver (vs. buck). Most of the inefficiency is bundled inside the led, and there’s not much more voltage to lose in the 7135