I think something about this all has gotten lost in the fuss.
The real issue here is as much the low modes as the high ones. People use PWM FET drivers for hotrod lights, but the reason it has a driver at all, and not just two wires, is because they still want to be able to turn their light on to say 0.5A sometimes. What this mod does, is just make sure that 0.5A is still say 100 lumens when the battery is down to 3.7 v as it was at 4.2 So when you're not hotrodding, you can always get a predictable brightness. It's not all about efficiency. Of course yes these tripple circuitry boards can also do that part of things regardless of which is more efficient. On the other hand, you can do this method with existing, very simple, drivers that you can actually purchase now(using option 1).. and a bit of software (but it doesn't write itself and no, I probably won't be doing it, just an idea).
Given how Moutain Electronics will program almost any firmware under the sun per order, I can't see how they would be intimidated by having a version of a firmware like this for a few different LED's, thus allowing option 1 simply by emailing them the software no? In that case there is NO hardware change and the only thing this does is fix one of the most commonly stated negative aspects of one of the more popular types of drivers. It just doesn't seem like a big deal. Maybe the new Texas tripples are better. I can believe that.
Change it. You will never see difference between fet and good buck with empty cells (when battery voltage is lower than led Vf on listed current). Voltage drop will differs by several mAs.
If your goal is to get some kind of regulation cheaply, you might as well just use cell voltage and a compensation table (or code). Yes, it will be LED specific but it can definitely be done and requires no extra hardware. It doesn’t have to be as accurate as a typical linear driver to be useful. Even something very basic like giving every mode a PWM % for a 4.2V cell and cell V at which PWM becomes 100%, with linear interpolation, would be better than nothing at all. Change the interpolation and it can probably be called good enough.
Indeed I think a software solution is the better option here. It is much simpler and actually makes sense as well. Honestly you can’t even tell a difference between a few hundred lumens with the humen eye anyways, particularly when it happens slowly over time.
A pretty basic compensation mode for the PWM would work quite well to keep visual brightness close enough.
Exactly my thinking and linear is good enough. On the other hand why not do it properly in a more usual linear representation. What you described defines a line with a +bx of course, you just have to do the algebra to convert it to that form. And while at it might as well put a +bx +cx^2. Use preprocessor defines for a b and c and if c is gets set to 0 fine, then it's linear. If you later bother to work out quadratic parameters to match the led a little better, then great. The programming is no harder. Doing it this way the 100% threshold almost defines itself automatically.
pseudo code:
while true {
turn_switch_on(); // 100% duty factor during adc read.
sleep 100 micro-seconds; (maybe)
pulse_V=readadc(blah);
pulse_current = a +b*pulse_V+c*pulse_V^2;
duty_factor = min ( mode_current/pulse_current, 100) ;
enable_PWM(duty_factor);
sleep(30) ;
}
So duty factor goes to the lesser of 100 or the amount actually needed.
And in 8 lines of code plus 4 constant defines you have free power regulation!
If you're really clever with calculating your constants, you can try to instead calculate brightness vs voltage and aim for constant brightness instead of constant current, but whatever.
I don't have experience with these drivers, but I've done quite a lot of programming (most of it not so recently), especially at algorithm level, so I'd be happy to review or help with something if somebody did take it up and get the structure in place.
I just noticed the H17F on mountain electronics. Wow, not exactly a "budget" item.
Like I said, depends on what you mean by "buck". The usual meaning involves an inductor and is more efficient. Cap charging losses are not only related to the quality of the cap. If you charge it through a wire (resistor) then you charged it through a wire. The simple electronics 101 example of charging a cap up through a wire to a battery voltage from zero of course shows that you lose exactly 50% of the energy, no matter how good your wire (or ESR of the cap) is. (The exact same thing is true when filling a bucket of water). I'm not saying a purely switch and capacitor regulator is that bad. It's not of course.
As for not arguing, that sounds fine. You may have noticed that the previous two posts were about the purely software solution using existing analog inputs.
It’s possible but not quite that simple. You have to deal with fixed point arithmetic and with your pseudocode you’ll likely be pulling in 16-bit multiply and divide routines which will add significant size to the firmware. There are probably more efficient ways to get the same result but they are not trivial to work out. I did something similar in my firmware and code which looks as simple as your example took hours to write and test. Just because it looks simple doesn’t mean it actually is.
It's true, I'm (mostly, not entirely) used to working on computers that actually compute, not these little bit flipper machines. But experience/reuse is the best tool in programming, be it other people's or your own. I'm sure examples abound. I didn't intend to imply it's no work.
and I think that 8 bit fixed point would be good enough, especially if the squaring is done unsigned and 2.6V is subtracted from everything first, but that's my guess.
I was interested in what the actual relative efficiencies were for dimming a FET driver with PWM vs using linear regulators (7135s), so I did some tests. I estimated output of an eagle eye X6 with XPL HI V2 3B using ceiling bounce. The drivers I tested were a FET-only driver from mtnelectronics, and a H17F driver that has a 8x7135 channel and a 1x7135 channel. In all cases, to measure the current, I charged the 30Q cell, used it in the flashlight for a set amount of time then recharged the cell to measure the charge used in that time and used these numbers to calculate an average current. This method gets around the potential inaccuracies of measuring current that is being pulsed with PWM.
In the tables below, the first column is the measured current. The second column is the lux I measured in my ceiling bounce test, and the third column is proportional to an efficiency of sorts; the lux divided by the current. For the FET driver I measured 100, 50, 15, and 5 modes. For the H17F, I measured the 8x7135 mode and the 1x7135 mode.
So the 7135s are indeed more efficient than using PWM on the FET driver. In the 3A range, using the FET driver with PWM uses ~17% more power. In the 0.37A range, the FET driver setup uses ~42% more power. These numbers are significant, but the difference is not as great as the ~64% quoted in the LD-2 thread. I think the difference comes from the fact that they assumed the output of the PWM-dimmed light drops linearly with duty cycle. My tests show it drops more slowly. For example, when the current drops from 5.88A to 2.58A, a factor of 2.28, the output drops only by a factor of 1.92. The drop in output is less steep probably because the LED junction is less hot at 2.58A than at 5.88A.
Very neat, and probably enough to be pretty convincing, although (and not to criticize) there are still possibly some mild issues with the test/reporting. The problem is averaging non-linear functions. The linear driver keeps a steady current, say 3A. The PWM averages over a changing current, say 4A to 2A. But the average of efficiency at 2 and 4 is not the efficiency at 3; it's something worse than three. This also depends on how you averaged LUX anyway (time weighted? Just measured a few times and averaged? were the runs short enough none of this mattered? If so you could still measure charge well? )
To really have high confidence you'd need some repeats of at least one point, especially for low current if you used less amp hours there, but there are hints in the FET data that it's probably all ok. The low current difference is impressive actually. The high current difference is less clear and/or less impressive.
Until/unless we see some cheap tripple drivers though (are there any?), the ability to have controlled modes in a simple DD driver still seems useful, but just if someone wanted to do it obviously. Anyway, I'm leaning toward analog control now, but for my next series powered bike light plan, not for a single cell light.
I’m not sure I follow. For the 50% PWM mode I did the test for 2min, the lux started at 51 and slowly went down to 49. 86mAh were used, which means the average current was 2.58A. For the 5% mode, the test was for 10min and the lux stayed constant. 37mAh were used during the 10min, which means the average current was 0.22A.
I probably didn't explain myself well, but that's ok. Anyway, those measurement times are short enough that non-linearity shouldn't be an issue.
I'd worry instead then more about how reproducibly you can measure such small battery discharges. Again though the consistent FET readings seem to give some evidence that's ok too. Repeating one test would give corroboration. What would also be interesting is to know how closely your tailcap readings match the battery drain measurement for PWM. I wouldn't be surprised if it's not so bad actually.
So this is going to be able to in principle pump about 24 amps through the driver and it seems they like it that way so that they can use fewer cells if desired.
I suppose they could parallel out 32 AMC7135 chips, 8 for each LED, and maybe they should be doing that. That would probably add $10 to the cost of the light at least (just my guess). But a PWM feedback would at least give it controlled modes for that super expensive 50 amp FET they've got on it, even if it doesn't help the efficiency any.
Very nice TA. Easyb I agree with fixed those mesaurements are very nice. In fact, they are so nice, that maybe they deserve their own thread.
It would be neat reference data to see the non-thermally diminished efficieny as a function of current to really know the limits of what to expect even with the best cooling. I'm sure cree knows this already.
So to do this you need regulated voltage and current supply, and you regulate down to X amps.Then you PWM it to say 200mA average current. First though you measure lux at 200mA 100% duty factor and call that 1. Then you compare the lux at 200mA PWM average (doesn't matter probably if it's off from that even significantly, so long as it's low) from each initial current and find its relative value. This would make a really nice plot I think.
You are right to think there might be some uncertainty in the charge measurement. With a different light I did more 10 minute tests with a low mode. I did the test 5 times and got 32, 35, 36, 34, 35mAh. So there is a 2-3 mAh uncertainty. I also retested the 8x7135 2min test and got 2mAh more (99mAh) than the first time (97mAh).