Update: If the light doesn't work after flashing, try doing a factory reset. Some flashing programs apparently don't erase the eeprom during flashing, so a manual factory reset may be required. The most reliable method for this is "loosen tailcap, hold button, tighten tailcap, keep holding until the animation finishes (about 4-5 seconds)". However, telling the flashing tool to do an explicit eeprom erase should work too. Or if a tailcap reset is physically not possible, and an eeprom erase isn't an option either, "Off -> 13H" may still work.
Original post below:
Lots of changes this time... several new models, new features, and more underlying architectural stuff rewritten.
New lights:
Added &hank-lume-x1-c (0283). Mostly done, but still missing support for standby animations ("smooth rainbow" and "breathing"). Work in progress. Adds ability to change aux RGB brightness (details below).
Added &fireflies-lume-x1-attiny1616 (0461).
Added &fireflies-lume-x1-avr32dd20 (0462).
Added &fireflies-lume-x1-avr32dd20-32w (0463).
Added &fireflies-lume1-6af (0451). Mostly works, but turbo is weird on this model and I can't fix it because it's a hardware problem. (ramp is regulated from level 1 to 149, and turbo is 150 only)
General:
Added Powerbank Host mode, for a couple lights which have a pin to control whether the flashlight receives power (charge the flashlight) or sends power (charge the other device). Use Batt Check -> 2H to enable host mode. Powerbank Host mode ends when you leave Batt Check mode. It is recommended that the user also enable Batt Color mode while charging another device.
Beacon mode uses Smooth Steps, if enabled. This "Smooth Beacon" is used instead of the dedicated "Beacon Tower Mode" some FF lights had.
Fixed bugs when user set aux ramp levels to weird values.
Dimmable RGB w/ AW2016 chip: (lume-x1-c)
The new AW2016 chip on Hank's Lume-X1-C is the reason why I've been focusing so much on things related to aux RGB lately. All these changes were necessary to support this chip and the features it provides.
Added ability to change aux RGB brightness. There are 4 settings:
Standby low brightness
Standby high brightness
POVD brightness
"On" or "Active" brightness: For ramp, strobes, etc.
To change standby low or high brightness: Go to "Off" mode, use 7C to reach the standby "low" or "high" mode, then use 8H to select a brightness. There are 14 steps, with the lowest 5 using PWM.
To change POVD brightness: Go to Batt Color mode (Batt Check -> 1H), then use 8H to select a brightness. There are 9 steps.
To change "On" / "Active" brightness: Go to a mode which uses this, like the main Ramp mode (with an aux channel enabled), or a strobe mode (with an aux channel enabled). Then use 8H to select brightness. There are 9 steps.
Battery / voltage upgrades:
Fixed flicker in Smooth POVD, by increasing voltage precision and adding a lowpass filter to the animation color. Instead of ~60 color steps, it now has well over 1000.
Increased battery voltage precision from 8 bits to 16 bits on most models (everything except attiny85). Before, it was 0.00V to 5.10V in 0.02V steps (1/50th of a Volt). Now it's 0.000V to 10.24V in 0.00015625V steps (1/6400th of a Volt). Had to recalibrate every affected model.
Batt Check now displays 0.01V precision instead of 0.02V.
Breaking change: Increased precision of user-configurable voltage calibration. Was 0.05V steps before, is 0.01V steps now. Batt Check -> 7H -> Option 1 uses "20" as its neutral value now, for +0.00V, and each step above or below that adds or subtracts 0.01V.
Made user voltage calibration handle dual fuel better, on avr32dd lights. Now adjusts the slope instead of the offset, so adding +0.10V at 3.9V only adds about +0.03V at 1.2V.
Added "Batt Color" mode. Use Batt Check -> 1H to toggle between colors or digits. This is like Smooth POVD, but runs until you stop it. It is intended to be used while charging, so you can stop charging when it turns purple, instead of having to count digits.
Changed a lot of internal stuff to make all this work.
Build / dev tools:
Updated the Atmel DFP version. Optional. Note, however, that if the wrong DFP is used, or if the build can't find it, it may break the Factory Reset function on some lights.
Added guidelines for how model numbers are intended to work, and how to assign them. Please stop choosing model numbers with a 0 in the middle.
Build script now shows the full version string of each model.
Build script handles improperly-formatted hex digits now, and translates them to the required internal format, so loneoceans git commit IDs should have digits now instead of just buzzing.
DAC ramp calculator handles 8-bit and 10-bit DACs now, and allows limiting the maximum power.
Hardware-specific changes:
Every new model has a new ramp, so expect some changes in the brightness of specific ramp steps. The Fireflies models in particular had all sorts of weird ramps, and I've tried to make them more consistent between models, and more similar to the ramps from other brands.
Fixed bug where 2C return-from-turbo didn't work while using a weak battery, on lights with weak battery detection.
Fireflies-lume10 is next after the hank-lume-x1-c gets finished. They have the same aw2016 chip, so they have similar complications.
Not sure yet if Lume10 has the same weird single-level DD FET or if it can be adjusted using PWM. I hope it's not the same single-level design. I really dislike that design. Won't know until I try it though.
Awesome, looking forward to it! I wasn't really sure how different Lume 1 and 10 are, but it seems like the 10 FET can definitely pull more current. Hopefully it's better all around in the 10
2026-09-12 not working on dual channel D3AA.. I loaded the new hex using my iMac (it is old and IS an Intel model), got verification, but light does not turn on.. tried twice with same result,
so I went back to 2026-08-12 and everything works again
Dang, I tested that, too. But I tried it again and confirmed it broke.
After some digging, I figured out what happened. I tested everything on a branch, then merged it to trunk, tagged it, rebuilt, and tested a few to make sure it was still okay... and the few I tested didn't include any with an attiny1634 chip.
The new Microchip DFP broke all the attiny1634 builds, so they don't boot. Rebuild with an older Atmel DFP and it works fine. Not sure what changed between, but it must be something pretty foundational.
So I updated the build script and the DFP installer script. A "make dfp" now grabs 3 different versions of the DFP... one for avr32dd, one for attiny1616, and one for attiny1634+attiny85. It builds with a different one for each.
A new version is uploaded to github... grab the new .zip file with a "+1" in it, and it should work now. At least, it works for me now.
Confirmed that it works with the new "+1" .hex file.
I checked with avrdude with a dual-channel Emisar D2, model number 0135, and with the original .hex file I got the same result as jonslider reported above. Going back to 2026-08-12 worked, too, but now the new 2026-09-12+1 works as well.
It seems like every time I do a release, I manage to mess up something. This was a new one though. I wasn't expecting the newer DFP to make it unbootable... and also wasn't expecting the DFP version to change just by changing what directory I was in when I built the files. Everything worked fine in a dev branch, and then after a no-changes merge to trunk, it was unbootable because a dependency version had changed and I didn't notice.
There's a popular video game speedrunning event called GDQ, Games Done Quick. The world's top speedrunners get together and run through games for an audience, live. They run the same game over and over for years, tens of thousands of times, and practice the specific run they're doing at the event for a few weeks, and then finally do it on stage... and yet, almost every time, there will be something which goes wrong. Something new that they've never seen before. So they almost always say, "Huh, that's never happened before".
Then, of course, they realize what they said, and laugh at themselves... because they have just become the latest victim of the GDQ Curse.
Thanks for the updates! Been a little slow flashing these to my lights, but I can safely say my Noctigon KR3 functions as expected:
Adjustable RGB works (and the config for it is implemented well - is it possible to have the level adjustment work IN the selected color? It presently ramps up in white; viewing the ramp in the user-selected color would simplify choosing the level one wants)
Smooth Beacon is pretty cool looking! (I may be one of the 3 people who like it & cannot say I've ever actually used it... but it's what it's)
Smooth POVD... I don't use POVD myself because of the formerly-jarring transitions from off to POVD to my standby RGB but this may have convinced me to get on the bandwagon
Now I'm gonna figure out which lights I have onboard charging so I can try out the Batt Color function - most of them have a color indicator to show a full charge, but this looks like it could be a nicer, easier-to-use option.
is it possible to have the level adjustment work IN the selected color?
It already does, for POVD and the "On" modes... but the standby modes are a little more tricky, because of what happens if the user has it in rainbow mode or voltage mode or something like that. It causes the aux LEDs to go really fast, like when holding 7H. So instead of that, which was worse, I made it preview them in white. Making it stay the same color was otherwise a lot more complicated than it seems like it should be.
Smooth Beacon ... cannot say I've ever actually used it
I never really used beacon either, but I've been using it a lot more since adding this. Usually just if there's something I need to remember, like remember I need to call someone, or stop a battery charging before it's too full, or something like that... I'll run a low-brightness beacon and place it near me, as a reminder. It helps me avoid getting lost in tangents for 12 hours and then realizing only after it's too late.
try out the Batt Color function
It's worth noting that this only works on lights with dimmable RGB... and there are only a few of those so far. If it can do Smooth POVD, it can also do Batt Color. They're basically the same thing.
Gotcha - I only suggested the standby adjustment because of my own particularities... Floody lights get Red aux, Throwy lights get Blue. The difference between the red & the white setting, especially for the low modes was quite noticeable. But, I totally get that hardware & software don't always walk hand-in-hand... I appreciate your time!
I think I have one or two lights I can test the charging stuff on - if I find anything worth asking about, I'll let you know!
Yeah, I found I had to make sure I held the button down while reattaching the head to EACH light I updated. I've seen that recommended several times but this is the first time I can recall having to make sure to do it.
Weirdly, though - my KR1AA flashed the new update (I confirmed the version check & tried the "soft beacon" mode) but it RETAINED all of my settings from the previous version.
If it shipped with 284, you should probably keep using 284. It has a lower limit on the turbo power. Usually, Hank picks power limits for a reason, so if he used a lower-power build and you flashed a full-power build over it, you might risk damaging the LEDs by overdriving them.
Or you could just avoid turbo, and wait for 0284 to be supported. I didn't know if it a real build that Hank uses, but ... it sounds like it is, so I should add that.
Thanks for the clarification, 284 is specified as 32w boost for 18650 with advanced aux. Is 283 40w then? I may switch back and wait for it to be added.
I added model 0284 today, and I'm running it on my KR3 and KR1K.
It's the same as 0283, but maximum power is 70% instead of 100%.
It's not entirely clear what "100%" means on some loneoceans drivers though, so I'm not sure exactly how much power it uses. Sometimes he uses 70%, sometimes 80.5%, and both are called "32W"... but I'm not sure which is right, or if it varies sometimes.
I'll have to ask Hank sometime what the actual power is, and what the actual limit is supposed to be. But for now, it's 70%.
Mine shipped with 283... I would not say I've turboed it much since flashing the update. I didn't do anything crazy with the thermal limits, either - so...
Don't forget to add "ToyKeeper" to your Patreon contributions!
While a small amount like $2/Month may seem small, with a bunch of people it adds up to something meaningful! If many of us did a $7/Month "Starbucks" coffee contribution, even better! 😉
Proud Patreon supporter for at least a couple years at this point...
Still trying to find ways to get the other bills paid though. :D
(I'm hoping I'll have paying customers for my browser extension thing, once I get the server side written... but I haven't done that yet, and haven't touched it in months because I've been doing flashlight stuff instead)
Thanks! Every little bit helps. Without people tossing coins into the hat, so to speak, I would have had to stop working on this project a long time ago.
weird, flashed my D4K lume with the anduril.hank-lume-x1.hex file, but it doesn't come on afterwards. no lights, nothing, acts as if there isn't even a battery installed. works fine when I flash it with my back up anduril.hank-lume-x1.hex file from before the update. anyone else?
I feel like there must be something strange happening. What software do you use for flashing?
I flashed my D4K lume-x1 with this release and it's working. I'm using avrdude 7.1+dfsg-3+b2, and here's what it shows when flashing:
~/src/anduril/> ./bin/flash-avr32dd20.sh releases/anduril.r2026-09-12+1/hex/anduril.r2026-09-12-1-g66a469d.hank-lume-x1.hex
Flashing avr32dd20 MCU on port /dev/ttyUSB2: releases/anduril.r2026-09-12+1/hex/anduril.r2026-09-12-1-g66a469d.hank-lume-x1.hex
avrdude error: "safemode" feature no longer supported
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e953a (probably avr32dd20)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file releases/anduril.r2026-09-12+1/hex/anduril.r2026-09-12-1-g66a469d.hank-lume-x1.hex for flash
with 13819 bytes in 1 section within [0, 0x35fa]
using 27 pages and 5 pad bytes
avrdude: writing 13819 bytes flash ...
Writing | ################################################## | 100% 2.14 s
avrdude: 13819 bytes of flash written
avrdude: verifying flash memory against releases/anduril.r2026-09-12+1/hex/anduril.r2026-09-12-1-g66a469d.hank-lume-x1.hex
Reading | ################################################## | 100% 1.87 s
avrdude: 13819 bytes of flash verified
avrdude done. Thank you.
The only thing which changed between those two commits is the DFP version. So if the first one works and the second doesn't, it has to be that. But if they both work, then try a git checkout trunk and make lume-x1 again to check the latest version.
both of those methods worked perfectly fine. but if i just clone the repository (into a new directory of course) then do make dfp, make lume-x1 without doing anything else, then that hex file will write and verify, but the light doesn't respond.
Thanks, that points toward the issue being likely somewhere in my code instead of Atmel's code. Like, perhaps it's reacting to something in the voltage ADC 16-bit rewrite.
But it's weird that it's working for some people and not others. There could be a difference in the hardware, or in the flashing tool, or ... not sure. What exact flashing method are you using?
It would be a lot easier to fix if I could make it fail. But everything I've tried "just works".
One thing I noticed when I flashed my FF X4 Stellar is that it did the same thing as my D4K, non responsive, I tried using the power button to reset it to defaults but it didn't work at all. The only thing that worked was holding the power button while I screwed the flashlight head on. THEN it was able to reset and it started working perfectly. I then replicated the same scenario on the D4K and it then it too started working perfectly. So it's not your code so much it's just that the lights need to be reset to default, and the only way I found that worked was the holding the power button while screwing the head on method
OMG thank you, that helps a lot. It looks like it's just not erasing the eeprom like it's supposed to.
Could you try another test?
Flash the old version. Do a factory reset (probably a tailcap style reset). This is to get it back to the state it was before, where things didn't work.
Flash the new version, without a factory reset. Confirm it doesn't work.
Flash the new version again, but add a "-e" in the command line before the "-U", like ./avrdude.exe -p avr32dd20 -c serialupdi -P com4 -e -U flash:w:anduril.hank-lume-x1.newer.hex
I'm hoping that just adding the explicit "-e" (erase chip) will fix it. Then there will be a simple solution anyone can use, even on lights where the tailcap reset isn't practical.
Mine does a chip erase whether I tell it to or not, so I still haven't been able to get it to fail.
well, now i can't get my light to fail to work no matter what hex file i use, lol. but in a way that gives us our answer, since I defaulted my light, that cleared whatever was breaking it.
Yeah, I think we have at least enough of an answer. Not sure how to make it fail, but knowing how to fix it is the real goal and that's already solved.
It's used on the fireflies-lume-x1-attiny1616. IIRC, it includes lights like the X4 and the E04... the ones with a USB-C port. May also include some others, but I haven't tried others yet.
Or there are models from other brands, like Sofirn's BLF LT1. I think some Wurkkos models (like TS26) might also be able to charge other devices... not sure. Those don't have any powerbank controls in Anduril though, since the charge circuit is entirely separate. That's how it is in most lights... separate charge circuit which does its own thing.
I haven't really used the ability to charge other devices from a torch, aside from briefly to test the powerbank host/guest toggle pin. Had to dig to even find a cable for it, and a compatible device to use for testing. Usually when I charge devices, I plug them into an old USB-A brick because I want to slow down the charging rate. It's healthier for the batteries.
Sofirn Q8 Plus, it's quite nice. I use Molicel P45 batteries in it instead of P50 though. Don't want to melt the light since it has no current regulation. Otherwise a great light.
No, I'm not talking about melting while charging. I'm talking about when the light is actually running.
Current regulation basically means the light controls how much electricity the LEDs are allowed to pull from the batteries. The Q8 Plus doesn't have that kind of regulation, so with very high-drain batteries it can pull a LOT of current. That gives you more output, but also creates a lot more heat in the LEDs and the light itself. In an extreme case, you can get hot enough to damage things.
That's why I use Molicel P45s instead of P50Bs in mine. The P45s can still provide plenty of current, but they're a little less aggressive, so there's less stress and heat.
As far as knowing whether a USB/Anduril light has current regulation, you generally have to check the manufacturer's specs or reviews. Anduril itself doesn't tell you whether the hardware is regulated, the driver in the light determines that.
For Emisar DA1K, model number 0281, hank-lume-x1, I have come across a quite noticeable batt check drop of 0.1V (or 0.09V) with 2026-09-12+1 (and with 2026-09-12).
I have checked with a Molicel P50B, which is 4.02 with 2026-08-12 (as well as with 2025-07-07), but only 3.92 with 2026-09-12+1.
And I have checked with a Molicel P45B, which is 4.18 with 2026-08-12 (as well as with 2025-07-07), but only 4.09 with 2026-09-12+1.
In contrast, for Emisar D3AA, model number 0161, and for Wurkkos TS10SG, model number 0713, there was no difference in batt check between 2026-09-12+1 and 2026-08-12.
I noticed the same drop on my DA1K. However, that same firmware build is used on multiple different products, and the voltage was basically spot-on for all my other hank-lume-x1 lights. On a D4K, for example, it didn't need any adjustment. But on my DA1K, same firmware file and same driver circuit design, I needed to add +0.10V to make the batt check values correct.
To calibrate it, use Batt Check -> 7H -> Option 1 -> 3H. That sets the calibration to "30", and the centerpoint is 20, so 30 is equivalent to +10 centivolts, or +0.10V.
I've been tracking the calibration every time I reflash and test a light, and most I've tried were in the range of -0.02V to +0.03V... but I had a few which were +0.05V, +0.08V, or even +0.10V. And in all those outlier cases, it was on a build which is used on many different lights and most of them were much closer to zero... so I can't really adjust it for each one at a source code level.
A variation of up to +/- 0.15V is expected though, especially on older MCUs. So I made the calibration range accept up to +/- 0.20V. It seems like the manufacturer variance has gotten smaller on newer MCUs, so it's usually within 0.05V.
Anyway, it may be useful to keep a DMM nearby when flashing firmware, and use it to measure the battery, then use Batt Check and adjust the calibration until it matches. Then write down the correction factor you needed for each individual light. I put this in my Anduril setup notes file alongside any other settings I want to configure after reflashing. I forgot to add the values for most of my lights when doing the 16-bit voltage rewrite though, so there are a lot missing. Gotta do those again... sigh.
Thanks for clarifying! And good to hear that this is expected behavior, and that the DA1K is somewhat of an outlier here. I just did not expect an entire 0.1V difference, but of course, model number 0281 is used quite universally.
any chance we will see model 0282 - Lume X1 32W ? The 18650 Lume X1 lights dont do well with the normal 40W firmware if the battery voltage is low or battery's IR is high for whatever reason. Loneocean has a build for 0282 that is shipped with 18650 FFLs and Hanks but it is behind and this release only the FFL 32W is built
ah thank you! i was looking at the hex archive and didn't see it. any chance to add the hex to the +1 zip? Currently i dont have access to dev environment but if too much trouble i can probably find someone to compile it.
On my d3aa, when i do 3C for battery check, and then do 3c again to change the emitters for battery check, I've noticed there are now 2 red aux options.
1 dim red aux
1 bright red aux
What is this about? No other aux colors have have a dim+bright option...
I added an any-color channel mode on the aux LEDs, for lights which are capable of doing PWM on the RGB pins. Use 3H in that mode to change the color. It can also ramp up and down in brightness, but that only applies in modes which have adjustable brightness.
The reason why it's red is because a hue value of 0 means red. But you can set the hue to anything, stopping at any point on the color wheel.
The extra channel mode was mostly added for testing, to make sure the RGB is working correctly. But it could be useful for some people, so I left it in.
Thank you Toykeeper for all the great work! Is anyone else having issues with the Firefly Lume X1 (32w and 40w) hex files working? I am able to flash them but the lights don't work with the new firmware? I screw the head back on and the light flashes once but then neither the aux nor the main led turn on or respond to button presses?
Edit: solved. Needed to reset Firefly Lume lights first
FWIW, I flashed an X4Q with no issues. I used: anduril.r2026-09-12-1-g66a469d.fireflies-lume-x1-avr32dd20.hex
u/ToyKeeper - I can also confirm that the lume1-6af does behave oddly in Turbo. It flashes once and then goes off. Was really off-putting until I remembered that you mentioned it in your release note! At first I thought maybe my battery wasn't charged enough to sustain turbo for more than an instant.
It should last at least a few seconds on turbo... how long did it take on yours?
In loneoceans' fork, he had a thing he called "turbo temp extra", where it would disable most of the thermal regulation on turbo mode. Instead of doing PID regulation, where it looks ahead and tries to "steer into the curve" to avoid exceeding the user's configured temperature limit, he would disable that and go way past the temperature limit, basically going way off the "road" and then try to steer back. Like if the limit was 50 C, it would let the light heat up to maybe 60 C or so, staying on turbo the whole time, and then start trying to regulate afterward. It would then drop really low in order to recover, causing it to "over steer", and then eventually have to climb back up to a stable level.
This had a tendency to make lights overheat and damage themselves or the battery or the user's hand.
So I didn't include that code. Because of this, I expect turbo won't last as long as it does in his builds... but in exchange, it should be a lot safer and less likely to overheat or damage anything.
To compensate for the weird ramp shape, where level 150 is a lot higher than 149, what I did instead is make it reset all thermal history and "inertia" when it drops from 150. That way, it should drop only a single level at first, and then stay at 149 for at least a few seconds until it has additional data. If it's still rising too fast, it'll start regulating down again, but at least it'll end up on a shallower trajectory, and won't immediately overshoot the stable level it's searching for. Basically, the initial response at 150 draws a steep line downward, but instead of following that line, it resets as soon as it takes the first step, and goes with a flat horizontal line instead. Then it measures for a few seconds before drawing a new line... which won't be as steep as before. I hope that makes sense.
On every non-loneoceans light, the driver can make a smooth ramp down from turbo, which allows the steering mechanism to work as intended. But the sudden huge single-level drop on some of his lights breaks that, and there isn't really a good solution yet. It's like trying to take a hairpin turn at high speed on a slick road, where the only options are steering too late or steering too early. Either way falls off the road.
It literally just flashes on and then immediately off. It behaves very strangely. I 2C to top of ramp, then I 2C to turbo. It will flash briefly and then turn off. But the aux aren't on so the light is still "on." Then I 1C and it flashes briefly and then off but this time it's really off, the aux come on. Then I 1C again and it's at top of ramp. Battery is at 4.11v.
I have only one light with lume1-6af firmware... it's an E04 Surge. When I put it on turbo, it stays there for quite a while, like it was over 2 minutes before I gave up. My battery was probably too low to make it overheat. So for testing thermal regulation, I lowered the temperature limit to 40 C. Then it would stay at turbo for 5 to 10 seconds before stepping down one level. Then it stays steady for another 10 seconds or so, and gradually regulates downward for a few minutes until it reaches equilibrium.
For testing, I found it useful to go to the smooth ramp and raise the ceiling to 150/150. Smooth ramp -> 7H -> Option 2 -> 1C I also typically set a slower ramp speed, like speed 2 instead of 1. Then just ramp up to the ceiling, and see how it "pops" up at the final level. Doing another 1H to ramp down should make it "pop" back down before it ramps smoothly. Just to confirm it's working correctly. It shouldn't turn off at all during this process.
Out of curiosity, have you done a factory reset? It might just have corrupt data in eeprom. There has been a lot of that going around. Adding a "-e" before the "-U" on the avrdude command line should erase the eeprom, or a "loosen, hold button, tighten, keep holding ~5 seconds" should reset the eeprom data too.
Yeah good question. I just had that same factory reset issue on my X1Q (in case it matters for any reason, I use pymcpuprog). I just erased the T1R and re-flashed the new firmware: no change in turbo behavior.
I also just tried it with smooth ramp. I did 7H for ramp config though (assuming that's what you were referring to). The problem still exists for me in ramped mode at the 150 ceiling operationally it's sort of worse because it remembers that level after I turn it off. I now have the ceiling at 149 and confirmed there is no problem with it there.
I will probably go back to stepped and remember not to turbo it!
Ah, yes, 7H, not 7C. Has been a long day. The smooth ramp thing was just for testing purposes, not for ongoing use.
I just erased the T1R and re-flashed the new firmware
I hadn't heard of a FF T1R before now. I've only tried a FF E04 Surge.
In either case, the factory reset should be done after flashing firmware.
Do I understand correctly that when you go to level 150, the light flashes bright for just a few milliseconds, then turns off? And then if you ramp down, it turns back on?
If that is the case, it sounds like the driver circuit may be somewhat different between your light and mine. I may need to obtain a T1R for testing purposes, to find out what's different and fix it.
Oh, it doesn't have a FET? Yup, that would explain it. It's trying to dump power through a chip which doesn't exist. :D
For now, yeah, set the ceilings to 149, disable turbo, and it should mostly work. It'll likely still have issues on strobe modes though. So it really should be using the "fireflies-lume1-6af-nofet" build target instead. I haven't added that one in my repo yet though.
Anyway, this is why it's important to always make sure the model number is the same. Install firmware for the wrong model number, and stuff will break.
Yes - picking the right model number is key. I had ironed out most of the steps in my flashing work flow and documentation, but this one pesky T1R is an outlier legacy driver.
That's weird. I tried that on a FF L60mu, and it works for me. I checked again just now to make sure, using the .hex file in both the original and the updated release .zip files.
There are both avr32dd and attiny1616 versions of the FF Lume-X1 though, so it's important to make sure the model number matches.
Hmm... I have it running on my FF Z1. I also have a FF X4, but it uses the attiny1616 version. It's possible that Fireflies might use different drivers in the same light, perhaps for different LEDs, so the name of the light isn't necessarily a reliable indicator of what driver is inside. The only reliable method is to use Version Check before flashing, to ensure the firmware model number stays the same.
For a sanity test, it'd be a good idea to make sure you can flash loneoceans builds and get it working. Then after that is confirmed, try the matching builds in today's release. It would at least help narrow down what the issue is.
Hmm.... Yeah the hex files from LoneOceans website work. The Z1 is the B0225 and the X4Q is the B0224 boards which should be avr32dd20. I'm using zflasher on my phone. I can try later using my computer as another troubleshooting option.
If you could try multiple flashing methods, that would be really helpful. Another person here (derailius) ran into a similar issue, and I'm not sure what's causing it. Same .hex file, but it works for some people and not others. Seems like there must be something different, like a different flashing process or different hardware, but I'm not sure what exactly.
I haven't been able to make it fail, you haven't been able to make it NOT fail, and it's not clear yet what's causing the different results.
Was able to try it on my computer this morning running avrdude 8.3. No difference unfortunately. I flash the mainline Anduril on the Z1 and X4Q and the lights don't work like before. I flash the LoneOceans hexs and the lights work. I did notice yesterday I downloaded r2026-9-12 and there is a +1 version on github now but that didn't make a difference either unfortunately.
/u/derailius found the answer, and it's surprisingly simple... it probably just needs a factory reset. :D
The flashing program might not be erasing the eeprom like it's supposed to. You can work around this by doing a factory reset (loosen tailcap, hold button, tighten tailcap, keep holding for about 4-5 seconds). Or maybe by adding a "-e" on the avrdude command line before the "-U" (but this isn't confirmed yet). Or in ZFlasher, maybe just do an explicit erase or eeprom erase first.
The "+1" version isn't relevant for attiny1616 or avr32dd builds. I added it because the original release broke all the attiny1634 lights. My dev/test branch was using an older Atmel DFP than the trunk/release branch, so it worked in testing and not in release. So I removed the original .zip and replaced it with one without that issue.
Good stuff. In some future version of Anduril 2, may I request making an option to have the button LEDs independent of the RGB aux? I end up making my own branch with 8C in both lockout and off modes to cycle the button brightness.
Interesting. Haven't seen that one in the wild before. Wasn't sure if it was used in production, or if it was just another of the conceptual designs loneoceans added to his fork. Usually Hank tells me if he needs a variant with limited power, but he never mentioned this one.
I just added that one... &hank-lume-x1-32w (0282).
I tried it on my D4K-519A, DA1K-NTG50, and a prototype D4K with lume drivers.
Each one had a slightly different "gear ratio", so I put in a relatively easy compile-time option to adjust that. My D4K-519A uses 22, DA1K-NTG50 uses 25, and the prototype (which has electrical problems) uses 28. YMMV.
My lights shipped with 0281 firmware (100% power), but I think I'll keep this 0282 instead (70% power) because I usually prefer to have a bit lower turbo.
However, I just noticed you have to be logged in to be able to download artifacts. I think github used to allow anonymous downloads, but it doesn't any more.
Hey u/ToyKeeper, I sent you a message waiting for a reply. I believe there is an issue with 9/12 firmware. I just reflash a lume x1-c driver and it didn't work anc was acting weird so I use the older version hex file
Did you try doing a factory reset and/or an eeprom erase? Someone else here was having a similar issue, and all it needed was a factory reset. It may need to be a tailcap style reset though, so for some lights, an eeprom erase might be easier.
Adding a "-e" to the avrdude command line before the "-U" might help. Would be awesome if you could confim that though, because once it works, it's hard to make it fail again. If you have one which isn't working, that makes you uniquely qualified to help debug this. :D
Yes, I tried to reset the ui and reflashed it twice, was acting weird the main emitter will come on and aux was acting weird, reflashed to 8/12 firmware was fine after. I have to reflash a few lume n1 drivers, if there is an issue ill let u know. I already messaged hank too on this, if he had an issue he will let me know
It's crucial to make sure the model number matches. If it doesn't, don't flash it.
Always use the Version Check function before flashing, then look up that model number in the MODELS file to get the name. If it's not there, it's not supported yet.
I have to reflash a few lume n1 drivers, if there is an issue ill let u know
The lume-n1 drivers aren't supported yet. Don't flash those with anything currently in my repository, because it won't work.
I just reflash a lume x1-c driver and it didn't work ... reflashed to 8/12 firmware was fine after
The lume-x1-c was not in the 8/12 release. It's brand new in the 9/12 release. Are you talking about a different light?
It sounds like you may be flashing mismatched firmware onto hardware it wasn't intended for. A factory reset can't fix that.
No clue. Hank hasn't said a word to me about the existence of the lume-n1 drivers. Usually he sends me hardware to use for development so I can get the code written, but since it has taken me so long to get the lume-x1-c working, he may have given up on me. I was thinking I'd ask him about it once I have the rest of the lume-x1-c finished.
I don't think he realizes how much work was involved in making the lume-x1-c work correctly. I've done like 15,000+ lines of patches in service of that goal, which is roughly equivalent to the amount of work to write an entire book or two. Had to rewrite multiple foundational parts of the kernel, and fix and re-test and re-calibrate every light in the repository twice. Have been working on it for months.
Anyway, I don't really know anything about the lume-n1 yet, other than it exists... and that it seems to be distributed in violation of the license. Loneoceans pulled in some proprietary code which isn't compatible with GPL, so every vendor shipping his recent drivers is violating the license. I tried to tell him about it 3 months ago, but haven't heard back. A little miffed about it. It has all been a big mess to clean up. Sent him another message just now, while it's on my mind.
So... no clue when lume-n1 is getting added. There are ... issues to resolve.
Will any of these new features work on something like a Wurkkos HD10? I am assuming the TS10 is the correct firmware specifically the Low FET variety.
I recently installed the a recent version of it but had to reinstall the older 7/7/25 version. Seems like the light kept coming on in momentary or lockout mode. Not sure which as I never use either mode so I know I didn't program it to do that. Had to 4C from off to get it to come on. Once the light was off, it would resort to that mode. Tried everything like 6C if it was in tachtical mode or whatever but it just was stuck in that mode. Finally had to factory reset it and now it works like it should. Haven't reprogrammed any of my settings yet though.
Works fine on HD10. Just make sure the model number matches, and make sure to include a chip erase in the flashing command, or do a factory reset after flashing. Like, with avrdude, make sure to have a "-e" before the "-U" option.
Resetting the eeprom is mandatory whenever reflashing the firmware. I recommend making sure your flashing program does it, but if that's not feasible, at least be sure to always do a factory reset afterward. The config values change between releases, so old eeprom data is very likely to cause problems.
The dual channel drivers use a completely different design, much older, and it's not capable of doing PWM on the RGB pins... so no Smooth POVD on those.
If it uses a 6-pin flashing adapter, it can't do Smooth POVD. If it uses a 3-pin flashing adapter, it might be able to, or it might not. Depends on the circuit design.
So, help me understand please. If I got a Z1 a few weeks ago, it obviously wouldn't have this update. How, if at all, would I be able to apply this update? Is it even possible for the non-techie types or would I have to purchase a new light with the update?
You can get a doodad from Hank (Intl-Outdoor) for updating the firmware. It's a 3-pin UPDI adapter. Works on almost any recent Anduril light. Or for older lights, there's a 6-pin usbasp adapter. A few other people sell them too, so Hank isn't the only source.
Basically, open the light (unscrew the battery tube) and look for a set of 3 or 6 pads next to each other. The Z1 has the newer 3-pad style. Press the adapter against those, run a command on a computer or phone, and it installs new firmware. Only takes a few seconds.
I would not call it easy.. there are a number of steps involved to obtain and select the correct firmware files
and it can be challenging for me to reflash because my old eyes make it difficult to see the pins on the flashing tool, to position them correctly on the pads on the driver.. I have to use a jewelers magnifying visor, with a light mounted on top to illuminate the contact points..
and in my case, I choose to use a mini vise to hold the flashing adapter onto the driver pads.. so my hads are free to operate my computer (I dont have an android phone)
it is definitely easy when you have all the right stuff and good hand eye coordination.. but for me it is not easy to get setup.. it involves wrapping my brain around a number of concepts and hardware..
in your case, if you want to learn a new skill.. go for it, the adapter is inexpensive..
otoh.. most of the stuff in the new firmware, may be things you dont care about.. as it is mainly about how many colors the POVD Aux use.. and I recall your first reaction to POVD was a desire to turn it off (I felt the same way initially)
I use the flashing adapter from u/the_gchart, you can message him here on reddit.. he is also on blf as gchart, you can reach him by clicking on his username in this post:
Still kind of confused about the brightness level of POVD or Battery Check. Does this update allow the user to select the brightness of the battery voltage test? I have mine flashing blue but it looks like it's high and not low like I would prefer.
After flashing I did factory reset and it still showed 04/29/24 on my DW3AA. Tried it again and now the LED of the flashing key goes off when making contact with the pogo pins. Light doesn't come on with the pins connected or light with battery in it. Is this light bricked?
It might need the light rotated 180 degrees to flash it, maybe?
Some lights flash easily, some are more of a pain. I have some where I have to get the pins into exactly the right position or it won't flash. Normally, I use a pretty strong magnifier to see while I get the pins positioned.
As for fine-tining the POVD brightness, that is only on lights with the new aw2016 aux RGB control chip... like lume-x1-c drivers and the not-yet-supported lume10 and lume-n1.
Probably shouldn't have messed with the light then. Especially if the newer features you mentioned are only with newer hardware.
The Three pins is a piece of cake with the DW3AA. Can't get the light to flash anymore when the pins are connected. What to do when there is no sign of life like this? Didn't think it was even possible to brick a light when you can just reflash unlimited times.
It's very unlikely that the light would be bricked. But if it's an older flashing adapter, it is sometimes possible for an adapter to get damaged when a light tries to draw too much power... and this can happen specifically on a d3aa/dw3aa/kr1aa with older flashing adapters. The weak battery detection cycle can over-draw some flashing adapters, but newer ones protect against that. I had that happen once, just before my 2024-04-20 release.
Does the adapter work for flashing other lights?
As for new features, most of the new stuff works on d3aa/dw3aa/kr1aa. Not all, but most.
It's a new adapter I bought from G-Chart. Bought the longer one for the KR1AA as well as the standard length one for everything else. Tried both adapters on the DW3AA and no signs of life.
Loaded the 162 KR1AA hex accidentally to a KR1AA running a 161/D3AA (checked my other KR1AA aswell it has the 161 version by default) and now the light is just blinking erratically. Will turn on minimum if the button is held down for long and then can adjust brightness between like 10-20 units. Otherwise it just blinks and sometimes starts to blink like doing a reset with a button when held down but won't reset. Tried to flash the original 161 2025 07 07 to it and it doesn't change anything.
Using a windows and AVRDUDESS 2.20. Is the "Erase flash and EEPROM (-e)" the next thing to try or what could be causing this? Newbie reflashing here :D.
Okay I tried a bunch of different D3AA versions with the erase flash and eeprom activated and the light is still the same. Once you insert a battery, it starts to blink approx in 0.5 seconds alternating pattern between a medium and a bright blink. Won't react to clicks of button but once you hold it it starts to flash like you're resetting it.
If I hold the button it won't reset. If I release the button in any moment of this blinking, the POVD comes on and then dims out. Then the light is running the slow change aux and if you press the button it might start the blinking again. If you hold the button the light turns on in a pretty dim brightness. Holding the button after that will increase and decrease the brightness but the range of brightness is very dim. About the same as setting the minimum 10 and maximum 20.
Light won't go into any other "mode", if I press 3 times to go into the battery check mode the light starts the blinking again :D
Got a KR1AA head off another one I had lying around because of a bad button, flashed that with the D3AA latest release and it works normally. Now I'm wondering if this is a software issue or did I mess something up in the head with the long pogo pins going through the rear..
The d3aa and kr1aa firmwares can be used on the same hardware. They just have some things tweaked to make it work a little bit better on the models they're named after. Either one should work.
Can't say for sure if there's anything physically wrong with the light or not... but the KR1AA can often benefit from being taken apart and cleaned. It has particularly fiddly contacts. It also can benefit from having the inner tube pulled out and then set back into place.
I don't have a model 0633, and don't know much about it.
Looking it up... It seems it was created about a year ago during a time when I was preoccupied with spine surgery. No wonder I missed it. Also looks like it has unique hardware which has unusual behavior. Could add it, but it'll likely end up with bugs since it's unusual and I don't have hardware to test.
56
u/DropdLasagna Sep 12 '26
Words cannot describe how awesome this is right now.