Anduril ... 2?

Go to the Advanced UI (if you are not there already)

From OFF => 3C to Battery Check => 2C to Temperatue Check => 7H (click 7 times but hold the 7th click pressed)....keep holding until you see the first flash....still keep holding until you see a second flash....then release the button....your flashlight will start click as many degrees Celcius you want the limit to be above 30°C, i.e. 20 clicks for a thermal limit of 50°C. When finished, just do nothing....wait until you are back in temperature check.

Anyone able to give me some guidance as to how to add files to atmel studio on windows?

I’m trying to build anduril as as a project within atmel so I don’t have to use the bootleg method of editing each file then compiling it using the build all script.

I haven’t found a way to add anduril files into atmel studio though. If you’re on windows, could you do a quick screen record of how you do it, or point out what I’m doing wrongly?

EDIT: I followed this guide and it worked, yay!

Ich danke Ihnen.

Thanks L-P! Your K1 is configured higher than stock, so try 60 clicks for 90C - think the max is 90C on yours. If you click more times than max, it will set it for the max.

Small heads up - the ability to #define DEFAULT_AUTOLOCK_TIME and to compile in your own temperature offset (avoiding needing to recalibrate if you flash firmware at temperatures other than 21°C) has landed !

I’ve also discontinued the “ramp low slower” branch with RAMP_HALFSPEED_LEVEL and RAMP_QUARTERSPEED_LEVEL. Now that dynamic PWM exists for more granular moon levels , I agree with ToyKeeper’s assessment that it’s a much nicer experience to adjust the ramp instead .

Thanks again to ToyKeeper for feedback and reviewing!

If you’re wanting to make use of default autolock and temperature precalibration in your own build, here’s an example using the Noctigon KR4-nofet variant:

Save the following as cfg-noctigon-kr4-nofet-yournicknamehere.h alongside the other cfg-*.h files inside […]/anduril2/ToyKeeper/spaghetti-monster/anduril/:

// Include default configuration
#include “cfg-noctigon-kr4-nofet.h”
// ATTINY: 1634
// [Other extra options go here - you can also create a “-cfg.h” like “hank-cfg.h” to include on multiple lights]
// Default to enabling autolock, 10 minute timer
// Manually calibrate temperature offset
#define THERM_CAL_OFFSET 12 // default offset (5) + 7

Then run the build and flash your custom anduril.noctigon-kr4-nofet-yournicknamehere.hex file as per others’ guides. See the comments in config-default.h near #define USE_THERM_AUTOCALIBRATE for help in compile-time precalibrating your own flashlight.

In my case, my KR4 and D4SV2 both use a temperature offset of 12. It’s not perfect, and I’ve erred on the side of reading too high a bit more often than reading too low. If others use this, I’d be curious what their temperature offsets wind up being, too.

EDIT 2021-8-19 4:41 PM EDT: Accidentally put in an #undef for DEFAULT_AUTOLOCK_TIME - that’s not needed.

(moved details over to the FSM thread here: )

Requesting a change to the FSM to be more flexible for ATtiny85 pin I/O selections for output channels for Anduril2 builds. Thanks!

me too. First things I do with every new Anduril 1/2 light:

  1. set bottom of ramp 1/150
  2. set bottom stepped mode 10/150
  3. set top stepped mode 149/150
  4. set # of steps to 5
  5. set thermals to ambient temp
  6. set thermal cut at 50 (edc), 60 (thrower)
  7. set auxiliary lights to match body color if applicable :))

I switch between stepped and ramp almost every time I use every light. I use ramping only if I'm indoors and stepped only if I'm outdoors. Steppped setup like I describe is perfect for me outdoors, and it ensures all of my lights operate the same exact way. No need to double click for turbo, can turn on in turbo, and no need for ML outside.

Hhmm. Yea, the 150 step, 2.4 sec ramp was something that seemed just right to me, but will be too fast for some. I think I was the one that came up with 150 entries, 2.4 secs ramping in Narsil for the Q8, with input from BLFers. TK though originated the first smooth ramping firmware though

TK developed a great tool to generate those 150 element ramping tables (Python script:, but also will support ramping tables of just about any length. So maybe the easiest way to lengthen the ramp time is to grow the table, but still maintain the 16 msec update rate. so a table of 200 will be 3.2 seconds, 240 would be 3.8 secs, etc.

If you want it just a little slower, say at 2.8 seconds, then 2800 / 16 = 175 steps. Unfortunately though, tweaking the table length is not user configurable (wouldn't you love to see that in a UI configuration mode, clicking 175 numbers in? ). There's a few settings that would need to be tweaked of course, like the channel transition points, etc., but we do have spare memory in flash available with the 1634 (Hank uses) or 1616 (1-Series) ATtinys.

So bottom line, it's fairly easy to do in a 1634 or 1616 MCU based driver, and keep everything else in tact as standard Anduril 2. Actually the ramp table and all associated settings are in the driver/light specific configuration file (cfg file), so the firmware is designed to accommodate this kind of change.

Ahh, found the post introducing the Q8 ramping table:

and here little earlier:

way back when...

Whew, Tom, that’s really reaching back… FIVE years ago!

Yea, seems almost generations ago. Funny, got a text from a friend/neighbor begging for a light when "Henri" hits us Sunday. First light I thought of was a Q8, but of course should be running Anduril 2

The 4 3500 mAh cells, decent size to handle a bit of heat, or many hours on low -- just can't beat it no matter what has come out over the past 5 years.

Ohhh - the Q8 thread still holds 2nd place all time on BLF in # of posts:

I’d definitely be down for a Q8 refresh with a driver that has CC or buck channel and new emitter options, just saying. :wink:

Don't get me wrong, I love the ramping feature and how well it's executed, it of course just doesn't always fit all of my needs. It is an awesome tool to have . I just wish some of this hardware crap coming out recently could handle it better, I guess is what I mean, with Super Fast ramping on the low end modes.. makes it impossible to stop appropriately

Wait, are you talking about Narsil/Anduril1/Anduril2 ramping too fast at the low end? Some of those attempts to clone our ramping are super fast at the low end, and super slow at the high end - that's for sure.

Maybe I missed it but I haven't heard much about slowing down the ramping over the last 5 years. This is the first I'm aware of.

I'm with you there. Converting to 3x21700's would also be on my list.

Has anyone else had issues with the size of Anduril 2 lately? I have stock rev 610 and it wouldn’t compile the unmodified FW3A software (attiny85) and gave me overflow errors until I removed a few functions like candle mode.

Edit: I optimized for size as according to this post by MikeC and it is now working. I haven’t had to do this before for attiny85s so I reckon the code as gotten larger unless I’ve always been optimizing for size without knowing it using the build all script

I always use/have used -Os, also you need -fwhole-program. This will reduce the size further.

The size depends on options/config. for the 85, worse case is 3 channels, indicator/aux LED support, and then including all features/functions. I generally drop SOS, though that might be the default now.

What’s this and how do I use it?

From the gcc documentation:

I only use Studio (Atmel and Microchip Studio), so you plug in that option in the "Other optimizations flags:" field

Thanks, enabling it reduced the size from 21.9kb to 21.4kb. Every bit is valuable when you’re at the brink!

Wait what do you mean about 21.4kb? The attiny85 only has 8kb and last I heard it is almost entirely full. The d4v2, which has a attiny1634 processor with 16kb flash, uses about 9k of it in its anduril build. That said it should be possible to squeeze at least a few hundred bytes from the code at the possible cost of needing a little refactoring of FSM client code.