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! 
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. 
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.
I thought he may be referring to if you were to disable the aux LEDs from within the flashlight UI, not changing any code.
Thanks for the correction!
You got it right the first time.
Older lights don’t have LVP for aux LEDs. That’s new.
The missing-clicks thing is an old issue though. It just seems to be a bit more noticeable when it wakes up to check voltage, since that takes longer than the usual sleep ticks.
I’m hoping to get to the bottom of it soon though, since I should finally have hardware which is capable of triggering the issue in a reliable manner.
[quote=ToyKeeper]
I would prefer that too. Is there any hope that we’ll see that in a future version of Anudril?
—Bob Q
–1, KISS and compact for me.
IMO, I see no need for internal charging in any single 18650 cell flashlight. First of all, the battery doesn’t discharge so quickly. Even if it did, wouldn’t it be more convenient to just swap out the battery? After all, when you unexpectedly deplete the cell, how can you stop and recharge your flashlight? It would take much more time to do that than a swap.
However, internal charging is useful when charging a multi-cell flashlight, where you can charge 3 or 4 cells at one time, rather than taking that many extra cells or a larger charger with you. In the case of small capacity key chain lights where a quick charge is possible, internal charging may also be useful.