I can reproduce this issue with a D4k with 519a emitters. With the current KR4 firmware I get an immediate stepdown, with the firmware from 2022 not.
Edit 20230515: Strange, but I currently cannot reproduce this issue on my D4K … no unusual stepdown anymore. I’ll do more checks.
I tested the Post-Off voltage LED function with the Rev.710 version, with my model 0136 DM1.12. This function now works super. Together with the option to pre-set the duration of the voltage display, this all functions like a charm. Thanks for this update, a really nice improvement!
I find this hex choice situation a bit confusing. I also have a KR4 Dual Channel with W1 and 519A, but that is a model 0135, and was shipped from Hank (in December 2022) with the anduril.2021-12-13.emisar-d4sv2-tintramp.hex. This now runs on anduril.2023-04-25.emisar-2ch.hex, and that seems to work fine. Why do some of these run the D4SV2 tintramp firmware for model 0135, and others with the same specs seem to run on a kr4 hex? Is that different? What is the difference? Or do I misunderstand something here?
The multi-channel branch is awesome! I love the changes. Both on my dual channel (5700k dd +2700k dd) and single channel d4v2.
having 3 ”channels” accessible through 3C is a dream come true! 50-50 mix, cold, warm. Perfect.
Using the aux as a channel is an awesome feature. I wish it was an option for my dual channel light doesn’t have a proper moonlight level.
6c for brightness ramp style change (stepped or smooth) doesn’t bother me at all for now.
The tactical mode is very well implemented! I like how responsive it makes the switch too. Haven’t tried changing the brightness levels, but it’s pretty good. I might make the 2nd mode a bit brighter, or rather change the 3rd (strobe) to a medium brightnes.
The battery indicator at turn off is great. I believe it only works when aux are set to battery indicator, I would prefer if it were not tied to the aux setting, so it always showed battery level regardless of the color I set my aux at.
Also, when I hit make, it didn’t compile for the dm11 12v that my dw4 with boost driver uses. I hope it comes soon! This one really needs a moonlight channel!!
It would be cool if the tactical mode included adding aux colors to on of its modes 
Thanks for these awesome new features! Anduril is reaching godmode level of user satisfaction!!
Strange, but I currently cannot reproduce this issue on my D4K … no unusual stepdown anymore. I’ll do more checks.
Thanks a lot for trying and also glad it seems to work for you now.
For me it’s still the same unfortunately.
I also tried the hex file from Wolfgirl that she posted here but I have the same behaviour with the immediate ramp down.
Besides that, I think that the latest builds can be found here, same as before:
https://toykeeper.net/torches/fsm/anduril2/
For the sake of avoidance of any doubt I redownloaded the anduril.2023-04-29.noctigon-kr4.hex again and reinstalled it → same ramp down behaviour.
Or is there a different place where more up to date versions can be downloaded?
In the end there was more development happening since the 29/04/2023, I think? 
@wolfgirl42 ot @ToyKeeper , could one of you imagine why this happens?
Hank has changed which firmware image is used for a model before, e.g. the DM1.12 originally had the K9.3 firmware, then changed to the D4S for newer versions. The kr4-tintramp firmware’s header file is just importing the d4sv2-tintramp-nofet config, then disabling the button LED, so that could be the difference. D4Sv2 with 519A or W2 on one channel get the DD FET enabled as well (0136), which is a D4S-only configuration. Overall, both the KR4 and D4S firmware probably get used in the most different lights overall, most dual channel lights use d4sv2-tintramp-nofet, the K9.3 and DM1.12 use d4sv2-tintramp-fet, and a lot of different single channel lights use the KR4 firmware.
Most Hanklights use the same pin layout on the MCU, which is why the emisar-2ch firmware works on most of them, but doesn’t use the DD FET for dual channel lights with it usable (D4S, DT8/K, DM1.12).
Is there a way I could compile a .hex for Hank’s 12V/6V boost drivers from the new multi-channel branch? It only compiles for a selection of models. (Edited typos)
I just can’t wait to add a red “aux channel” to these flashlights that don’t have a proper moonlight (dual channel lights could also benefit from an aux-channel).
There’s some migration that needs to be done to the new hwdef style, then it’s just adding and defining channel modes. Which build target are you looking for - KR4 (0216) or DM11 (0273)?
Ok, that’s what I suspected. It’s 0273, both for the dm11 and the dw4 boost drivers.
Ok, I’ll give it a go, it’s mostly just porting some changes across, no changes to the actual low level definitions of anything hardware-wise.
I apologize if I’ve missed this when I went looking…
While waiting patiently for the different iterations of the most recent A2 updates, I’ve been playing around with the 2023-04-29 versions of the D4SV2, Emisar 2-channel and KR4 hexes and the 2023-05-02 hex for the TS10. I am quite pleased with the updates across that board but I find myself with some things I’d like to either clarify or possibly suggest.
There seems to be a new function where when turning the Hank lights off, either from on or when using 1H & 2H in lockout, the Aux emitters give you a brief display of battery voltage - in the same way you can set the Aux emitters to provide a voltage readout with different colors meaning different battery levels…
BUT - this readout appears to ONLY use the Aux emitters on HIGH. My question here is whether or not I’ve missed something about this function while the Aux emitters are set to low. I set mine up so that when the light is unlocked, whatever color or mode I’ve chosen uses the Aux emitters on High, but when locked out they are on Low. I’ve noticed when I have the light locked out and use 1H for moonlight so I don’t wake the missus, the subsequent voltage readout will use the Aux on High before then returning to the Low setting I’d selected. Is this adjustable so the voltage check is ALSO on Low when I’ve set them normally to Low? If not, can the function be modified to work this way?
As for the TS10 firmware, I’ve found that the manual battery-check reads out the voltage using the Aux emitters, not the main emitters like in my other A2 lights… I find that I VERY much like this! Is this coming more broadly in future iterations?
Many thanks, folks!
The latest version (commit 710) has a threshold set where when the light was last used below that ramp level, it will use them on low instead, currently defaults to RAMP_SIZE/10, i.e. 15, so moon/floor will use low but most normal ramp usage will still use high.
If you set that to a higher level they would stay on low for higher levels the light was used at, or setting it to RAMP_SIZE would effectively always use low, or 0 always high.
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/multi-channel/revision/710
I have some (unofficial, but unmodded) builds from 710 for every currently working target: MEGA
An item to set the threshold could be added to the 7H menu in battery check mode without too much trouble.
If I’m understanding what you’re saying, it looks like this is the solution to my question! Connecting the Aux output to the last used output from the main emitters or the last used output from the Aux emitters… Either seems to offer the solution I am looking for. Very cool!
Thank you for the response - I appreciate you taking the time!
No problem, I enjoy hacking on it to learn, e.g. got the chance to learn some of how dynamic PWM works in FSM and a bit more about writing hwdefs doing this.
Built based on revision 710, aux channels added (main LEDs, red, yellow, green, cyan, blue, purple, white) and all defaulting to enabled, added a third item to the battery check 7H menu (2nd is seconds for voltage to display, 3rd is the ceiling for using low for the battery aux plus 1 (i.e. 0C = cancel without changing, 1C = set ceiling to 0, i.e. always use high, >=151C = ceiling to 151 i.e. always use low). 3C in battery check mode to cycle the channel use for blinkies.
2 different builds here: File folder on MEGA - anduril.noctigon-dm11-12v-aux.hex is as described above, and anduril.noctigon-dm11-12v-aux_4c_previous.hex has 4C mapped to go to the previous channel instead of lock from on. By default all 8 channels are enabled, if you don’t want some of them, use the 9H menu to choose which. Source included.
Forgot to answer this, but yeah. There’s provision in the codebase for always forcing a specific channel for blinks (e.g. a white/UV light with no aux or a single-channel light with no aux and with special custom channel modes that aren’t usable for blinks (some kind of turbo-only or moon-only channel?? would be possible to implement on the new version), I guess), or if there are multiple channels defined, you can use 3C in battery check mode to cycle through the channels that it uses. The builds I posted default to cyan aux for blinkies because you have to set a default to make it runtime-configurable, but if you want to change it you can go through them all including main emitters with 3C.
Hi
I would like to try and make a latest build. I have never done this before.
I am trying to use Breezy on Macos to use Launchpad.
I have installed Breezy, that was ok.
When I start the command, I get the following error message:
bzr branch lp:~toykeeper/flashlight-firmware/multi-channel
brz: ERROR: launchpadlib is required for Launchpad API access. Please install the launchpadlib package.
I do have launchpadlib installed though. by running “pip install launchpadlib”
I think this might be a Python issue.
Does anyone know if I have to install Python 2 for this? Currently I think MacOS only has Python 3.9 installed…
I posted a “bug” report quite a while ago, but noone ever answered to it: Question #706482 “brz: ERROR: launchpadlib is required for Launc...” : Questions : Breezy
I would appreciate any help a lot
Sorry for all the questions here.
Hello all,
I’m wondering if I stumbled upon something documented as a bug or if it might just be an issue on my end.
I have a d4v2 with an early boost driver that I’ve had my own version of A2 on. My primary change was making battery aux 4 colors instead of the rainbow. 2022.07.05.0273_DM11-12v was the compile date/target.
I flashed vanilla 2022.10.21_Andurilv2.noctigon-dm11-12v from TK’s repo and I’m noticing some weird batt aux behavior all of a sudden.
With a low cycle 18650-30q at 4.11v, aux is bouncing from cyan to purple to blue and back to cyan. That’s a huge voltage range so I’m not really sure what could be causing it. Battcheck shows a 4.1v
Edit: I just flashed vanilla anduril.2022-07-29.noctigon-dm11-12v.hex and batt aux looks to be behaving as I would expect.
Hi! I think maybe I had a similar issue (different light tho) as you’re having where the AUX light on Voltage mode would oscillate between non-adjacent colors.
Full details here: Wurkkos TS25 Aux Voltage Mode Issue?
Per TK:
I’ve been trying to track down the source of an oscillating-aux-voltage-LED issue for years, and I think I finally fixed it. Anything 2023-04-25 or newer should have the issue fixed.
See a version on the repo that may work for you to mod: anduril.2023-05-17.noctigon-dm11-boost.hex
Hi
I got a couple of KR1’s delivered before the weekend and did various tests.
I get this ramp down issue on the following lamps:
with anduril.2023-04-29.noctigon-kr4.hex On:
with anduril.2023-04-29.noctigon-kr4-nofet.hex
with anduril.2023-04-27.noctigon-kr4-2chan.hex
3x D2’s and 1x D4K have no ramp down issue with the anduril.2023-04-25.emisar-2ch.hex firmware.
It seems that only the new firmware versions for the tailclick lamps have this ramp down issue I described.
I did not manage to compile an Anduril for myself from the source code.
Could someone compile a KR4.hex file based on the latest changes and make it available? That would be super cool 