Anduril ... 2?

It’s an interesting idea, but depending on the details it may be getting into the territory of becoming a different UI. Like, it could let the user customize every button sequence, similar to the YLP Unicorn, but then it wouldn’t be Anduril… it would be something else. So it might be better as a separate project.

Perhaps there could be one blinky in simple mode, but I’m not sure if people would like that or hate it.

It sounds like you should design a new interface which has these things. I’d suggest using a new name for it though, instead of Anduril.

Yeah, I don’t know of a way to make it easier to access without sacrificing something more important.

I don’t think a separate UI for biking is likely in Anduril, but a bike-specific UI could be created. For now, the closest it has is the strobe mode memory which can go directly to the bike flasher with a click-click-hold.

There are already two shortcuts to strobe from off:

  • Navigate to the strobe you want, in the strobe mode group. Then turn the light off. Afterward, a 3H action goes directly to that strobe, using the same settings you left it in.
  • For even faster access, after you turn the light off from strobe mode, click 5 times for momentary. Then simply holding the button activates strobe.

… and in the update, I’m also adding a thing to make that second option easier. Go to the strobe you want, then click 5 times to go directly to momentary. No need to turn the light off first.

Not sure about having two temperature limits in regular modes, but perhaps it could do something like set the Simple UI temperature limit 5C or 10C lower than the Advanced UI limit?

However, given the issues with factory calibration (or lack thereof), that means a much higher chance that the Simple UI would think it was always overheating. So it could be a significant usability issue for the people the update is intended to help the most.

It’s something to at least keep in mind though, since a lower limit in simple mode would help with the goal of safety.

I’d like to keep that one easily accessible, in part because I use it a lot. It’s supposed to be quick and easy to switch between ramp styles. Have heard from a few other people who switch back and forth a lot too, like what Klayking mentioned earlier.

This is much more tricky.

Probably won’t happen in Anduril, because the UI for it would be a huge pain to use. A big part of why it works the way it does now (floor, ceiling, number of steps) is to avoid setting the levels explicitly. I’ve never seen a UI implement that well without requiring a separate configurator app, and a configurator isn’t feasible on most of the lights Anduril supports.

If you can think of a really slick way to configure the levels though, perhaps it would be feasible.

I can’t add these with a firmware update. They require hardware features which don’t exist on most (or all) of the lights Anduril supports.

I’m playing with my new IF25a which is my first Anduril light today.

While off: Changing the aux light brightness requires seven presses.
While in software lock out: Changing the AUX light requires three presses. I believe this should also be seven.

Here’s why:
I intend to use this feature to show a dim aux when in lockout and a bright aux when in normal mode. For me this is a safety function and lets me know at a glance which mode the light is in. I expect it will also encourage me to set the lockout at night when I put it on my night stand. However, I’ve already found I’m prone to accidentally changing the setting while trying to take it out of lockout mode. For consistency sake and to prevent user error, I feel both modes aux lights should require seven clicks to change. People might not prefer extra clicks but I doubt many people change their aux all that often. Maybe on a D4v2 with different style AUX lights? If I could somehow lock these settings I’d be happier but I’d be just as happy if it took 7 clicks in both modes. It’s too easy to accidentally change.

Thanks for all the work you do. Anduril is awesome and I love the name too. If we have to mix it up I vote for Eärendil to be the new name.

I think the thermal calibration is going to be one of the toughest issues making lights safe. As things currently are, basically every Anduril light needs to be configured first thing.

As for changes to Anduril, I’d like to set the light up how I want it and then turn off all the config menus. Temperature calibrated? I never want to end up in that menu again. Ramping set (instead of stepped)? Get rid of it. On my LT1, I actually frequently end up messing up either the tint ramping or switching into stepped ramping. I think the issue lies with setting the double-click from off to not be turbo. So I end up “triple clicking” instead of going “on” and then double-click (3C instead of 1C;2C). Double-checked it; my FW3A came by default with 2C from off to top of ramp, whereas the LT1 came with 2C from off to the maximum brightness it achieves. I guess I’ll go find the instructions to set top of ramp to max and try the FW3A again.

This is a great idea TK! The 2H shortcut is so easily accessible but it currently does something mostly useless (IMO). Perhaps this could be used to go straight to Turbo from Off?

Pretty slick setup Klayking! I’m constantly tweaking mine as well. I like what you’ve got going on here and I’ll probably adopt something similar. I’ll likely use stepped mode to have a dedicated max regulated level as that will let me take advantage of the efficiency without having the blink in smooth ramp. I’d like more than 3 steps though so I’ll have to do some math :slight_smile:

Yes. But your feedback matters to manufacturers.
If you feel something listed above makes sense you can communicate that to them - and it’s likely that some future hosts will get such support.

I agree, coming up with a slick system for this on a single button UI is tricky. Here’s the simplest I can think of:

  1. Enter step config mode with whatever shortcut is used and the light will flash once then start buzzing as it currently does.
  2. In config mode, press nothing: the buzzing will stop and config will exit.
  3. In config mode, press once to set the lowest step at output level 1, and keep clicking to raise the level of this lowest step.
  4. When happy with the lowest step’s output level, wait a moment and the light will flash twice to indicate step 2 config is starting, followed by more buzzing.
  5. Step 2’s config will start at the same level you clicked to when setting the first level. Clicking nothing will cause the config to exit and save your single step. Clicking once will advance to one level beyond the first step, and more clicks will keep moving up in brightness.
  6. Repeat the process of adding more steps, each brighter than the last until you no longer want any more steps. Allow config to exit.

Thanks to continuing on from the last step, I don’t think this will be anywhere near as painful to config as my initial idea of bashing out a number of steps, then a number between 1 and 150 for each step. I can’t see this taking appreciably longer than the current step setup to configure, though there is indeed a slight increase in complexity. As this would be located within the advanced mode though, I think the extra control over your stepped levels would be worth it. I’m interested to hear what everyone else thinks about this though.

I think this is neat, and have an idea.

First, to have less levels only for this menu (let’s say 30, with a known level for each mode that doesn’t use PWM, so you have a reference. Maybe with a formula you can relate the levels from the 30 ramp and the 150 ramp, like multiplying by 5, except level 1 that remains the lowest). This reduces the ammount of clicks and still allows room for enough choice.

You enter configuration and on the first ‘buzz’ you enter the number of modes (also allowing a single mode, that would be nice). Now it asks as many ‘buzzs’ as modes you have put, and you just click from 1 to 30.

If you configurate more modes than you had previously, it remembers the modes you had on first place (if you don’t touch anything during the buzz), and adds more on top. If you eliminate modes, it eliminates starting from up, and deleting the highest ones. You can also edit just one mode, leaving the rest as it was just like you can do now.

For a typical 4 mode configuration, let’s say that you need about 4 + 2 + 7 + 12 + 25 = 50 clicks as an example. With the current interface, seleting 4 modes, floor on level 10 and ceilling on level 125 you need 4 + 10 + 26 = 40 clicks. Not that much of a difference and you get to choose with more flexibility, although you give up your 150 levels (just for stepped, not for ramp). You can’t stop that precisely on the ramp anyways.

In addition, you can even configure special modes, such as candle mode, to numbers higher than 30, or with holds instead of clicks. The brightness of said candle mode (or freq of strobe or beacon…) would be adjusted from the original special mode location.

Maybe this last thing is overcomplicating it :stuck_out_tongue: .

I’d like to see LVP for indicator lights. I think it was on your list before, pending a rewrite, and this is a rewrite :slight_smile:

If we’re talking about breaking changes, I’d like to really push the envelope and suggest something really different! As more and more flashlights are including built-in charging via USB, I think it would be great to use the USB interface for configuration as well. The most versatile method would be to have the USB interface mountable as a flash drive. That drive could contain 1 (or more) configuration files (JSON?) that define the configuration, available modes, etc. This way, anyone could use their computer to modify the configuration (directly or using a GUI). Could even allow developers to flash updates over the USB interface too!

This would solve the problem of accidentally getting into configuration mode, allow for broader updates, and allow for easier control of the configuration. Not to mention, you could share configuration templates.

While that sounds amazing, I think it would require some significant hardware changes. If there’s no flash storage/USB controller built in and I doubt any lights on the market have this, then there’s nothing to program this feature set for. I’m not an expert on flashlights though just my take as a computer nerd.

You are right. There would need to be a USB host added to handle the communications (such as the MAX3421E). There is storage available though it is probably just EEPROM and not flash. (I personally have no experience with flashlight firmware - although I’ve looked at the Arduino code. I primarily work with ESP8266 and ESP32 chips which have WiFi. I can store files on the flash as well as host a full website for configuration.)

Additional ideas:

  • Add support for OLED display’s to show things like level, battery, etc.

First of all, thank you for all of your hard work bringing us these awesome U/Is!

I love anduril and have gotten really used to it but would still love to see you offer a second version. We would get used to it pretty quickly im sure.

I havent yet read through all the comments so I dont know if this has been mentioned.

Could we pretty please have a simple version of anduril that:

1) Is always automatically locked out after turning off? Unlock would be a double click, which also turns it on to a level you can choose. Always just a double click to turn on the light. This will solve all accidental turn ons and eliminate so many button presses for theose who use lockout regularly. (Another way of putting is is one click is batt check, 2 clicks turns on light to memorized mode)

2) Still has quick, easy access to full brightness?

This would be achieved by using the following:

From off:
•One click would give a moonlight level bat check and would be a notice that light is locked out.

Holding the button down (1h) from off/when locked out, is momentary, as usual.

Double click turns on to your last used mode.

1 click + 1hold (is that called 2h?) turns on to moonlight.

•3 short clicks, instead of being batt check from off, goes to top of ramp.

•3 click +1hold goes to strobe.

•4 clicks from off goes straight to turbo.

From on:

•One click turns off.

•Double click toggles between turbo and memorized mode.

•3 clicks to toggle stepped /smooth ramping just like old anduril.

•2 clicks +1 hold= tint ramping just like old anduril.

All other functions gone, or in a more advanced u/i that is hard to access.

I dont like lights that have a hard to access buttons like in zebralights. Though they are nice for keeping the light from turning on accidentally, they are hard for my fat fingers to operate easily when there are multiple button presses needed, especially when cold and/ or when wearing gloves (which is the case alot here in the icebox of Colorado) so that’s why I like the fw series so much. But the accidental turn ons are an hourly thing with me if I dont lock out. Its a little tedious having to click 5 times each time i want to use the light (quad click to lock or unlock,+ one click to either turn on or off, plus another to adjust brightness if neccessary. Thats alot of clicking every time I want to use my light (which is alot, every day).

Check out this post: https://budgetlightforum.com/t/-/62655

It has info related to the firmware that runs on different lights, and how to find the source code.

Thanks Toykeeper for all the work and dedication on these flashlight Uis, and thanks also for reading and pondering all our comments.

I like Andùril, but am far from being an expert. I barely use the basic stuff - long press to floor, ramping, double click for turbo, three clicks for battery check… I sort of memorized how to set aux leds or start candle mode, but have never gone into any setting adjustment or calibration. Frankly i feel like i’ve dropped into a geek fest of some sort here.

If i may deviate a bit from the accepted logic that everyone can click, click hold, long click or double/triple/quadruple click or else… i’d say that in my experience, a lot of people cannot distinguish a single fast click from a long or “hold” one. I see people pressing the button like they want to squeeze something out of it and it will register as a 1H although it was supposed to be a 1C.

A lot of people don’t expect a flashlight to have different modes or brightness. They just grab it because they need light, press the button, sometime with a very strong intention, and expect to have a decent amount of light to help them right now, without learning a UI diagram or practicing how to properly click that button. If they don’t get what they want they’ll click again until.

A simple UI should take that into account IMO.

PS: i agree with not renaming it. Andùril 2 or something would be more appropriate and productive then a totally new name.

Plasticity, in the philosophical sense as “a capacity to receive form and a capacity to produce form”. In my view, that is what makes Andúril both unique and challenging, relative to current flashlight firmwares. One of the derivates of plasticity is the issue of programmability as a double-edged sword. I will try to elucidate this when I have more time.

ToyKeeper,

Thanks so much for your continued development on Anduril and other flashlight firmwares. It's a lot of work and I'm sure the community has benefited greatly from all your work!

I'll leave the UI suggestions to more experienced members here, but generally I like the list of proposed changes already. The only items I can suggest are not quite UI based, but just from some of the work stemming from the Lume flashlight drivers... so I'm not sure if they are that relevant or not for this thread.

  • Native support for enable pin in a more granular fashion - the current Anduril implementation for some of the new Emisar lights has most of the functionality but leaves EN high when it doesn't need to be, for example during FET usage. For the Lume driver I had to add some custom conditionals in code to turn it off when not being used.
  • Support for external algorithms in separate cfg file, e.g. a temperature management system - I'd like to implement a fuzzy logic temperature compensation for example
  • Support for external sensors in separate cfg file e.g. external temperature sensor which is implemented for Lume driver, with custom temperature formula definition

That said, Anduril is already super full-featured; anything additional is just a bonus :)

Thank you

You can change the config clicks to 10 or so in the code quite easily, CRX does that on his lights so ramp config is more hidden

the main question is if this means going to another MCU with more memory in the end as 8kb are too small then

That would be perfect IMO!

Some time ago I suggested moving them to FSM to simplify building of other UIs.
I still think it would be a good idea.