Anduril ... 2?

Awesome! This will be greatly appreciated by many.

It would be cool if changes made in Advanced/Unlocked Mode (normal) could be persistent in Lite/Simple Mode. E.G. If you set aux to blue they stay blue. Otherwise I agree, voltage should be default.

RE: config modes, when I first started using Anduril, I found properly entering the right config (specifically for aux mode + brightness) to be the most obnoxious/difficult, counting between 4-6 clicks while being distracted by the flashes etc. I don’t have a suggestion per se, except maybe to eliminate how close they are to one another (ie config aux brightness with 4C, aux mode with 6C, 5C = nothing).

Lastly, and I suggest this now while you’re still in the planning phases of A2.0, it would be really neat to offer custom shortcuts (or even just one)—>
Leave a click combo open to be set by the user for a custom action.
For example, 3H could be reserved for whatever the user configures it to be in Advanced/Unlocked Mode. In my case it would be changing aux brightness from low to high. I don’t want to have to cycle through off and blinking every time.

For others it could be a particular strobe mode, beacon, or whatever. Maybe toggling between two particular tints.

Offering the ability to customize the actual user interface (with custom shortcuts like this) would set 2.0 apart as a truly major upgrade, not just UI refinement to make the firmware easier to swallow for the masses. jm2c

I like everything you’ve proposed. Is the intent to have it be fully functional on ATtiny85 equipped lights already out on the market?

The “Simple UI” out of the box is a great idea, and that UI flowchart makes a ton of sense for just anyone getting the light for the first time. Like muggle mode currently, the ability to go back and forth between the Simple UI would be beneficial for if one would want to lend someone a light, but wouldn’t want to completely reset it. Using the same keybind, like 6H or whatever is determined to be the choice, would make it easy to switch between the two.

A timeout autolock function would be good for touchy lights like the FWxx series, but having the ability to toggle it as an option on device that would remain until factory reset would be excellent for times when you don’t want to have the light lock out. Perhaps have it set as a long sequence while locked out? Like 8H so there’s minimal chance that it can be accidentally toggled while the light is actually locked out.

Momentary on lockout should absolutely start with the lower of two ramps imo*

Aggressive throttling on repeated turbo use could be good, or some way to functionally limit total power delivered dependent on a pre-determined temperature threshold.

Minor suggestions for compile-time options for anyone wanting to flash themselves or alter options to their liking:

- The ability to have Simple UI off after initial boot/reset but still retain the functionality and option to enter that mode. Just an ease of use function for power users.

- *Option to toggle momentary on lockout be either lower of the two or how it functions currently, if such a thing is easily done and if folks like how it functions currently. No reason to toggle on device.

Thanks again for all the awesome work you’ve done for the community!

Great ideas, TK. I didn’t see stepped mode explicitly mentioned. Please keep that around. It’s my primary mode.

I agree with pretty much everything, especially that 2-level momentary should default to the lower setting, config mode should be harder to access, and auto lock is a great idea.

Thanks, again, for Anduril and everything you contribute to this hobby.

First thing that comes to mind is more sensitive thermal sensor. Realtime if possible. Would be useful for keeping hotrods safer from self destruction.

Like reducing current very quickly (within 1 sec, disable turbo, etc) until it’s under the set thermal limit.

I like the idea of default mode being a “simple” or “standard” UI with the option to switch to “advanced” by some longer sequence of clicks; 8H is likely to be virtually impossible to hit in error.

Because this would be a big change I would like a distictive name, at least to Anduril2 or something totally new. I have no suggestion off hand.

I really like the momentary lockout where we can select ML or the slightly higher floor level with a single or double click-hold when locked out.

Brimir is a more general word for the sword in mythology.

How about naming it with ‘Ringil’ since it doesnt backward compatibility.
Cant hardly wait to buy FL with this new firmware.

Anduril LITE for my kids sounds great!

I like it, it’s similar to how the ex11 is but worth a few extras. Ramping with battery check and lockout. Perfect. You could hide the ramping vs step in the advanced menu and save in eeprom. I think most here want just ramping or stepped ramp, not both. So in theory you would set that, the temp limits and calibration, and never be required to go to the advanced menu again.

My suggestion would be to make 2H from lockout activate memory mode of current ramp option. I can see how that could pose problems if manual memory isn’t enabled but maybe have it only do so if enabled, or have a toggle in the settings if there’s space?

The one thing that’s tough for me is deciding whether to set stepped ramping to a level low enough for regular use, or have it higher so my second lockout level is bright enough for what I want.

Every other change is fantastic, including making lockout always use the lower of the two settings for 1H.

The battery voltage readout on some of my lights is off by over 0.1 volts.

A voltage calibration function similar to the existing temperature calibration function would be a welcome addition to Anduril.

I am prepared to unlearn and relearn ….

ToyKeeper, I like your plans to improve/upgrade Andúril.

Here are some of my thoughts:

Thermal configuration

Accessing pre-selectable, user-defined step down temperatures would make it easier to toggle between a safe, conservative and a high performance setting. At least two temperature thresholds to choose of and that the user can define by the known click series would be fantastic. It would enable the user to operate the light with all features but also with the option to easily switch between something like 45°C and 65°C as the stepdown threshold. As an alternative you could also wipe the entire thermal configuration click series and only offer selectable, fixed thresholds to choose like 40°C, 45°C, 50°C, 55°C, ... up to something like 'no stepdown at all' or maybe 80°C.

I also agree that aggressive throttling on repeated Turbo runs might be a good idea. But it should go in line with user-defined step down temperatures, i.e. with safe settings in place it should not step down as aggressively.

IntelliBeam® feature

I like the idea that Surefire pursued with their IntelliBeam® feature ("IntelliBeam® automatically and seamlessly adjusts output to the optimal setting"), i.e. the driver will immediately step down when placing something in front of the flashlight, like a hand or if you put it onto a table. This will add some extra safety to new flashlights but it will require some hardware add ons in new flashlights. With the aid of a sensor (black rod) in the reflector the back-reflected light is measured. If it exceeds a certain value the driver automatically reduces the light intensity in a fraction of a second. Maybe it's worth to have something similar in more flashlights other than Surefire.

Submenu for manufacturer custom modes

With many new flashlights coming, maybe it's worth to leave some room for a submenu that each manufacturer can fill with their own customizations, e.g. for operating multi-emitter lights with different LEDs, colors etc.. I have lots of ideas on my mind like an auxiliary red LED in addition to white light that the user can operate separately.

Concerning new names for this firmware...

Well, if we stick to the Tolkien universe it might become difficult to find another sword that is as glorious as Narsil or its successor Andúril. ;-)

With that said, maybe we can name this one Galadriel (a.k.a. the Lady of Light). Galad is a derived word for "light" in Sindarin (one of the most important languages in Middle-Earth). Galadriel was one of the greatest of the Elves in Middle-Earth, surpassing nearly all others in beauty, knowledge, and power.

I think this is a fantastic idea. I agree that the name should be distinct with this many changes, but am ambivalent on whether it should be “Andúril 2”/”Andúril One X”/”Andúril Infinite”/”Andúril 12 Pro Max” (if the ‘brand recognition’ of Andúril is significant enough), or if it should have a different Tolkienian name.

Would like to see support for second e-swtich.

+1 :+1:

I like all the suggested improvements.

Making config mode less easy to get into would be appreciated by me.

IMO going from lockout straight to on/ramp really stands out as an excellent idea.

Re naming the two modes I think Andruil 2 Basic and Andruil 2 Advanced sounds best.

If you changed the name entirely Andruil would surely have to have distinct advantages of its own over ‘Andruil 2’ for it to remain a viable option next to the second UI, for people buying flashlights. And if your improvements work out well - it won’t. Then in my reasoning Andruil (as a brand) would sadly become obsolete. Hence I like Andruil 2 instead of name change.

May be wrong but those are my thoughts.

Thank you for all your hard work Toykeeper, your thoughts on improving the ui sound very promising.

Firstly, thanks ToyKeeoer for all your work on this. Anduril is brilliant.

Would you consider moving development from bzr to git for version 2? Obviously it’s your baby and your workflow us most important. My guess is that switching to git would remove a barrier to entry to help encourage more contributions. Personally I’ve only used bzr a tiny bit and don’t grok it like I do git.

Splitting into multiple files sounds like a sensible move too. I find it much easier working with object oriented languages, so a monolithic C file is a challenge.

Thanks again.

I’m sure I’ll have more thoughts on this, but the first thing that comes to mind is to remove the blink at different stages in the ramp. They’re useful dev features, but they don’t add much to the usability, and people who don’t know what they are always think it’s a glitch.