I do all my flashing on my phone via ZFlasher, which has the ability to read & copy the FW on the chip. I would imagine the windows software should be able to do the same.
I’ve made sure I backed up the pre-installed FW on a couple of lights just in case I ran into an issue with an updated version from Toykeeper, so it’s not a bad practice.
There’s more than one “tool” for Windows; I don’t use that crappy OS, but I’m informed there’s a Windows version of AVRDUDE (the tool I use on Linux), and here are the commands I use to make backups of both the flash (where the firmware is) and the EEPROM (where its configuration is stored) on my DD3AA:
avrdude -p avr32dd20 -c serialupdi -P /dev/ttyUSB0 -Uflash:r:emisar_d3aa_20250507_backup_flash.bin
avrdude -p avr32dd20 -c serialupdi -P /dev/ttyUSB0 -Ueeprom:r:emisar_d3aa_20250507_backup_eeprom.bin
You of course would have to change, besides the name of the .bin files, the avr32dd20 to the actual MCU in your light, ditto serialupdi for the protocol, and /dev/ttyUSB0 to COM4 or whatever that sorry excuse for an OS would force you to work with.
If it doesn’t work, it’s probably for the lack (or an incorrect version) of the OS device driver, and driver-hell is just another reason I avoid Windows at all costs – definitely can’t help you there, but I’m rooting (pun intended) for you.
Is there a software solution to lower max amps? For using a B35AM with the LumeX1.
I still want 150 steps, but i want step 150 to be lower.
It would seem (coming from someone with littel knowledge on the matter) that you could change the ramp table so it just doens’t go up as high. So you keep PWM_Max at 255 but only go up to 155 in the table at step 150? Similar to the 219B FET firmware but for a boost driver instead. Though maybe it’s a bit more complicated with UDR?
I thought the 150 will scale with the applied cap?
I.e. 2 separate features, a brightness floor and ceiling selector, then a step count selector. In short, it already does what you want it to?
@ToyKeeper do I have that right?
lowering the ceiling makes the ramp shorter. In stepped mode you wouldn’t notice it but in ramping mode you will.
Are you sure? I didn’t notice, and I don’t want to mess up the programming I currently have set up. You can set the floor to ceiling ramp speed, I didn’t notice that putting a ceiling changes the floor to ceiling ramp appreciably.
If you could try the following: lower the ceiling cap, then set the amount of steps, then set the ramping speed.
That seems like a good idea. Not sure if/when I’ll have time, but I created a bug report to remind me and to track progress.
I’ve wanted that feature several times too. So I created a bug report for it. What I have in mind is an option to automatically enable a predefined sunset timer when the light first turns on from off. Then it’d go through the usual sunset process, requiring only a single click to turn the light on and it’d gradually dim and shut itself off after a configured amount of time.
Sorry, there’s currently no way to do it without modifying the firmware. Setting a lower ceiling also shortens the ramp.
You’d need to calculate new ramp tables… which is a bit complicated. There’s usually a significant amount of fiddling and testing and tweaking required to make the ramp look smooth when it crosses boundaries in the underlying power circuitry, like changing gears on a bike.
I’ve tried to leave hints in the anduril.h files for each model, to help with recreating or modifying the ramp table when necessary… but it still takes a while to produce good values which look “right” during use. Sometimes I even have to modify the ramp calculator scripts on a per-light basis, or post-process the values, or just edit values manually.
So… it’s do-able, but it’s complicated.
I’ve had this post bookmarked to reply to for ages… oops.
A derivative of this patch was merged last month:
Added config options to control brightness of button LEDs and post-off voltage display, based on the ramp level of the main LEDs. Affects all lights with aux LEDs and more than 8 KiB of ROM.
The new options are in Battcheck → 7H → options 3+4, to control the low and high ramp levels where the button LEDs turn on at low or high brightness. Set to 0 to disable the button LED during ramping, or 1+ to set a specific ramp level.
Closes PR #10: SiteRelEnby-rgb-voltage-configurable
Thank you both for this change!
I use my D3AA (especially) on moonlight at lvl 1 quite regularly and it’s been a habit to keep my thumb over the button to keep the button aux lights from adding what little extra they can… Being able to just deactivate them while the mains are on is a great little change for me!
And while I only ever noticed an exceedingly small amount of pre-flash when going into moonlight, I don’t see any after this update!
Now to make the rounds again and do it to the rest of the collection!
One other question - for Loneoceans’ Lume drivers in my FFL lights, are those going to be incorporated into your updates and version list or remain separate?
(as if this is not already a ton of work already… sorry!)
I can also now say this update has fixed a similar annoyance I’ve always had with my Q8+… I’ve always kept the button aux completely OFF when the light was unlocked because of how bright they are. Not an issue when running the light on turbo, but from medium-ish on down to moonlight, it’s distractingly bright.
Now I can have it on full when the light is off and it’ll turn itself off when I turn the light on.
It’s quite a nice QOL change… thanks again!
There is a patch to add support, but the patch needs some significant changes and refactoring before it’s ready to merge into trunk. I’ll need hardware to test those changes on, and to do future maintenance… but I don’t have hardware.
So I need to talk to Fireflies to arrange what is necessary for proper support. They used to be pretty good about this, but I haven’t heard from them in years. So most of their models produced in the past few years aren’t supported.
Yeah, someone was having issues with preflash, so I did a bunch of testing and experimentation to try to find ways to reduce it. Mostly just adjustments to micro-timing of driver component activation. It didn’t fix the issue they were having, but it has completely eliminated preflash on every AA/14500 Hanklight I tested.
Gotcha…
Well, thank you again for all of this, TK!
Tying rotary controls (potentiometer, hall sensor) to Anduril 2? More hardware would be needed, and likely some software to translate knob position to the ramp. Anduril offers something that no other commercially available UI (which I’m aware of) currently does, the ability to set a ceiling and floor cap, and have the brightness selection scale according to that ramping window.
So, tldr, is it possible to integrate an “infinitely variable” tailcap control ring that ONLY controls brightness according to the brightness window?
I.e. ceiling is clockwise max, floor is counterclock max.
**I definitely foresee an issue with much higher standby drain, but it could likely be remedied with a few tweaks to “only detect ramp if on”, or tweaking the frequency of ramp detection.
I.e. if eswitch is off, frequency of detection to once every 20 seconds. Or, probably better, if switch off, then standby, if switch on, rotary sensor gets the juice first then sends that position info to driver
I got a question about new lume x1 hank configuration file of Anduril 2.
In anduril/hw/hank/lume-x1/anduril.h (Release 2025-07-07) there is a line:
#define MAX_1x7135 49
But why it is there? I thought this is a boost driver and all output is regulated?
It is just a name from old days. If you want, you can rename it to whatever you want. But rename them all.