XM-L dedomed by accident (really...)

? I suppose it sort of depends on what he was trying to convey. What I wanted to indicate was that these LEDs are specified for currents up to 3 amps. According to the manufacturer, Cree, they may be driven at 3 amps. So these LEDs are certainly “rated for” 3A.

If discussing the binning process, where you might say they are “rated”… When binned for luminous flux they are binned at 700mA. 3A is about 428% of 0.7A… so yeah. They are rated for 3A and binned at 0.7A. 300% doesn’t really come into play.

Here is an other question.
Consider 2 flashlights. Both are identical except for the driver. Both drivers are of the linear type (for example based on 7135 chips).
Flashlight 1 will deliver 1.4A (4*7135) continuously.
Flashlight 2 will deliver 2.8A (8*7135) and has a PWM signal with a duty cycle of 50%, meaning that the average current is also 1.4A.

Questions:
1- Do both FL output the same amount of lumen?
2- Is one more efficient than the other (lumen/watts)?
3- Is one going to drop out of current regulation first when the battery voltage drops?

Please feel free to redirect me to other threads if this question has already been answered.
These are just a few questions I’m asking myself and I’m curious to find the answer. My guess is that the flashlight 1 will be more efficient but I have doubts.

Here is what I think. Maybe ask comfychair what he thinks if he doesn’t chime in on his own, hopefully others will have input as well:

Flashlight 1 (4*7135):

  • less bright
  • more efficient
  • stays in regulation longer
    Flashlight 2 (8*7135 @ 50% duty cycle):
  • more bright
  • less efficient
  • drops out of regulation earlier

The Vf of the LED at 2.8A is higher, even when the duty cycle is only 50% the Vf is still that way. The high Vf causes earlier dropout. I think it will be less efficient, but I’m not sure about that part.

Ok, I agree about the fact that flashlight 2 will drop out of regulation earlier. Let’s see what others think.
However, I don’t understand why flashlight 2 should be brighter.

Don’t trust my judgment, I’m not 100% today. One should definitely be brighter than the other, I can tell you that :wink:

Well, here is what I think.
If you look at the graphs I posted earlier, you can see that at 3A the LED doesn’t output twice as many lumen as at 1.5A.
I suppose that if you have a 50% PWM signal you get half the lumen.
So in my opinion 3A with a 50% PWM outputs less lumen than 1.5A continuous…
But then again, I may be wrong about that. I never tested that.
Anybody else has an opinion on that subject?

I suspect that you have it right. I’m just not 100% today, so I got it backwards earlier. Your logic is sound.

One thing that has been discussed but never implemented (on a publicly available driver) is having independently addressable 7135’s. This could eliminate PWM in the majority of situations, reduce the drop-out voltage, and make the light more efficient.

On the ATtiny13A microcontroller we often use for custom drivers there are 8 pins. Two are consumed for electrical connections (GND / BAT+). Another is consumed for battery monitoring. For an e-switch light yet another is consumed by the switch. That leaves 4 pins to work with, so to get modes with 12*7135 you’d do something like this: 1x, 2x, 3x, 6x.

Then your mode options would look like this:
12x (6x, 3x, 2x, 1x) - 100%
11x (6x, 3x, 2x) - 91%
10x (6x, 3x, 1x) - 83%
9x (6x, 3x) - 75%
8x (6x, 2x) - 67%
7x (6x, 1x) - 58%
6x (6x) - 50%
5x (3x, 2x) - 42%
4x (3x, 1x) - 33%
3x (3x) - 25%
2x (2x) - 17%
1x (1x) - 8%

For moonlight you’d still need PWM on the 1x.

That is a very interesting idea! And it would not cost much. It would just take a little bit more space to get the pins connected to each 7135 group.
I also wonder why nobody is doing drivers this way… Maybe because people wouldn’t notice the difference.
*
I think I will get a programming card soon… I would love to program a slow ramp up when the light is turned on to avoid being blinded. Also when changing modes. Man I love µcontrolers! :smiley:

Hi Lagman. What are you using to measure current? Many DMM’s come with thin probe wires unsuited for measuring high power led currents so many of us have had to change the probe wires to thicker ones to get more accurate readings. It was surprising to me how far off it can skew the readings.

Hi and thanks for your advice.
I did check the resistance of my probes. I have two DMM: Uni-T UT136B and Uni-T UT61E. The first has a resistance (probes plus DMM) of 190mohms and the second 120mohms approximately.
I realize that this is not negligible. At 3A that’s about 360mV drop. In my above posts I added 10% to my measurements to compensate for that but can you tell me if it’s more or less than that? I don’t know.

Only way I know is to go ahead and substitute thicker wires and see what the difference is. Your 10% is based on a resistance that might be off. In my case the inaccuracy was more than 10% at 3A and even worse at higher currents. 190omh x 3A means a drop of .57V. I wouldn’t call that insignificant when it’s very close to the difference between the voltage of the battery and the Vf of the led and could very easily result in a low current reading.

I totally agree with you. My 10% estimation was based on the fact that I can barely see a difference in light intensity. But it can be incorrect.
I have no way to test the real current right now… I’ll get a clamp meter at some point but not now.
BTW, do you know where to buy good quality banana (4mm) plugs? I want to make special probes for my DMM using silicon wires…

I think this is how PilotPtk's driver (ultimate 7135 driver) was supposed to function. Project went totally on the shelf months ago though I believe - trouble with parts.

That’s correct Tom E, he ran into an errata vs supply problem IIRC. Here is his thread: The World’s Most Advanced AMC7135 * 8 Driver

He stated that his 7135’s were “individually addressable” which I find completely unnecessary for a single-color driver. (maybe he planned to do multi-color firmwares as well). He wanted to use a high-end MCU, USB, etc. His plan had many more barriers than doing this on a simple ATtiny13A. When he ran into errata problems that prevented USB from working he was put in a bind, IIRC there was not enough physical space for in-circuit programming of his MCU.

I think a firmware with a 2D lookup table could easily handle modes for X number of 7135’s. You’d configure 8* similarly to the way I showed in post #32 with 12*. Either way, you need 4 pins to address them in increments of one.
1x, 1x, 2x, 4x
8x (4x, 2x, 1x, 1x)
7x (4x, 2x, 1x)
6x (4x, 2x)
5x (4x, 1x)
4x (4x)
3x (2x, 1x)
2x (2x)
1x (1x)

As you can see, a different lookup table would be required for each driver which had a different total number of 7135s. Now that I think about it, maybe that is why PilotPTK wanted them individually addressable. :wink: Oh well, writing a few lookup tables isn’t that bad.

I think that most people would not understand the advantage of such a driver. And IMO that’s why there is no driver like that… :frowning:
Developing such a driver would not be lucrative as only a few people would buy it.

Several people here develop drivers without commercial gain in mind. Oshpark Projects

Well the advantage of turning ON/OFF 7135's is no PWM's. So 8 chips: high of 2.8A, 4 chips: 1.4A w/clean no PWM's, 2 chips: 0.7A w/clean no PWM's, 1 chip: 350 mA clean....

Also it's been discussed the nature of PWM's is toggling full power ON/OFF which has the same higher voltage demand as 100% power. So if you run with just 4 chips, the voltage demand is lower, therefore the cells will last longer, etc... All around more efficient, less stress... How much? Dunno, but theoretically much better - true direct amps, no PWM's - beautiful thing. I like the idea for sure...

Don’t forget that you can still do PWM on a single 7135 as well, if you are so inclined. I think this will give a much lower moonlight than a stock qlite (for example) is capable of.

I guess somebody should get motivated to design the hardware. I’ve got a fair idea of how to handle the modifications to the STAR firmware as well.

I think PPtk bit off too much - should have left off the whole USB thing... Probably much easier then.

Unfortunately I have no time to tackle with eagle (not to mention programming) but this old idea should’t be too hard to become reality. Especially as OSH park can be used to fabricate pcb boards and parts of existing firmware(s) could be used. Most of us are by now more than capable to reflow few components and program attiny.