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.
2 Thanks
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
2 Thanks
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:
- KR1 SBT90.2
- SFN-60 6500k
- SFN-60 5500k
with anduril.2023-04-29.noctigon-kr4-nofet.hex
- KR1 SFT-40
with anduril.2023-04-27.noctigon-kr4-2chan.hex
- KR4 Dual Channel
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 
Thank you Wolfgang
Very much appreciated!
I will install it tonight when back home and will post how it worked out.
1 Thank
Thanks again, Wolfgang
Unfortunately the ramp down is the same or similar on my KR1 SBT90.2 also with this version of the Firmware.
Since I can’t program, we might have to wait for Toykeeper on this item 
Maybe someone else with a KR1 or KR4 can reproduce this issue?
I tested it on my fork of the dual channel version and wasn’t able to reproduce it on either light I currently have running it (single or dual channel). Then tested the latest revision (711) on my KR1 (W1, not SBT90 though) to see if it was something odd and hardware-specific, and couldn’t there either. The main variable is the FET, as there are SBT90-specific firmware images for most lights as that does need the FET, but max regulated power is at level 130. I have a SBT90 DM11, I’ll try and test that later with the noFET firmware, but I’m wondering if that’ll be the issue. So far there aren’t any FET-enabled multichannel builds.
Thanks Wolfgirl
Super nice that you had a look as well 
I don‘t know what this is, but I can reproduce it on all of the lamps I listed above, all tail clicks.
Also SFT-40 nofet. 0211 and 0212 lights.
Drives me crazy 
Can I ask you to send me your version of the Kr4 firmware as well, please if ok, I would then try that as well.
Maybe best to recognize this phenomena is if you go into ramp level 7, after 10 seconds it goes down to something like ramp level 4.
It becomes most obvious when you run your light on ramp level 7 for 5-10 seconds and then switch your light off and directly on ramp 7 again.
Then the difference becomes obvious.
Thanks so much and great!
That no fet firmware works on my KR1 SFT-40 without immediate ramp down 
The light came as 0212 from Hank —> so no fet.
Could you send „your“ version of the FET version 0211 as well? Maybe that one works.
Whenever good for you 
Thanks again!
Edit: the KR1 SBT90.2 with „your“ nofet version ramps down here.
There aren’t any official multichannel builds for FET lights yet, which is why I’m guessing this issue happens only on the SBT90 lights. I was thinking about working on porting one to it, but it might just be easier to wait.
1 Thank
Hi Wolfgirl
Yes sure. I hope the info I sent helps for debugging. Happy to provide more info and testing if helpful. I am getting pretty good at using my little flashing tool 
Thanks for all your support already. It’s great how you do this
I wish I could get breezy to run on my Mac for compiling…
Because the names came from the first model to use a given firmware… and then Hank started using the same code on other hardware because the hardware was electrically compatible. So the naming has become a bit of a mess.
He’s not doing anything wrong; he uses the right firmware for each hardware model. But the naming scheme wasn’t really designed to handle being repurposed on other hardware models, and I’m not sure what to do about it, if anything.
I’m not sure if you saw it, but this is what I’m using on my D4K-boost light:
http://toykeeper.net/torches/fsm/anduril2/anduril.2023-05-17.noctigon-dm11-boost.hex
I’ve been using it for 5 days now without seeing any weird behavior.
Yeah, it doesn’t feel done yet. It could really use some extra polish.
2 Thanks
I’m seeing that here too. Have been trying to debug it, but I haven’t found what causes it yet.
The D4v2 build works fine, but KR4 ramps itself down. It ramps down because the KR4 is getting non-stop overheat warnings… I’m just not sure why.
And it only happens after doing a factory reset. When simply flashed and then turned on, it works fine. So it seems something about factory reset is messing with the thermal parameters.
I’ve been going over the two builds with a visual diff tool, and making as much of it as possible exactly the same. But even after eliminating virtually all differences between the builds, it still has the issue on KR4 and no issue on D4v2.
This seems like one of those cases where it would be really nice to have an actual debugger, like running the code in a simulator and examining the internal variable state directly to see what’s happening.
4 Thanks
Hi Toykeeper
Thanks so much for the answer.
I can confirm that the ramp down only happens if a 13C factory reset was done after flashing the new firmware.
I just reflashed the KR1 SBt90.2 and there is no ramp down.
I did the 13C always after flashing before, trying to be extra diligent… 
I wish I could help with this issue.
Unfortunately it seems that my python installation on my MacBook is a complete mess and I can‘t get breezy to work…
Let’s see what I can do…
I’ll give that a try, thank you!
I asked someone about that, and unfortunately seems it’s going to be a massive project as there’s nothing that’d be off the shelf usable. I need to find some time to get back onto the devboard idea…
Ah, this explains why I wasn’t able to reproduce it then, I usually don’t bother to reset after flashing as I make builds that already include my settings as defaults.
1 Thank
I hadn’t seen it, THANKS!! I love it.
-
Boost driver flashlights with front aux are now all throw+flood flashlights
(very dim flood only, set to r+g+b “white”) -
Having an easy to access aux-moonlight on Hank’s boost driver flashlights is so nice. No more messing with series of 7clicks (or going to lockout) to switch between dim and bright aux for illumination purposes.
-
We can set a strobing colors now :
– enable an aux channel || (ON-9H … 1click to activate)
– get to strobe mode || (OFF 3H → 2C until you get to the strobe mode → adjust strobe speed with 1H or 2H)
– switch to the aux channel || (ON 3C)
— I was surprised to find out that 3C worked in the strobe modes
-
Police strobe… that’s a fun one! I’ll refrain from using this in public, unless I need a cop’s attention…still risky.
Did you change the ramp shape here too? Or am I just imagining that it’s visually more linear now? If yes, what rampcalc parameter did you use (just curious)?
Great update!