So the Golisi is a decent improvement- but the downside to that is turbo now unleashes what feels like a nuclear reaction inside! 
Instant heat that increases very rapidly - so no doubt turbo is brighter but it will also be temperature limited a lot quicker. Previously I could run it on turbo for longer before the heat built up to that “very uncomfortable” level.
… hence why Anduril tends to be so aggressive about thermal regulation during turbo.
Imagine that same amount of heat and power … but in a much smaller host which gets hotter faster. The original D4 earned its reputation as a fire-starter.
Then imagine that much heat, in such a small host, and it doesn’t regulate itself. That’s what the very first batch of D4 was like. It shipped with RampingIOS v1 firmware, which didn’t really have any thermal regulation… just a timed step-down at 45 seconds… at which point the light was well beyond the spec’d thermal limits of several of its components. It was hot enough that it had a tendency to burn the user, even when touching it only long enough to click the button to turn it off. People were wrapping insulation layers around the battery tube so they could hold it without hurting themselves.
That’s also a big part of why Anduril has no unregulated turbo without physically holding the button down. This mostly prevents people from letting it overheat, because they’ll instinctively let go to keep their skin from blistering before the light gets hot enough to damage itself.
A modern D4S is pretty mild in comparison.
5 Thanks
I wasn’t going to let it get too hot to check out how well the self regulating temp works. (I think I’ve got it set at 55C, but haven’t check the calibration.)
I’m almost in two minds as to which battery gives it the more desirable characteristics- the Golisi is great for showing off (for very short bursts) but the protected Klarus perhaps more practical for everyday use. With the Klarus, turbo can be used for longer periods - even if it isn’t ultimately as bright as the Golisi on turbo, it is brighter than the Golisi on the highest non turbo setting. (It’s a D4SV2 with 4 x W2’s.)
I guess it’s like the debate when I ordered over whether to get the boost driver or stick with the 12A FET. Ultimately I wanted to be able to get the most output I could, even if it was only for short bursts. By interchanging batteries I’ve got more options.
Hey toykeeper,
I have an idea, and thinking always about 1 year. The Temp check function and the battery check function is not easy to use and identify. In my own daily enjoying with rarely use these two functions. Now there is a Voltage mode in Anduril2 aux, I love it (Although I need to spend a lot of time to experience it to remember which specific color means the voltage of which levels.)
Could we add one Temp mode for Anduril aux. I think that would be super cool. The aux color would changed follow the nuclear reaction inside.
1 Thank
The colors are the same as a rainbow:
I have avoided a temperature mode for the aux LEDs. There are a few reasons why:
-
With only 6 colors, temperature would be very approximate… and people can usually feel temperature much more accurately and across a wider range with their skin. I don’t think a 6 color temperature gauge would offer any practical benefit, and the measurement does not update often enough to make a satisfying animation.
-
Measuring temperature in standby mode causes slower updates and higher power usage, because it must switch back and forth between voltage and temperature… and the first measurement is bad after switching. So it would be 4X slower, or 4X more power, or 2X slower and 2X more power.
-
There is an unresolved issue with noise in ADC readings while asleep. This does not happen often, and I cannot make it happen on purpose, so it has been difficult to investigate. It can occasionally generate warning events inside the light. This is fine for voltage, since it merely turns the light off (when it was already off). But for temperature…
-
There were problems in the past when the light could generate overheat warnings while asleep. That can be fixed of course, but the issue was bad enough last time that I don’t really want to risk it… especially when there may not be any benefit.
So I don’t plan on adding it. But I have some other ideas for things to do with RGB.
3 Thanks
Thanks for your detail reply lol
“Measuring temperature in standby mode causes slower updates and higher power usage.”
That’s definitely disastrous for flashlights, please allow me to withdraw my recklessness.
Also, I heard the new ideas with RGB? That’s amazing! How about new mode like “flowing water drops”? Oh my godness. Can’t wait to see that. I will follow your voice always my queen.
Well that was weird af…Gonna try and move past that…
I can think of another reason not to make that feature. Somebody out there is gonna be messing with temperature just to watch the colors change. That’s probably not something youd want to encourage.
Im imagining somebody getting the light super hot then throwing it a snowbank/freezer/cold water and then getting it super hot again to watch the pretty colors.
Just use the golisi and set the top of ramp higher.
1 Thank
I’ve always stressed the variable introduced with cell choice, so easy to hand a muggle your hot rod with no fear when you’ve governed it with a cell that just can’t cause damage. 
1 Thank
I ain’t handing over nothin lol
4 Thanks
I haven’t played with that setting in the past, but figure Hank may have set it up at a certain “safe level” for each given flashlight’s specs?
It’s user-configurable for a reason.
You’ve already discovered one of those reasons. Different batteries have different performance. Hank doesn’t know what kind of battery you’re going to use, so he couldn’t tune it very precisely even if he tried.
Hank didn’t set the default ceiling level though… I did. And although I try to provide sane defaults, I don’t know what hardware models Hank is going to use the firmware on, or what variations the user is going to order, or what kind of battery they’re going to use. So it’s up to the user to tweak things to meet their individual needs and preferences.
And if there’s anything hardcoded which doesn’t fit right, like maybe the ramp shape was calculated for a 5000 lm light but you’re using it on a 1500 lm light, so the ramping doesn’t look like it’s very linear… the source code is available, and I put the ramp calculator’s parameters in each build target. People can copy/paste that command and modify the parameters to generate a more appropriate ramp shape.
Anyway, don’t be shy about configuring and customizing things. That’s kind of the point of providing so many options. The defaults are just a starting point, an educated guess about what might be suitable for a new user.
3 Thanks
I was amazed when I first looked into the code at how easy it was to understand, when most microcontroller code just tends to become an unreadable mess. I still need to learn the ramping code better though.
There is a temperature aux mode in starryalley’s version (also ported to mine - at the moment I’m partway through a project to make generating a custom image easier) if anyone was interested in doing it themselves, but I’ve not extensively tested it, and ultimately agreed that the thermal management in anduril is so good it really isn’t needed.
From my point of view, as being more oriented on the practical side of using an flashlight and less on the hobby part both the battery check mode and display of voltage levels of the aux in Anduril 2 is a bit unintuitive.
Imho Zebralight has the best and fastest feedback approach for batt check (This light uses 1 to 4 flashings of the main LED to give a rough estimate of
the remaining capacity of the batteries).
The same could be done for the aux lights.
4 flashes = 3.9-4.2V = green aux (green is good)
3 flashes = 3.6-3.9V = yellow aux (still quit okay )
2 flashes = 3.3-3.6V = red aux (battery on the empty side)
1 flash = <3.3V = pulsating red aux/blue aux (battery depleted)
I used a ZebraLight style battery indicator in the mid-2010s, but I found it didn’t provide enough detail. Then I tried using a variant with 8 blinks instead of 4, but it still didn’t really tell me what I wanted to know, and I kept forgetting which lights used 4 blinks and which used 8, so it was hard to tell if 3 blinks was high or low.
So I switched pretty much everything to volts-dot-tenths. There’s still an option in the code to use an older display style, but I don’t think it works any more. Perhaps fixing / adding that would be a good project?
The battery colors are easier to change, by editing a small table matching voltage levels to colors.
BTW, did that battery rainbow image show up for you? On one of my computers it’s showing me a broken-image icon, but on everything else I tried it seems fine.
I agree with ToyKeeper here, as much as I like ZebraLights in general, the 4-flashes voltage indicator is wayyyy too coarse. 3 flashes can mean ~75% or ~50%. That’s quite a difference.
Whoops I hit the delete button somehow.
All I said was I’d even take more significant digits if it was accurate enough. Two more decimals places. Blink out 3.921v
It could probably add one more digit, but even that would be difficult. It would need much more precise user calibration of both the slope and the offset of the linear conversion function, and the extra precision would not really be available most of the time since flashlights are very electrically noisy environments and the measurements vary wildly.
Oh ya for sure.
My dt8 with all w2’s came in the other day. I put in a new high discharge cell, battery check, 4.1v. Turbo’d a few times in row, burned my hand a little, batt check immediately after, 3.3v…3.6v…3.9v… ok now 4v lol. Took the battery a sec. Ooo I should set the aux lights to battery check and do that again.
God help everyone with a dt8k lol. I pray for them. Man that thing gets hot on turbo.
Yeah, it’s a little crazy TBH.
As for aux voltage mode though… I’m probably going to be working on that today. I think I found a minor bug which makes standby mode use slightly more power than necessary, and may also reduce the stability of measurements sometimes. So I’m going to try to fix that, and if it works, I can probably make it check voltage more often while still using less power than before.
So after using turbo and turning the light off, the colors might update like … once every second or two, instead of once every 8 seconds.
I’m also debating whether I should make RGB aux low mode actually use high mode for a few seconds after turning the light off. That would make it easier to see whether it’s green or yellow. The red channel is really dim in low mode, and there’s nothing I can do about it, but maybe a couple seconds of high mode might be a good workaround.