I have one improvement idea….I’m not sure whether it can be done with software alone or whether it requires special hardware but I’m sure you TK know. 
The aux LEDs when running low are not very visible during the day.
At the same time they are brighter than moonlight and actually disturbingly bright during the night.
Maybe it would be possible to detect ambient lighting conditions with the main LEDs and adjust aux brightness accordingly?
It requires special hardware. No supported drivers have this capability. Even the FW3A’s optic nerve can’t determine ambient light levels, since its signal is highpassed to pull it down to zero.
However, one question. Did you mean to say “The aux LEDs when running high”? Because on low, they’re usually nowhere near the brightness of moon mode.
No, I meant low. I’ll re-check that this night because maybe they were not running at the level I thought they were…
Another small fix in changeset 472.
BTW, what gcc version do you use?
I use 9.2 and a few images don’t build:
Another e-switch: https://www.washingtonpost.com/nation/2019/12/05/miguel-wattson-electric-eel-tennessee-christmas-lights-twitter/
This link leads to a paywall. They want me to pay either with cash or privacy and don’t serve content unless I do.
I checked that:
It’s very likely that I actually used high.
That said, the lows could really see some improvement.
The different colours have very different brightness. Blue is less bright than moonlight but nevertheless disturbingly bright at some angles.
Green seems slightly dimmer to my eyes and red is much much dimmer. White is not white, red component is completely invisible…
I’ll try to improve this. Sounds like a good noob task. 
ADDED:
If I understand that correctly - this is controlled purely by hardware, not by software. 
I thought that picking the best compiler version would be a possibility to save a few bytes.
So I tried gcc 6,7,8,9 to check which produces the smallest output.
gcc 8 won.
But it still can’t compile these 2 configs which makes me thing that TK may be using something even older than that…
Try with gcc-avr 5.4, maybe then it works.
I’m not sure this is the right place to ask, but will files for the Astrolux HL01 eventually be added to the /torches/fsm/ download list? I’m not yet sure how to hook up that light for flashing, but I’m sure it can be done. And I always get a kick out of upgrading.
That probably depends on whether Astrolux gives me a copy of the source code they used.
It’s one of like a dozen apparent license violations I’ve been meaning to chase down…
With the new Haikelite HK04 (quad XKP50.2) on VTC6D cells and spring bypasses, the max of 70C doesn't give me 30 secs, best I can get is ~22 secs. I need a bit more headroom. Sure would have been nice to know this 70C max limit - I've been clicking 50 times, 60 times, 70 times over and over again - no idea, til i came across this thread and this post in this other thread: https://budgetlightforum.com/t/-/54947/161.
Could you please at least update the latest Anduril manual in the repository with this limit? That should be the ultimate ref. I re-read a "few" of the hard copy Anduril manuals I got and couldn't find it.
Btw, I don't see any config file in the repository for the HK04 - is HL doing this stuff on their own? Funny - their website doesn't exist anymore, or is temporarily down, dunno - used to be Haikelite.top.
Update: forgot to mention it's a quad XHP50.2, measured 37 amps at a min on full turbo (before spring bypasses added), does about 15,000 lumens at start and is the size of a SP36, so yes, it does get hot. Maybe even a max of 80C would be fine.
I converted Anduril to VS7 a while back, wasn't that difficult but think it took a while. Also, I seem to recall to be able to keep the code base current, it would be an effort. I know it compiled and built fine, think it was smaller code size than i expected as well - not sure of that though.
Just checked - I did this back in Dec 2018, so might not be as easy now.
I really shouldn’t be surprised, but I still am. Chinese manufacturing really is the wild west. There is no law except what can be enforced at the end of a gun.
I hope Astrolux gets its act together and complies. Anduril is the reason I bought the HL01.
I just built the latest version, 464, of Anduril on Atmel Studio 7, latest version. The key things I did:
That's basically it. This is what it resulted in:
Program Memory Usage : 8122 bytes 99.1 % Full
Data Memory Usage : 205 bytes 40.0 % Full
The other important thing is the files: where to copy them, what files to include, etc. I took the simple approach and moved them all into just one folder.
I built it for the Q8 for now, but will try others. The HL HK04 light I'd love to change to rise the max thermal limit, as defined in fsm-adc.h:
But the HK04, like the SP36, has the driver glued. I tried removing the switch to get access to push out the driver, but the switch has some nasty glue - I destroyed it partially in trying to get it out - never ran into this before. I killed one of the LED's. Ugh...
So, it looks like as of now, these flashlights use Anduril, but have not released the actual source code used (ie. unknown which Anduril “build target” they were based on:
Astrolux EC01
Astrolux HL01
Astrolux FT03S
Haikelite HK04
Thanx TK! I see your manual update 
I sense a pattern here…
Can we as a community put some pressure on them to release the code?
How? Anyone have an email address for Mr. Astrolux or Mr. Haikelite?
Haikelite's website even disappeared.
Hhmm - Astrolux does seem to have a website: https://www.astroluxlite.com/, but of course the Contact link is dead, but the brand link does work: https://www.astroluxlite.com/support.html?article_id=5
Based on their websites, they are a mess for sure...