TK's Emisar D4 review

I don’t really know how battery voltage reacts to 15kHz PWM , I am just guessing here. I think the experiment will be more conclusive.

Have to go, at this monent no LVP has kicked in yet, the D4 is down to 193 lumen, with a rested battery voltage of 3.18 V. A li-ion at 3.18 V is as good as empty (less than 5%? Who knows exact values?).

Hold on, maybe I’m not getting it, but we want to know what voltage sag is when output is a fairly low 200 lumens, and whether LVP is going to kick in or not right? The question is whether voltage sag is the same high value when current draw is 15A or not (and I claim it’s not: much lower)?

Ok, so why not just measure voltage directly? Let’s say resting voltage is 3.3V (example), and we connect battery to D4’s head without battery tube using low resistance wire. Then we measure voltage directly when output is around 200 lumens, so we know voltage sag immediately or not?

The collaboration of theory and practice makes engineering awesome! :partying_face:

That requires a DSO.
Edit: Even if we can see the voltage, we don’t know how the protection circuit works, maybe it is triggered with one low voltage measurement, maybe it is triggered when seeing consecutive measurements for who knows how long. Wait, my bad, its open source.

Of course. This is the kind of mistake I would have made if I were testing… ugh… :person_facepalming:

Edit:

It’s frequency/algorithm related that the DMM is likely not able to give the correct value (I think). But would an analogue volt meter give the correct value?

To see the voltage fluctuation under 15kHz PWM, we need something with sampling frequency higher than 30kHz, store the samples, and show the curve on a screen.

Yes we do, and I see you figured that out. The most relevant section of the code is here

To sum up for those who don’t read C, it checks for low voltage every 16ms and steps down if it detects low voltage four times in a row. That’s many times slower than the PWM and should be sufficient to prevent spurious stepdowns.

Ok, but the next question is what exactly is observed: what exactly does the hardware see? In reality you can have high frequency fluctuation of voltage due to PWM, but what does the voltage sensor read? Is it able to extract the peak low voltages in a tiny interval, so LVP kicks in, or maybe it only sees an average, so LVP does not kick in? So, something checks voltage, but the voltage is not a fixed value (PWM)…

That will do it! I find a couple of spare ready to go 30Q’s work with this light………….does not take long to get the V down into the mid 3’s. Swap out and carry on the fun :slight_smile:
What would work better is having 3 x D4’s , that way the spare cells are housed for instant WOW :smiley:

My little test was based on this:

Result: at least when using a high drain battery (that is the least what the D4 deserves) you can run rhe D4 at 200 lumen until almost empty.

Assuming the PWM and measurement is not synchronized. So, sometimes it samples at FET off, sometimes samples at FET on, the probability is the duty cycle.

At 50% duty cycle, the expected number of samples to get 4 consecutive FET ON measurement is 14 times, ~0.22sec.
At 10% duty cycle, the expected number of samples to get 4 consecutive FET ON measurement is 11110 times, ~3mins.
At 5% duty cycle, the expected number of samples to get 4 consecutive FET ON measurement is 168420 times, ~45mins.
Hmmmm……
May I suggest to use moving average on the sampled voltage.

If measurement and PWM are exactly synchronized, it could alway be measuring at ON or OFF.

When I said “weak” I meant “low current”, definitely not 30Q. And so I did a test with 18650B charged to 3.6V.
Turn on, 350 mA. Increase slightly, wait short while, no effect, shines OK. Ramp up all the way to turbo - still OK. Gets warm very slowly compared to VTC6. Run fine until thermal protection kicked in, then I stopped the test. It took forever to warm up, like 30 seconds.
So I was wrong, the D4 is fine with a weak cell.

30q fully charged, now the FL works very well, it gets got very quickly :slight_smile:

Yes around 15s from cold, once it been used in WOW mode, heat is almost instant from there on(used within minutes). Glad sorted, worth checking the V a few times after a few uses to get an idea . Then when out, will not get caught out as easy with low voltage if makes sense.

Recently I found another thing about what PWM does with a li-ion. I have a little 10440 copper Maratac with an XP-L2 running at 3A on high, while the little Efest battery at 3A has only 1/3 the capacity of the same battery at 1A (HKJ’s test). It is a simple FET driver so on low setting it alternates (18kHz) between 3A and 0. I expected the runtime to be consistent with the lowered capacity at 3A but instead it was about 3 times longer, like it had experienced a current of 1A or less. I was pleasantly surprised because the lowered runtimes was my main worry of using a FET driver.

I have two possible explanations:

  1. the PWM is so fast that the peaks do not end up fully at 3A, this could be checked on a scope
  2. the lowered capacity of the Efest 10440 at 3A in HKJ’s test is caused by heat, the PWM-ed low setting never heats up the battery.

Or else, something else is going on chemically in the battery.

Tonight’s play things starring the D4

Perhaps in the future it can do that. IIRC, Tom’s NarsilM already does it… but this was kind of forked from an earlier Narsil and simplified.

Thanks! It seems CRI is not completely straightforward, but the cooler-when-brighter trend appears to be fairly consistent at least.

Yes, 7135 chips do not attempt to convert extra voltage into current. They burn off the extra voltage instead. Same with a FET. A voltage-converting driver should be more efficient when the battery is full and emitter Vf is low, like a 219c with a full li-ion cell. The same voltage-converting driver will generally be less efficient when the two voltages are very close together though, and it’ll generally have lower maximum output. Even without accounting for size, there are tradeoffs.

In actual usage though, I don’t generally notice the difference in runtime since it happens in many short sessions spanning weeks or months. Like, I don’t often notice whether it gets 10 hours on medium (D4 XP-G2 @ 160 lm w/ 3500mAh cell) vs 11 hours (Zebralight SC600w Mk II L2 @ 150 lm w/ 3400mAh cell).

Not true, as testing showed.

This is how it would behave if it were a digital system, but it’s not. The behavior is analog. At 200 lm, the FET pulses are not full power. It rests at 350mA most of the time, but has very brief spikes which go higher. As earlier testing graphs showed, though, those spikes don’t reach maximum power until a significantly longer duty cycle.

So at 200 lm, or any medium-high level, the efficiency and tint do not match turbo, and they don’t match the 7135-only level. It’s in-between.

At higher duty cycles, like 1000 lm and above, the FET likely does reach full power during each pulse, but the overall efficiency, tint, and sag are still in-between because there are so many analog components involved. And because it’s still spending part of its time at 350mA, part of its time at 15A, and part of its time between the two.

IIRC, maukka scoped this on the D4 a few pages ago and found that theory to be true. The pulses have a slow enough rise and fall time to act as a very weak lowpass filter, so short pulses never reach full height. (edit: scoped output, but that works because the LED activation time is much faster than the FET driving it)

The voltage samples are taken at clk/128 speed, which IIRC gives somewhat of an analog average of 128 sequential time slices. PWM takes 512 time slices per cycle. To get 128 FET-on time slices in a row, it would have to be at a ramp level of 101/150 or higher (where FET PWM=66/255).

So… the hardware’s measurements have a lowpass built in. And then it has another lowpass in the measurement logic. And another lowpass in the LVP logic. It’s not prone to triggering LVP due to measurement noise. If Tom’s comments are correct, the firmware takes four measurements per second. If four values in a row look too low, and it didn’t step down within the past few seconds, it’ll step down. I think I may see a bug in the code for that, but it isn’t one which has any significant symptoms.

The short version is: LVP works normally, even when the momentary voltage levels change dramatically from one microsecond to the next. Development included real-world testing.

As long as the cell’s protection circuit doesn’t trip, yes. It works fine even on weak primary cells like a CR2032, unless you try to use turbo. In that situation, it will (correctly) trigger LVP until the output is down to a level the cell can manage, and then run happily until the voltage is actually low (low for li-ion).

Anyplace we are keeping suggestions for a V3 of the software?

1) Inserting batter for first time - Make double blink moonlight or not necessary (If you lockout at night with unscrew of cap, blinding flashes in the dark are not desirable)

2) Don’t memorize settings which have shortcuts (moonlight and turbo)

3) Allow for a memorized output setting set by user

Those were a few of mine and another person’s that I really liked. I know there were more, but can’t find them all. Thanks!