Great review.
1 Thank
Thanks for the review! You’re really covering the fan favorites around here. I noticed the beamshot pic of the TS10 - future review?
Great review.
I’m surprised by how high the sustained output of it is, I normally prefer FET driven Hanklights but I might just have to get a D4K or DW4 with a boost driver now.
Do you have any plans to review the FET driven DT8K? Maybe with low-cri emitters like W2 for efficiency. I have one and it’s a lot of fun.
Yes, I’m focusing on lights that I find interesting - which tend to be popular with others.
And yes, good eye there - there will be a TS10 review coming soon-ish.
1 Thank
Yes, it is an impressive showing. Personally, I’m a fan of the higher sustained step-down level, which is why I went for the boost. That said, I also like a good moonlight mode, so I get the popularity of the simple FET option.
Not in the short-term, as I have a lot of other lights on hand. I will be posting a D1 review shortly, but it seems to have a boost circuit given the performance (went with the W2 for max throw).
But I’ll keep that configuration in mind for the future!
1 Thank
Really appreciate your reviews here @selfbuilt , thanks a lot!
I added the review tag for you.
1 Thank
The D1v2 may or may not have a boost driver, it depends on the emitter. The W2 (Osram CSLPM1) is a 3v emitter so it has a fully-regulated linear driver (up to 8A iirc), not boost.
The emitters in the D1v2 that get a boost driver are the Cree XHP, Nichia 719a and B35AM and the GT-FC40
1 Thank
Ah right, that makes sense. I’m not familiar with the Osram emitter specs yet, I selected it mainly for the throw. But considering it’s tiny size, it makes sense that it would only be a 3V emitter (and thus no boost required).
I’m working on that review now, but the linear driver is doing a good job of keeping the W2 well regulated.
Thanks I just noticed the review tag - I’m adding that to my review posts now.
2 Thanks
Nice detailed review. However, there’s a few errors: the 3800 lumen “spec” from Hank’s site is for the FET driver. Also, the measured 3150 lumens on the boost driver is way too high.
Hank’s boost driver is 2A per LED.
According to tests the 519A produces 605 lumens at 2A.
So, absolute maximum from the D4K 519A with boost is 2420 lumens and this doesn’t take into account losses from the optic. Consensus is that it’s around 2000-ish lumens.
1 Thank
Yes, I know the 3800 lumen refers to the FET - the boost will be lower. I’ll add a “(FET)” label to the table.
And I agree the 3150 estimated lumen measure in my lightbox is off - but that is true of all lights in my lightbox. The lumen estimate is based on an earlier calibration standard. I’ve maintained it for comparability to all the other lights in my lightbox.
Great review as usual!
One minor correction though… I’m ToyKeeper, not Toymaker. 
smooth Ramping mode (which is the only mode present on the Simple UI)
Simple UI can be stepped or smooth, and has a bunch of other configurable options too. It just requires going into advanced mode to configure things, and then those settings are locked when it’s back in simple mode. Depending on the firmware version, it may or may not be possible to switch between smooth and stepped from within simple mode. Originally that was one of the locked settings, but now it’s usually free to change because manufacturers requested it.
It’s also becoming somewhat common for the 3H mode group to be accessible in simple mode, again at a manufacturer’s request.
dedomed emitters for the complete absence of artifacts (and full flood)
The dedomed version has more artifacts (16-point star pattern at the edge of the corona), and the beam is more throwy. Removing the dome also tends to improve color-over-angle consistency. The unmodified dome-on version has fewer artifacts and more flood, more lumens but less lux.
I measured the standby drain as fluctuating between 45 and 50 uA, but with a very brief jump to ~285uA every 3 secs or so
That’s fixed now. There was a bug in the standby voltage measurement code which kept the ADC powered on longer than intended, and could occasionally produce a failed reading. With that fixed though, the avg standby drain is about 15 uA lower and the readings are more reliable and consistent.
It’s one of quite a few changes which happened in the year since that particular firmware was built. If you have a flashing kit, I’d recommend updating to the latest version. I particularly like the new “smooth steps” / “soft start” feature, which is visible immediately from the very first button press. It’s a small thing, but it has a big impact on overall feel.
Anyway, the intended RGB aux usage is to have them on low mode with voltage color. This makes lights easy to find in the dark, provides a firefly level of illumination, and allows easily checking the battery status of an entire collection of lights at a glance. Runtime in this mode is measured in years, so checking a light once a year is generally sufficient.
the switch backlight and front circuit board AUX RGB emitters can’t be independently controlled
Not yet, anyway. The circuit allows it, but I haven’t yet added a feature to configure them independently. I’m still deciding how best to do that without complicating the interface more than necessary. How would you like it to work?
dynamic range
FWIW, I’ve been working with thefreeman on some new HDR boost drivers – high dynamic range. I think people will really like them. It goes a bit higher than Hank’s current generation of boost drivers, and also goes much lower, with everything in-between. The circuits are significantly more efficient, and output is more stable and more responsive because it generates control voltage directly with a DAC instead of putting PWM through a lowpass filter. It has no ripple at all.
I don’t understand all the details because I’m not an electrical engineer, but he has put a lot of work into maximizing the efficiency and dynamic range… and the prototype I’ve been using is easily the nicest driver I’ve ever used in a flashlight. There’s even a AA / li-ion dual fuel version designed for Eneloops.
Hank often has several different versions of his regulated drivers. I think this one is indeed 2A per LED (8A total), but I’ve seen him use anything from 5A to 12A total per channel. He picks an appropriate value based on which LEDs the buyer selected. So it may be good to ask him.
OTOH, back when maukka was helping people get their light boxes calibrated to match official reference lights, I recall doing some rough estimates on the difference between maukka’s measurements and the industry standard used by Zebralight, selfbuilt, and others. From what I recall, the Zebra scale was about 40% higher. So take the 3150 ZL lm in this review, divide by 1.4, and it works out to 2250 lm.
Some additional bias may be present due to the style of integrating device. Shoe box style integrators tend to favor floody lights, while tube style integrators tend to favor throwy lights. A proper sphere with baffles would be needed to minimize beam shape bias, but those are a bit tricky to build right and often obnoxious to store.
Haha, quite right, so you are - sorry for that Selene! Fixed. 
Tons of useful info there, thanks for sharing.
I was going to ask you about that - I did notice the change, but forgot to update that background paragraph (which I had copied from an earlier review). I had noticed on the Hank lights (and the Wurkkos TS10) that you can access both ramping modes now in Simple UI.
Interesting, thanks. I don’t have experience of dedomed lights with TIR optics, but I don’t call seeing artifacts in the old days (mind you, those were different emitters too).
Good to know. I haven’t invested in a flashing kit, but will probably get around to it one of these days.
I agree, that is an absolutely a fabulous use for the RGB aux. You still get many years of battery life, and can tell at a glance how much juice is left.
I think it’s fine as is. As you know, I like my moonlight modes - so I’m always wondering about having independent control of the switch LED for a basic white moonlight. I think the aux RGB is great as a voltage check, so the simplest thing is to leave as it and just go for the RGB on both the aux emitters and switch.
Indeed they do, which is why I have a small internal calibration correction for full flood lights. It’s not enough to fully correct, but it does minimize the bias somewhat. 
It’s hard to be exact, but I find my lightbox measures (which were based on a number of manufacturers values, including ZL) are typically ~20% above more conservative measures.
Do older versions of Anduril potentially have worse standby times as well? I have lights with Anduril 1 that I could flash to Anduril 2 if there was sufficient reason. Otherwise I have no complaint with Anduril 1 so I’ve just been keeping it.
Some probably do. But I doubt this counts as a sufficient reason, since people aren’t generally going to notice whether their standby time is 3 years or 3.5.
OTOH, lights old enough to not have any aux LEDs (like original D4v1 and FW3A) might end up with shorter standby times after updating. Because old aux-less builds turned off the sleep timer entirely in standby, while newer versions keep the “sleep ticks” timer running to support features like auto-lock and hybrid memory.
1 Thank
I didn’t realize how inefficient red button emitters would be on a earlier Hank purchase. The light has 5000k XP-L Hi emitters that I love but just awful standby time. I might update the firmware for even the tiniest improvement TBH 
Interesting details about the sleep mode. Is there a way to detect that there are no aux emitters? Or is it one of those things where you need to limit unnecessary code for space reasons? I guess either way this is an edge case that noone is likely to notice unless they are looking for the difference.
Oh. If you have aux on high mode in standby, the most effective way to make it last longer is to switch to literally any other aux mode. The newer firmware reduces standby power by about 0.015 mA, so if your aux is drawing 10 mA, that would only reduce it to 9.985 mA. In other words, it might increase standby time from 12.50 days to 12.52 days.
Meanwhile, switching from high aux to low aux would increase standby time so it’s measured in years instead of days.
The firmware either tries to drive aux LEDs or it doesn’t. It doesn’t sense whether they exist. Instead, the code is written to fit the hardware model. If the model has aux LEDs, the code includes a compile flag to use them.
1 Thank
That would help but then I would only ever be able to see the aux lights in a dark room.
My personal preferences clash with practicality on this, I know.
I have another question for the sake of my curiosity. (I’m not looking for a solution to standby drain on high aux)
Is the hardware used for standby regulation the same on the E21A driver? (D4V2 linear driver)
That makes sense as self-adapting or self-configuring firmware would be bloated as heck and probably not very reliable. Is it theoretically possible to code firmware to check for something like an available aux channel? Or is the board layout impossible to deduce logically from what the firmware has access to? Purely hypothetical of course, and assuming there was somehow enough space and processing power to make the adjustments.
There is no standby regulation. It’s just a simple circuit with battery, resistor, maybe a second resistor, and the LED. The first resistor can be swapped out to change the overall brightness, while the second is inside the MCU.
Some sort of solution is probably possible, but it hasn’t really been necessary so I haven’t even tried. There’s a bunch of hardware-specific code and settings, and the presence or absence of physical components definitely falls into that category… so it’s hardcoded per hardware model. If anything, I’ve been moving toward more hardware-specific code, not less… and just recently did a major refactor to make hardware-specific stuff easier and more powerful.
As for making it auto-detect the hardware, it’s as you said:
1 Thank
So it is theoretically possible that Hank could have used different external resistors on different drivers, but if that’s the case then one should be brighter than the other? Makes sense.
Yea the approach I brought up doesn’t really make sense to attempt now and maybe never will. I was just fantasizing about the concept of a universal driver for a line of products. But with the need to keep the hardware cheap and the products reliable that would be a lot of complexity for not enough reward.
Maybe a more useful approach would be a product-line specific AI which could collaborate with end-users to generate customized firmware and interface. It could double as an interactive user manual afterwards. A cloud-based AI of this kind could get basic survey info and make helpful suggestions about what tweaks other people have kept and why.