I looked it up and it seems to be supported by Anduril’s stable “anduril2” branch, as “blf-q8-t1616” [1]
That branch’s latest revision is 657, released on 2023-03-28, so if the date your light blinks after the model number is older than that, you might consider upgrading to it. [2]
And as the stable branch is, well, stable, it should have minimum breakage risk – and anyway if something is broken, you could just flash it back to its current firmware as you wisely already backed it up
It was blinking as switching on/off on same brightness and colour, showing the battery status. Now that behaviour is gone.
I will try to play around with this a bit more and reproduce the issue and let you know.
Thank you. My DM1.12 has SST20 (2700k) in flood and W1 in the throw channel.
I might try the different versions and try and measure the output to compare, which might be interesting for other users as well.
One question: I assume boundary level means the maximum output possible (150 being max/turbo). Why could it not be 150/150, to get the max out of the light?
That should be fixed with my ADC patch that got merged recently. Which build date / revision are we talking about?
The boundary levels I listed were the maximum output for the regulated channel. If the boundary is 120, that means:
The idea is to make the ramp appear visually linear. If the boundary is in the wrong place, the ramp will have an “elbow” where the slope visible changes all of a sudden. This pic shows how the ramp should look (on the left), and how it looks when the boundary is too low (middle) or too high (right):
Ohhhh… that makes sense. I haven’t actually seen that issue happen, so it didn’t occur to me. But yeah, that bug could definitely cause a blinking battery indicator.
Failed readings would, if I recall correctly, be counted as zero… so it would randomly alternate between a correct voltage reading (color) and zero (black).
As this seems to indeed be affecting other users eg @Light-Chris, may I suggest this fix be backported/retrofitted into the stable “anduril2” branch?
I myself can do the backporting/retrofitting against the latest stable rev (657 as of now) and post the patch here, plus a full set of binaries for all lights that build.
Just posting my volunteering here in advance, so in case someone else gets down to it, we don’t end up duplicating work.
Personal preference here, but I tried both and I like emisar-2ch-fet better on my DM1.12s, and k9.3 on my K9.3. In general, I want a larger regulated ramp so having the ceiling at 130 gives more resolution, then to go to turbo when I want maximum power; I rarely really use levels 131-149 other than ramping through them, so for that use case emisar-2ch seemed better (although maybe I should compare the lows more, I guess).
Not sure about Hanklights as I don’t own any yet, but the lowest lows on my FC13 and TS10 are fantastic, I’ve been using them for non-astro dark-vision-preserving use cases (read: finding my way from bed to potty and back in the middle of the night 
) and they’re both excellent at that with either the stable or the multichannel branch.
I’ve read that Hank’s boost drivers don’t go as low, tho.
The Wurkkos lights use a FET+1 style driver, and dynamic PWM, so they can go very low by slowing down the PWM and using the minimum pulse length. The result ends up strobing visibly, but the average is quite low.
Hank’s boost drivers (so far) don’t go that low… but I think he’s planning to fix that. HDR drivers from thefreeman go just as low as a TS10, but without any PWM. It’s incredibly smooth, while also being stable even at very low levels. So I’m working on getting the code merged in and officially supported.
…I meant between the k9.3 firmware and the emisar-2ch-fet firmware builds. Nothing to do with Wurkkos 
I’m not entirely sure if the issue exists in the stable branch, or if it’s something I broke only in the multi-channel branch. There were other ADC changes there which may have caused or exposed this bug.
So I wouldn’t recommend trying a backport until/unless the issue is confirmed to exist in the older branch.
Hummmrmrm… but wasn’t that the case with the issue @Light-Chris just posted? Here’s the part from his first post that led me to believe the issue happened with the older, “anduril2” branch:
Have I misunderstood him?
Under normal use, I see no strobing with either the FC13 or the TS10.
With the TS10 (haven’t tried it with the FC13 yet), only if I go to a totally dark place, turn on the light at the lowest brightness, and then move it from side to side at half-arms-length with the LED turned towards me, can I then see the “interrupted line” effect indicating the the LED is indeed being turned on and off.
Is that what you’re talking about?
That build is based on the multi-channel branch.
That firmware file is from the multi-channel branch. I haven’t published any stable branch builds in several months… so everything recent is multi-channel.
In particular, he reported blinking during the post-off voltage display, and that feature doesn’t exist in the stable branch.
Yes, that’s the PWM making visible pulses. Different people have different sensitivity to it. Me personally, I can see PWM up to about 10 kHz. So it’s easy for me to see pulses as slow as the FC13 moon mode, which goes down to … 0.6 kHz I think? I forget. But some people don’t notice pulses even as slow as 0.1 kHz. It varies widely.
Since this light uses dynamic PWM, each ramp level has a different pulse speed. Level 1/150 runs with the MCU underclocked to 1/4th the normal speed, and a PWM waveform 4096 cycles long, which at 10 MHz base speed … works out to 610 Hz if I did the math right. But it gets faster as it gets brighter, and the higher modes should be about 19.5 kHz.
In order to see it more easily, the most effective low-tech method I’ve found is to shine the light in front of a dark background (ideally empty space) and wave a thin, stiff white object through the beam. An index card works well. It should end up looking like the picture below, like a series of individual frames overlapping.
Here’s one which pulses at 488 Hz. The creator of this light found it to be sufficiently fast to produce a smooth, steady beam… but when I saw it, all I could see was a strobe light.
With thefreeman’s driver though… there are no individual frames, even at the lowest level. Everything in the beam makes a smooth blur, no matter how fast it’s moving. It doesn’t even have any visible ripple.
I stand corrected. I thought that the download link having “anduril2” in the URI, plus the fact that there was no mention to “multichannel” anywhere, showed it was from the stable branch.
@ToyKeeper may I suggest that the branch name, if not the revision, be placed somewhere (in the URI, or preferably in the filename) so as to avoid that kind of confusion? The compile date is IMHO too volatile for that, given that it changes everytime the “./build-all.sh” script runs.
I don’t plan on having a lot of these big long-running refactor branches. Instead, I plan on merging down as far as possible, moving things to github, and trying to keep branches smaller and shorter-lived.
Will be nice to have a proper VCS I can just send merge requests to and open issues on. Also, my life is about to get more chaotic again soon for at least a week and possibly more but I did a little work on some automated build tooling so a new commit to main will test which lights’ firmware image changed and which didn’t and refresh any builds appropriately. Also found a (theoretical) security vulnerability in one of the included build scripts, and have some other small tools and stuff that might be worth contributing.
@ToyKeeper if you need any help separating the anduril codebase from the rest of the repo while preserving relevant history only (which is nontrivial due to some file moves and renames), I’m guessing is fairly hard in bzr, but I’ve already automated doing it in git (used for my git mirror that tracks launchpad).
This is true for the boosted lights I sent you but it depends on the converter IC used. 3rd entry here
The Boost IC has an Ultrasonic mode, at light load it decreases the switching frequency but never below 23kHz, typically 30kHz, this doesn’t save as much power as if it had no lower limit, but it guarantees no visible or audible artefacts.
But in my buck drivers it goes pretty low at zero load, around 100Hz, I usually increase it by adding a dummy load resistor, sacrificing a bit of power (not much, like 100-200uA) in exchange for higher frequency.
Hi
sorry, I had a bit of a holiday trip and couldn’t log in.
@ToyKeeper , thanks for the explanation 
and something went wrong when I installed the firmwares 2 days ago.
I can’t reproduce the issue I had then. it just works now without the blinking.
I will try the other different firmwares and will post my findings and performance differences, but I can’t do that tonight anymore. Sorry!
@ToyKeeper I like the multichannel software. One of its advantages is the post-off aux led voltage function.
Is or will there be a chance to use this function with the Firefly E12R as well? I have one, and I would really like to have that function with this light as well. My E12R has the anduril2-lume1-ff-6af-with-fet hex from 2022-12-27. Model 0481. Rev (I think) 653.