Amen to that, brother! And not just for people like us, but for everyone. And anyone that feels uncomfortable they could get their Anduril lights in an unworkable state by random clicking, just ask and I can work out a “Simplicius” mode for them to replace the already simplorian standard “Simple” mode where they would have to click the light “I’m not stupid” in Morse with exact timings to get into Advanced mode 
1 Thank
I have found that you really need to wear (thick) gloves or wrap your light in a towel if you want to set the temperature accurately. Even holding an Aluminum light in your hands for ~30 seconds is enough to heat up the body and the sensor will be off 1-2°C later when the light drops down to ambient temperature.
Maybe this was a fever dream, but did I read in one of these threads that it’s possible to make a build with aux LEDs on a second channel?
I’m thinking if some mod ideas… say the D1v2 for example. With the boost driver it doesn’t have a low moonlight mode. So throw a TIR in there, add some white aux behind it, and steal the aux power from the lighted switch. Is it possible to reconfigure A2 to be able to control the aux LEDs a little easier than with cycling through low, high, blinking, off with 7C? Can the power level of the aux be controlled variably like it were on its own channel?
Thanks for posting. I had the same dream.
If it is possible to make the TS10 Aux ramp up and down in brightness, I would like to know how to do that too.
agree… I dont hold the light in my hand, I leave it sitting on a wood table… but even the voltage readout process can raise internal temp… so I recheck again later, after the light has been off for a long while.
bottom line for me, if the light is off by 1C, its close enough…
Yes, that’s possible with the multi-channel branch. Unfortunately there’s only high brightness. While it would be possible to add low brightness as well, it will never be possible to get another brightness than low or high.
1 Thank
In the default builds, RGB aux LEDs are included as extra channels, and can do all the same modes as the main LEDs. However… brightness in those modes is just “on” or “off”, because the channels don’t have the ability to ramp.
You could add PWM on aux LEDs to enable ramping, but it’d generally have to be done using software tricks instead of hardware PWM, because the aux LEDs are usually not connected to MCU pins with PWM functions. This involves catching timer interrupts and flipping a register, and the result is a little noisy.
If you’re willing to connect LEDs to a PWM-capable pin, ramping would be a lot more feasible. Basically, twiddle a few registers on boot, define another channel in the hwdef, and it should let you 3C to change channels and use the extra LEDs the same way as the main LEDs.
So the TL;DR is: Yes, it’s possible … but
4 Thanks
I would take that as a No… lol
Aux lights have such lousy artifact beams its hardly worth the trouble imo
otoh, for secondary lights with a clean beam… ramping could be really cool
for a light such as the TS10, maybe a single RGB mounted in the Center would produce a relatively clean beam to use for actual illumination.
1 Thank
That’s a great idea IMO – even better if that aux RGB LED could be placed behind a TIR of his own. But right not I don’t think there’s space for that in the optics… :-/
not ideal Aux beam but maybe better than stock,
Zumlin posted his mod to center mount single color LED behind the stock optic on a TS10, pics here
2 Thanks
If it is possible in a single channel model, since the microphones have a minimum of two PWM channels depending on the model and it is only using one.
But by firmware it could not be done, because they are connected to another pin.
You would have to change the Aux to a free PWM pin, in this case it would be the secondary channel, it is like a D2 dual channel or D4K dual channel, but that second channel would be the Aux.
But I repeat, you have to modify the hard, unsolder the Aux cable and solder it in the second channel, in addition to the Aux amperage control etc.
I have explained it without giving electronic details.
In short directly without modifying the hardware of the flashlight you could only use levels as before.
I say it electronically, you know that I am still learning about flashlights but electronics is the same for all fields.
Thanks for the link, looks amazing and perhaps (with a red aux) would even serve for the purpose of preserve-night-vision close-by illumination. @zumlin, would you do one of these on demand? If so, please PM 
1 Thank
Thanks for all the great info, everyone. One other question, and I would normally try to look this up myself but I just don’t have the time these days. Is it possible to reconfigure a build so that when holding from off, it first turns on aux-low, then after a second it turns on aux-high, then after another second it turns on the main emitter(s) and begins to ramp from the lowest level? If you get all the way to the main emitters the aux leds would be off.
The goal here is to give easier access to aux for use as illumination. Again, for this niche use case the particular light doesn’t have a true moonlight mode so the intent is for the aux low/high to take the place of that. Getting to the main emitter bottom-of-ramp would take a couple extra seconds but for this use case either aux low/high would likely be your intent if you’re holding from off. A single click from off would behave normally. 7C would behave normally for toggling the aux.
ime Aux are no good for illumination because the beam pattern looks like this (on a TS25)
1 Thank
There’s no reason they have to have ugly beam patterns. What I’m thinking of would be a more involved mod or build.
If you’re building it, or modding, can you give it a proper moon mode?
It may even be possible to connect the main LEDs to a pin and a resistor in a manner similar to how the aux LEDs are connected… and then you’d have a main LED moon mode which can run in a completely passive way, even with the MCU asleep. It’d basically be a white aux LED channel with a nice beam pattern, and runtime could then be measured in years.
That brings back the original question though. No, it doesn’t currently have any features to use aux at the bottom of the ramp. The aux LEDs are mostly used in 3 ways:
- While in “off” mode, aux low mode is intended to illuminate the light itself, to make it easy to find in the dark. This is also sometimes bright enough to work as a “firefly” mode, and see things up to 2m away. The color additionally indicates the battery charge level.
- While in lockout mode, the aux LEDs blink to show that it’s locked.
- For a few seconds after turning off the main LEDs, the aux LEDs light up at their higher brightness setting, to show voltage by color.
With the main LEDs connected for use like an aux channel, the “firefly” mode should be more efficient and provide a much more useful beam than the RGB aux… and with the right resistor value, it could stay on all the time, as long as you charge the battery at least once per year.
Or you could allow somewhat more power through, connect it to a PWM capable pin, and use the extra-low channel as just another part of the ramp. It wouldn’t be as efficient, but it’d make the bottom of the ramp lower and smoother.
3 Thanks
That looks a lot like a flame fractal I made for wallpaper a long time ago…
2 Thanks
That’s aux rgb lep fractal😂
1 Thank
I’ve found its actually not too bad. In a dead dark room, since my lights are on high aux all the time, I tend to just grab it and aim, and its not much more useless than any other 1 to 5 lumen moonlight out there… good enough for finding light swicthes anyway. I mean, with such a small amount of light that only travels about 3 feet anyway, the pattern doesn’t really matter. YMMV.
But then, I only do it because its already on… I find normal moonlight modes absolutely useless, except for conserving battery in power outages, I never use it, and rarely then.
I’ve been going back and forth in my mind about whether having a distinct “low” level on an aux channel would be worth the code space or not.
See if there’s a "save target as " type context menu item, but here they are for this one and I’ll try to remember that - pushing lots of blobs to git isn’t particularly good as a best practice but I’ll figure something out that’s easier to automate. Really I should stop procrastinating set up a proper server to drop all of that stuff on.
Factory calibration
This has been on my todo for a while, I wrote a proof of concept but I’m still not happy with how it works, but I’ll definitely keep it in mind as something there’s demand for.
I’ve tried it because menus are really annoying with a single aux color. You can’t see the flickering or when it switches to the next item. But what threshold? You don’t have the definitions available in the hwdef. Also ramping doesn’t feel that great with only two levels.