A few off the top of my head:
Back to topic: This is a great flashlight with some minor issues. There is no big company behind it. You cannot buy it on Amazon. Are there even normal people who have bought this light?
•
•
are there normal people that have bought this light you ask? Do you think it’s within the realm of possibility that some ‘unaware’ purchaser of this light, might put his light in muggle mode, and then leave his residence to go to work, come home and find his home burned to the ground? I think several posts here have already proved that to be a very real probability, and an alarming one. I hope all purchasers can be reached by mail with the warning - this at the very least.
How can i tell if I have the muggle mode bug? Can it be determined by order date?
It is my understanding that all currently shipped D4v2 lights have the muggle mode bug.
Basically, if your item shipped before yesterday, and if it has a muggle mode, it most likely has the issue. But to be sure, you could put it in muggle mode and wait. It should start blinking after ~15 minutes.
That’s already happening. Aside from a few hours to sleep, no time has been wasted in letting people know and working on ways to resolve things.
I also want to help the community so if someone has the buggy firmware I can reflash the corrected one in Hungary for shipping back cost.
I haven’t read through the entire thread since this was posted, but mine is the same way. Quite weak.
Update:
And now I have read the full thread and I’m up to speed on the firmware. Makes my magnet concern less so. I unscrew tail caps, so not a huge concern, but I would be interested in a fix that accommodates dummies like me. Also, does anyone have a comprehensive list of lights that use Anduril with this bug?
Refer to post #2:
“No other Anduril-based lights are affected. It is only the first batch of D4v2. And no other modes are affected… just muggle mode.”
I finally received my tan D4V2 SST20 4000K + SS bezel - same as in the picture on first post. It worked right out of the box with no issue so far.
I already own a couple D4V1 so was not particularly interested in the hot rod aspect of it and mainly played with the new RGB aux leds. I got confused at first with the seven clicks hold/release routine but sort of figured it out. Real nice addition indeed.
One artifact of the RGB aux leds is that when you run them on low and select a composite color involving two colors - like cyan which is green and blue, depending how you look at the optic you can make out the two components. That sort of makes the aux leds multicolored and more complex/textured.
I don’t care about the muggle mode bug. This is not a light i intend to lend. I’ve got plenty of safer lights for that. Good to know about it though.
I think the D4V2 would have been better named the “D4 Deluxe”.
Real good work Hank and TK! 
PS: now i really miss aux leds on the D18… 
I seriously feel for you TK, having to deal with what I would call a non-issue that is being blown so far out of proportion. I vote to eliminate muggle mode altogether and force people to take responsibility for their own actions. None of my 15 or so Anduril lights have ever seen that mode.
Went on a short vacation recently and took Ham’r with me. Ended up needing a night light for my son and ran the 5 driver 17 emitter light in moon mode all night for two nights, cells were still showing 4.13V when we got home. Love the flexibility of this firmware, thank you again for upping the ante on my e-switch lights!
Still debating as to whether or not to mod my D4V2, I really find it a very complete light as is and the tint from these Nichia’s is spot on! Running the mid-compact 18500 and quite happy with it. My new “gold standard” for stock lights. 
(yes it’s gold, sand, wheat, champagne… whatever, looks Gold to me)
Exactly. It’s only the D4v2, because it’s the only light with the new LVP-during-sleep function. This makes it change the aux LED color to match battery voltage, and also makes the aux LEDs shut off if the battery gets too low. It was kind of necessary since the aux LEDs are so bright.
The problem is, when I made it do the voltage measurements during sleep, it also enabled temperature measurements during sleep. They share an ADC channel, and it goes back and forth between the two every other cycle. And that would be fine, except apparently the temperature sensor goes totally bonkers while asleep. And even that would be fine, since the “off” modes ignore thermal events and the light resets its thermal history upon wake-up… but muggle mode wasn’t ignoring thermal events when it should.
So it requires a curious combination of different things to all happen at once before it fails. And no other light has that exact combination.
Hopefully no others ever will. I made it stop doing temperature measurements during sleep, and made muggle mode be more careful about checking when to respond.
Same here. And originally, the D4v2 was going to ship with no muggle mode. It was taken out during most of development, then added again at the last minute because people were asking for it. It makes sense for such a hot light to have a “safe mode”… except, thanks to the bug I missed, it didn’t turn out so safe.
… and that’s a big part of why I didn’t notice the issue. It’s a mode I never use except for testing once in a while. So it doesn’t get much real-world use… just lab-style testing. And the test plan didn’t include not using it for an extended amount of time.
I second this about a gesture of goodwill or compensation and I am still waiting on confirmation of the bugs being fixed as I am ready to order a 6500k one!
I didn’t get any email but glad I am checking this thread for regular updates.
I appreciate your work TK and Hank!
Keep it up!
I’m all for people offering flashing services or Hank selling head assemblies at cost to affected buyers.
Yes, all the other modes are fine.
Is it possible to make the aux LEDs fade between colors with the firmware, or is there a hardware limitation preventing this?
I have 2 of these early D4v2s. Although I seldom have use for muggle mode, I am concerned about the possibility of accidentally putting my light into muggle mode. Suppose that instead of clicking 7 times to turn off your auxillaries, you accidentally click 6 times and are in muggle mode without knowing it. (That has actually happened to me, so I don’t believe this situation is far fetched). You leave your light and come back to a destroyed light and perhaps your house in flames.
Then what about if you sell your light or give your light away. The next user would be vulnerable to the same danger and you might be liable.
These lights have a warranty and should be reflashed under that warranty. Perhaps, all of them should be recalled.
I really don’t want to be reflashing these lights myself. I wish there was someway this reflashing could be done in the USA,rather than shipping my lights back to China, but if it comes to me having to do the latter, I have to do it. I just can’t live with a potential ticking time bomb.
It seems TK and Hank are well on the way to sorting the muggle mode problem. Thanks for your positive actions. However, there are two aspects of it that I do not understand. I would be more confident of any proposed fixes if these aspects were made clear:
Why does the light not come on by itself with a fully charged cell?
Why does the thermal regulation apparently fail when the light does come on by itself?
It’s technically possible, but not really worthwhile. Fading requires using PWM on the three color pins, but they’re not on PWM-capable pins. So it’d have to be emulated in software, which means it would have inconsistent pulse timing and wouldn’t look as smooth. More importantly, using PWM requires that the control chip stay awake, so it would use significantly more power. It’s more efficient to just leave the aux LEDs on; dimming them with PWM would not reduce the power used.
So… it could be done, but it would be tricky, the fade would have visible noise in the signal, and it would drain the battery faster. Not really worthwhile.
I’m not sure why the temperature measurements fail in sleep mode, but it seems to be voltage-related. It’s actually pretty surprising that it’s getting such weird values, because the reference manual recommends doing the measurements in a sleep mode. However, it recommends a different sleep mode dedicated to noise-reduction while doing analog readings. It wouldn’t be the first undocumented behavior I’ve run into, but it is perhaps the weirdest.
The reason why thermal regulation doesn’t work after the issue happens is because the light is still asleep. It can’t generate PWM signals while it’s sleeping, so it can’t dim the emitters to any in-between levels. Also, since it’s asleep, everything is massively slowed down. Instead of measuring 4X per second, it was measuring just once or twice per minute. And instead of the event handler running at 62 Hz, it runs at 8 Hz. Instead of PWM running at 16000 Hz, it’s effectively running at 4 Hz. So it does try to regulate, but it runs in extremely slow motion.
Since Muggle Mode has been fixed, I see no need for its removal.
I’d like to get get an idiots programming kit to fix my D4v2.