TK's Emisar D4V2 review

Don’t know if it was covered earlier in the thread, but is it possible to alter the Anduril source to change the colors of the battery status aux leds? Like change it from the stock blue/green/red to green/yellow/red or green/blue/red, for instance?

could someone please explain how the battery status aux LEDs work? Thanks.

It is a mode you select. The mode will show blue, green or red depending on the battery voltage. The updated UI graphic shows how to select it. When you are cycling through the different aux color/modes there is the slow cycling rainbow and the fast cycling rainbow. The fast cycling rainbow is the battery voltage indication mode. When you finish selecting the mode it will then show one of the three colors.

While I am sure it is possible to do, TK hasn’t released all of the source code files for this model yet (someone correct me if I am wrong).

Just received my D4v2 in SST-20 3000K and wow, it’s a very nice light.

Unfortunately I have found a problem with it:

When I click or click+hold the button from off the flashlight sometimes (maybe 1 in 40 clicks) does not turn on - nothing happens.
The click from the button sounds and feels normal when this happens so I don’t think it is a problem with the switch itself, because it ONLY
happens when I try to turn on the flashlight but never when changing modes or turning it off.

It took me one or two days to notice this problem because it doesn’t happen very often and I wasn’t sure if I made a mistake when playing
with the light and learning the Anduril UI.
But when I picked up the light from my desk and tried to click it on and nothing happened it became clear that something was wrong.

I am using a Sony VTC6 18650. I also cleaned all electrical contacts, this didn’t help.

@ToyKeeper
Do you think this could be software issue? I just found this bug report Bug #1803918 “fsm: sleep ticks interfere with button presses?” : Bugs : Flashlight Firmware Repository which seems to describe a similar problem. I am using the Aux LEDs as battery indicator, though.

Read this post regarding the issue.
https://budgetlightforum.com/t/-/47204/814

The microcontroller wakes up approximately every 30 seconds to measure voltage, and it will not respond to input for a very short period of time.

Please add info about the lens:

~25.64mm x 1.5mm AR coated

Is this bug only there because of the aux leds and them needing LVP? And does this also occur if you turn the aux leds off?

I switched to a static Aux LED colour (green) and it still happens.

It is for LVP so the aux LEDs do not drain the battery below a safe level. It will happen no matter what mode there are in, probably when they are off also. However I have not reviewed the code so I am not sure how TK programmed the feature.

Thanks for the reply Mark.

Well, I really hope this can be fixed. A flashlight that doesn't turn on 100% of the time when clicked is not reliable IMHO. :-/

Changes to the code can definitely fix the issue. If it bothers you it is possible to disable the feature in code and reflash the firmware. Once TK releases the code anyway. I have had it happen once or twice but to me it isn’t bothersome, but I can understand where you are coming from.

Could this be why sometimes when ramping up in muggle mode the ramp goes for a bit and restarts from the floor? It has happened on every single Anduril light I’ve owned or used.

ah crap so no UCL lens for this light. Do you know of any other similar performing lens that do not bump the tint towards green?

When I tried to use my new D4v2 for the very first time it wouldn’t turn on, too. I clicked the switch again and again without any success. Then I unscrewed the battery tube and assembled everything again. Afterwards it ran like a charm without any problems. So, maybe this was the same situation as reported some posts above?

Is the D4v2 the first Emisar with this behaviour ? (sometimes MCU is ‘busy’ checking voltage and does not respond to click)

Yes, older lights do not have LVP for aux LEDs. TK corrected me below.

TK, the sophistication you’ve programmed into this V2 is exceptional! Getting very excited for the arrival of a light on a level I haven’t been in quite some time… almost funny this can happen after all the lights I’ve had come in here!

The free mosquito repellant modes are icing on the cake! :smiley: Thank you for the extreme effort you put in here, once again…

I ordered a plain mineral glass lens from a watch repair site (esslinger.com, never bought from here so we’ll see)

After some initial confusion, i posted the head ( only) back wrapped up in some paper placed in a small box, then inside another samll plastic tub.
the Postage/shipping was only £5.25 ( approx US$6.60) Intl-outdoors stated they only need the head back, and they are/have sent out a replacement ( head)
Was a good job that I asked,as i was going to send the whole order back.

So at the moment ive got a Dvv2 with no head, hopefuly the replacement will be with me soon

Yes, that should be reasonably simple to change in the source code. Or you could change it to use 6 colors instead of 3, which is how I prefer it. That gives a bit higher resolution for the voltage reading.

Yeah, people keep asking me to help them clone Emisar products, and that seems a bit rude… so I keep pushing back the release date. Clones will happen anyway, as they have with all prior Emisar products, but at least this way Hank gets a head start.



Yes, and I have a half-broken light on the way which can reliably produce a related issue I’ve been trying to track down for an entire year. So I’m hopeful that it can finally be fixed soon.

Basically, there are some tricky interactions between the pin change interrupt, the watchdog timer, and the standby mode. It would probably help to figure out a way to detect what woke it up, and then choose whether to run the a full timer tick cycle or a “lite” tick cycle. Can’t run the full one every time because it’d greatly increase standby power use, but the lite version tends to miss button presses once in a while during sleep.

No, if it’s compiled without TICK_DURING_STANDBY, the issue goes away completely. But then it can’t do anything while it’s asleep… like making the aux LEDs change color or turn off. It ends up with a much higher risk of draining the cell too far.

I haven’t found it to be a huge deal during use though. It’s pretty difficult to make the light ignore a click on purpose. On a few occasions, I’ve clicked the thing until my fingers were sore, and only managed to make it happen once or twice. This makes it difficult to test code changes, since I can’t really tell whether the change made any difference.

No actually, it’s not. Anything with TICK_DURING_STANDBY can do this, and that was added more than a year ago. Basically, anything with a “blinking” mode for the aux or button LEDs. It hasn’t come up much at all though, until a couple days ago.

I don’t have a GT-Mini, but if I understand correctly, its problem is a hardware issue. It also has completely different firmware, which has different UI mappings, and some people like it more or less than Anduril.



Nope, that’s because of the thermal settings and thermal sensor. And it has been greatly improved in recent versions. What used to happen was:

  • The thermal sensor was typically not calibrated, so on some lights it got measurements like 35 or 40 C at room temperature. Meanwhile, overheat warnings happen at a default level of 45 C.
  • Muggle mode assumed the light should never overheat at muggle levels, so if it happened, something must be wrong. It then responded by dropping directly to the muggle floor. Instead of doing thermal regulation, it would basically just panic.
  • The thermal sensor has pretty noisy measurements, so it could occasionally get really crazy values.

Add these up, and it ended up sending overheat warnings in muggle mode at times when it really shouldn’t. But things have been improved a lot recently:

  • The sensor values are put through a lowpass filter to eliminate crazy measurements.
  • Thermal rate of change values are further noise-reduced to make it ignore the constant chatter it sees when the temperature is actually steady.
  • Muggle mode has been changed to only step down a relatively small amount when it gets an overheat warning.
  • A factory reset and auto-calibrate function has been added, so it’s really easy now to calibrate the sensor.

So that should pretty much eliminate the muggle panic issue.

Also, it helps a lot with thermal response in general. For example, here’s a before-and-after measurement on the FF E01:

Thanks. :slight_smile:

I didn’t set out to become a microkernel developer, but that’s more or less how things have gone. Flashlights have gotten a lot more complex in recent years. They now basically work like miniature computers, running applications (like Anduril) on top of an operating system (like FSM). TBH though, I’m not really info the lower layers; I’m usually happier sticking to the higher-level application stuff.