I like so much to test things to their limit and Anduril 2 is a gorgeous platform to test. I started with TK and ask for less number of clicks in one time (10C to 1H) and then I asked to StarryAlley in GitHub(he do very cool custom firmware) for aux settings because do 21 clicks from low to off are too much clicks in my opinion but I love aux and I want to use it. Here @dmenezes (thank you so much) try my suggest and now many people are happy. I know chips space are limit to mod the code but 8C is a good solution for using aux more smart. And also the number is not in use.
I test only a TS10 with 8C and is cool. I hope in near future to test a D4v2
2 Thanks
@Light_Veteran, thank you for your testimony and kind words.
This shows exactly why I dearly love Anduril in particular and the Internet and all things opensource in general: thanks to them, you were able to voice your original idea (again, thanks for the suggestion), I was able to implement it, and then @AK-Adventurist, @jon_slider and others to test it, which allowed issues to be found and investigated, and then @SammysHP dived in and was able to trace the issue to a much more fundamental problem in Anduril and promptly provided a fix, which I then incorporated, @AK-Adventurist tested and approved, and here we are with everyone happier and wealthier for it. And yes, I do mean “wealthier”: I think about opensource as collective wealth, “commonwealth” in the original and best sense of the word. And that with us spread among different countries, different languages and cultures, and having never physically met (and probably never will).
None of that would be possible without our ladies @ToyKeeper’s original and continuing work in Anduril, and @wolfgirl42’s expert and helpful answers, and this wonderful BLF community that hosts us all.
And of course we all have Richard Stallman[*] to thank for his foundational efforts with the GNU Foundation and the free-as-in-freedom software movement: none of us would be doing what we do today without him. As a personal note, I vividly remember the first time I heard about him and his ideas: it was in 1985, when I was still a few short years into my career as a computer guy, in a Computer Language magazine interview. I read and reread it a couple of times and it was so new and revolutionary that I tried to find fault in his reasoning, to no avail; I ended concluding that it was a great idea, but it would never work outside of purely academic settings because the big corporations that controlled everything (IBM etc) would never let it work. Then came the Internet, 386/BSD, Linux and the rest is history.
Few times in my life I was so happy to be proved wrong! 
[*] yes, I know he has issues, some of them serious, and I would probably not like him as a friend; but this doesn’t diminish the greatness of his ideas and efforts re: opensource.
1 Thank
In accordance with GPL and in order to keep everything in one place, here are the sources I used to build the above:
- @Toykeeper’s anduril multi-channel rev 725: ~toykeeper/flashlight-firmware/multi-channel : revision 725
- @SammysHP’s fix for ADC setup/config issues: 725-SammysHP_ADC_fix.diff · GitHub
- My fix to 1) above, needed to avoid a compile-time error if
USE_SIMPLE_AIis#undefined: 721-fix_undef_USE_SIMPLE_UI.diff · GitHub - Latest (last?) version of my implementation for the 8C-quick_aux_switch functionality: 721-8C_quick_aux_switch_-_20230616.diff · GitHub
A) was buit from 1+2; B) was built from 1+2+3+4.
@ToyKeeper
Another safeguard I’d recommend is to stay in lockout when the LVP triggers. Lockout is already kind of “off” and leaving it could cause more harm when the button is pressed in the pocket and LVP got triggered by accident due to a wrong ADC measurement:
diff --git a/ToyKeeper/spaghetti-monster/anduril/anduril.c b/ToyKeeper/spaghetti-monster/anduril/anduril.c
index ab43df6..d8df57b 100644
--- a/ToyKeeper/spaghetti-monster/anduril/anduril.c
+++ b/ToyKeeper/spaghetti-monster/anduril/anduril.c
@@ -373,6 +373,13 @@ void low_voltage() {
set_state(off_state, 0);
}
}
+
+ // stay in lockout mode, it's already kind of off,
+ // leaving it could cause more harm
+ else if (state == lockout_state) {
+ set_level(0);
+ }
+
// all other modes, just turn off when voltage is low
else {
set_state(off_state, 0);
3 Thanks
Hi dmenezes, glad to hear you voice. We’d love to do that. But could give us some clearer guidance steps? I’m worried that we will caused the new issues due to not good at language and our poor technology.
1 Thank
Hi Terry, nothing to do for you. The driver is fine. It was a bug in the firmware.
Aaaaaand that’s our man Terry from Wurkkos! Great to hear your voice too, my friend!
@SammysHP’s answer is exact and precise: no action needed from Wurkkos.
To sum it up for you: TK latest Anduril code had a weird issue in just one of your lights (the TS11) and meantime worked perfect in all others (TS10, TS25, FC13, etc) so I erroneously concluded that it must have something to do with some design failure in the TS11, but @SammysHP proved me wrong by finding and fixing an ADC-related bug way deep into Anduril code that made the issue go way and with his fix the latest Anduril now works in each and every light we tested, including the TS11.
Thanks for chiming in and being always available to help! 
1 Thank
That’s great to hear. Terry will keep follow this post and always on call ; )
We love to serve for knowledge lol
3 Thanks
Thank you!!!
I understand that the first link is the modified version of the current branch.
And that the second link is the same with the 8C.
Correct?
Yep, if by “modified” you mean with Sammy’s ADC fix.
And that the second link is the same with the 8C.
Exactly!
1 Thank
Hello all!
Just wanted to check back in, that last hex @dmenezes compiled of @SammysHP’s fix did indeed have no issues on my TS25, not a flicker anywhere on a fresh 21700, nor any with the 18350.
And the TS11 is still fine too, although I’ve not actually been using it, that’s the beauty of the fix; its stayed locked just laying around all weekend!
Now if I could just get people to understand when I tell them “no its not” when they come along and say “hey dude your flashlight is on”… Lol
1 Thank
My wife is always telling me my flashlights are on due to the aux lights. I just say thank you.
1 Thank
Thanks for the report, glad to hear everything is working!
Re: people thinking your lights are on due to the auxes, perhaps have a t-shirt printed with “NO, MY FLASHLIGHT IS NOT ON” so when people say it, you can just point to it 
Little confession: I play a lot with the auxes on my flashlights, but when it comes to final configuration I always have them off – because I myself find it disturbing to have them on when the flashlight is supposed to be off. So that t-shirt would apply to me to 
5 Thanks
And now with only 8 clicks… unbelievable!
3 Thanks
I just say “it’s like a standby LED”, people either get that, or seem surprised that a light would have one of any kind. When even some mainstream lights have lighted switches.
3 Thanks
LOL so your shamed me enough that I’ve started using my TS10 aux leds as a bedside-location help and they’re working great for that. And 8C does indeed make it perfect for quick switching them on when I go to bed, and back to off when I wake up… talk about eating our own dogfood – and finding it delicious
1 Thank
Is fast with memory! I hope @ToyKeeper insert this command or a simple command to do this.
I have to try it!!!
Thanks.
1 Thank
To whom it may interest: @ToyKeeper just released a couple of new revisions on her Anduril multi-channel branch, the latest being rev.728: ~toykeeper/flashlight-firmware/multi-channel : revision 728; checking the changelog, it incorporates @SammysHP ADC fix discussed above, plus some other interesting stuff, so I downloaded and compiled it to test both with and without my 8C-quick-aux-switch mod.
Unfortunately, even in its pristine state it leaves both my Wukkoses (TS10 and FC13) completely dead: no blinks, no response to button presses, don’t even respond to the unscrew-out-then-screw-back-in-with-button-pressed factory reset procedure; flashing rev.725 again brought both back to life. So I guess something is wrong with rev.728, at least for the Wurkkoses TS10 and FC13.
Will wait for the next revision and if it’s fixed, will report here – hopefully with new sets of hexes.
EDIT: just opened a bug report on TK’s launchpad: Bug #2027882 “rev.728 multi-channel branch: totally dead on Wurk...” : Bugs : Flashlight Firmware Repository
1 Thank
Have you read the changelog and understood what it says?
refactored how channel modes are defined, and converted emisar-2ch build
All other targets don’t work at the moment. Don’t forget, it’s a development branch.
2 Thanks