Runtime & total output

[neoseikan]

Runtime & total output

A lot of works have been done by great CPF reviews such as Chao, Selfbuilt, c0t0d0s0, Chevrofreak, and BigWaffles. One of the important work from them is drawing runtime curves of so many flashlights. WIth the curve, we can see the different specs easier and more intuitively.

With a reasonable measurement on relative overall light output, we can know more about the flashlight. Fortunately, we have these measurements. Selfbuilt measured the overall output of every lights with his lightbox, so, we can compare the total output ability of different lights now.

With photoshop, every one can get the area size infomation of an area surrounded by the curve and x-y axis. The area size means the total amount of lights from a flashlight.

Here is some runtime curves from selfbuilt, I borrow them to find the hidden specs of flashlights.

Firstly, let's have a look on these 18650 lights.

1- ITP C6: 125595 pixels
2- M20 121333 pixels
3- Regal WT-1 114355 pixels
4- Jetbeam Jet III-M 112768 pixels
5- Solarforce T7 62536 pixels (14500)
6- Jetbeam Jet III ST 58870 pixels

Now, we can see the relative output is:
12.6 -> 12.1 -> 11.4 -> 11.3 -> 6.3 ->5.9
Supposed all of them used the same amount of energy (except for Solarforce T7), the relative output means relative efficiency too.

NOTICE: The efficiency of the same light varies at different output levels or different time point. What you seen here is a relative overall value.

Let's see more.

They are AA lights with Sanyo Eneloop.

Fenix L1D : 140519
Nitecore D10: 116889
Jet I Pro: 106629
Jet I MK IBS: 106566
Nitecore DI: 104617

It's
14->11.7->10.7->10.7->10.5

NOTICE: The Y axis is different with the upper chart, so, the numbers listed here and there means different things.



Any one like this way?

 

[Lermite]

I like this way to represent the flashlights effenciency, but I'd like better a more concrete unit than pixels, something like lm.h (lumens x hours).

 

[Marduke]

You could run the graphs through a plot digitizer, then compute the area of each curve from the polygon formed from that curve.

However, that method still relys on the Y scale from each reviewer and test setup. However, a master list could still be put together which compares the relative efficiencies of different lights if the same common light is used as a benchmark between reviewers (such as the LxD-Q5)

 

[neoseikan]

You could run the graphs through a plot digitizer, then compute the area of each curve from the polygon formed from that curve.

However, that method still relys on the Y scale from each reviewer and test setup. However, a master list could still be put together which compares the relative efficiencies of different lights if the same common light is used as a benchmark between reviewers (such as the LxD-Q5)

Agree with you.

 

[tnforever]

This is basically computing the integral for each runtime plot, but with the runtime graphs not being a specific equation.

It'd be interesting to see how much light could be squeezed out of individual lights at different output levels.

For example, the L0D specs 30 lum (3.5 hrs), 11 lum (8.5 hrs), 75 lum (1hr) for a total output of 105, 93.5, and 75 lm.hrs

Interestingly the light is most efficient on medium mode in this case.

 

[neoseikan]

This is basically computing the integral for each runtime plot, but with the runtime graphs not being a specific equation.

It'd be interesting to see how much light could be squeezed out of individual lights at different output levels.

For example, the L0D specs 30 lum (3.5 hrs), 11 lum (8.5 hrs), 75 lum (1hr) for a total output of 105, 93.5, and 75 lm.hrs

Interestingly the light is most efficient on medium mode in this case.

In fact, most of the X lumens (Y hours) words don't mean a regulated X lumens output lasting for Y hours, but X lumens at the first few minutes and the light can last for Y hours before it shuts down or falls to 50%. That's why we need the integral.

 

[tnforever]

In fact, most of the X lumens (Y hours) words don't mean a regulated X lumens output lasting for Y hours, but X lumens at the first few minutes and the light can last for Y hours before it shuts down or falls to 50%. That's why we need the integral.

Yes, I was just using the listed numbers by Fenix as an example, since I don't have a method for calculating the area under the curves

 

[I came to the light...]

This seems to be the only true way of calculating efficiency. More work is needed to turn this into concrete numbers, comparable across different graphs, but I think this is very useful in interpreting graphs with multiple runtimes charted.

 

[Lermite]

The area computing must not be done from the graph but from the data of the graph.
I use this method to compute a battery capacity by measuring its current during a discharge.
I know the time between each measure and I know the value of each measure.
The result is value[0]*interval[0]+value[1]*interval[1]+...

 

[richardcpf]

Since the LEDs and circuit boards are more efficient when being driven at certain current, a light that can give you 100 lumens for 3 hours doesn't mean it can deliver 300 lumens for one hour. If we compare a light that underdrives the emitter and gives more runtime, using the pixel method we will see that it is more efficient than a light which overdrives the LED and gives shorter runtime.

I could run a Q5 at 350mA, if the driving board's efficiency is ~90%, it'd be drawing around 400mA. At this current it will produce 100 emitter lumens for 6.3 hours with a 2500mAh battery. But if we drive the same LED three times harder, lets say at 1050mA, it won't deliver three times as much lumens and the runtime will be way less than a third of 6.3 hours.

In both charts, the light which delivers least output is the more efficient one. Seeing runtime vs output charts like this could be useful in someway but for measuring efficiency among many lights this is not a good method.

 

[neoseikan]

In both charts, the light which delivers least output is the more efficient one. Seeing runtime vs output charts like this could be useful in someway but for measuring efficiency among many lights this is not a good method.

Exactly. We should consider about this. For example, grouping them as high-output and low output lights.

 

[selfbuilt]

Interesting discussion. Of course, I have an advantage for output calculations since I hold the original data and not just the generated curves.

I have debated calculating actual summed output data at defined time sampling intervals (e.g. ROV.min). However, I have generally resisted this urge for the exact reason Richard pointed out:

In both charts, the light which delivers least output is the more efficient one. Seeing runtime vs output charts like this could be useful in someway but for measuring efficiency among many lights this is not a good method.

A slight difference in initial output can produce quite significant differences in total output when you sum it all up. Even continuously-variable lights can have quite different efficiencies at relatively small differences in starting conditions. More importantly, regulation patterns have a huge effect (i.e. some lights are more or less tightly regulated than others - and direct drive is typically the most efficient, as the examples above noted).

Note too that the exact total output value can be tricky to determine, if you don't allow the cell to run down to zero output (which I only do regularly for protected Li-ions - I certainly don't do it on eneloop, and only sometimes on alkaline). Lights will a long moon mode (especially a regulated one) could be under-represented by this method if you don't let the run continue. You might expect this to be negligible - but again, different regulation patterns may invalidate that assumption (i.e. long regulated moon mode would likely be quite efficient, for that part of the run).

This makes any one number derived from the data potentially misleading. Generally speaking, I think the overall visual impression you get from the graphs typically impart a lot more useful information at glance.

But there are times when it could be useful - particularly, when the runtime pattern of one light is quite different from another (thus making visual comparisons difficult). A good example is in my ICON Rogue 1 review: to get around the rapidly-decaying regulation pattern, I restarted the light at 1 hour intervals. Since it is then hard to compare overall efficiency visually, I did exactly this sort of summed total output over time (results posted in the review). Of course, overall efficiency would have been much higher had I just let the runs go without restarting (i.e. lower regulated output would have been more efficient). The point of the exercise here was just to help you compare the graphs with the rather wonky looking restart runs.

I'm open to the idea of including this sort of summed output-over-time, but I don't know if it really has enough utility in most cases. I am also concerned about the misconceptions that could ensue if people tried comparing summed outputs for lights with quite different regulation patterns and overall outputs. Simple numbers can carry a disproportionate amount of weight in discussions sometimes, even when not appropriate.

Just my $0.02 ... carry on. :wave:

 

[flashy bazook]

Not sure why it is a problem WITH THE METHOD of measuring efficiency if as richardcpf says "In both charts, the light which delivers least output is the more efficient one. Seeing runtime vs output charts like this could be useful in someway but for measuring efficiency among many lights this is not a good method."

Indeed, driving an LED hard may have a cost in efficiency. It may be a perfectly good choice for a given user to go for the higher output and to ignore the lower efficiency, depending on his/her needs. But it is still less efficient!

If may also be the case that driving an LED at too low a current might be less efficient and we just haven't seen it in these particular examples.

Personally I was impressed at the idea of measuring the pixels from a graph (how do you DO that!?!). Where this overall number is useful is exactly to separate those lights that can generate a LONGER runtime by running a bit below some competing lights for a time, and then gradually declining.

Our summary number in the past is often "runtime to 50 percent light output", and it also has some important disadvantages and can be too generous for lights which start lower and then decline gradually (rather than sharply go to off).

So the new proposed measure can be a useful complement to our other measures (static lumen outputs and runtime to 50 percent output).