I am just wondering if the following calculation is correct or whether i am missing some side-effects of PWM:
Assuming i have 1x 7135 giving me exactly 350mA of current to the LED,
and i have a PWM controller giving a duty cycle 1/350, i get an average current of 1mA.
Then a 18650 with a discharge capacity at 350mA of 3000mAh should give me 3000 hours of runtime.
The only thing that i know is missing here is the supply current of the 7135 (200µA, and only during the “on” cycle) and the controller ic (i.e. PIC12f629: 100µA)
Am i missing some other effects that reduce the battery runtime in this PWM scenario?
(does a continuous discharge of a battery yield the same capacity as a pulsed discharge at the same current, when i do only count the time that the current is actually on?)
Feel free to get technical in your answers, i do know some stuff about electronics and always like to learn more
Well, the 7135 has a nasty undocumented feature… that 100 uA standby current is only if no LED is connected! With one connected, it can draw a couple of milliamps when the LED is OFF.
Other than that and some minor parasitic effects your assumptions are correct.
Well, from 20,000 feet, I’d say your First-Order Approximation seems well within the Margin of Error!
But I did want to illuminate one point: You’re hitting your circuit with 350mA pulses, width-modulated, (not the average 1mA); 1/350 of the time. So you’d plan accordingly… (E.g. you wouldn’t want to hit an RF transistor’s Base with that! Or a pre-apocalypse LED. Or an XM-L either, but for a whole different reason*…)
Batteries can “recover” some charge when Off due to the chemistry (your valence may vary). But generally, you only count the current for capacity measurement when it’s actually flowing (i.e. 350mA pulses, 1/350 of the time)…
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.
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.
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.
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!
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.
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 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.
