Anduril ... 2?

My apologies if this has been suggested - I haven’t read through the entire thread. I’d like to see an option for the lighted switch to have a battery check option. So rather than a simple, steady blink, the switch will periodically broadcast the battery voltage.

To clarify, this would be under the current aux/switch options.

I’d like a timer mode like candle mode but with just regular brightness, maybe swap it for one of the annoying strobe modes nobody uses or likes, oh and a working muggle mode.

I’d like an Anduril feature that materializes $100 bills in the battery compartment, please. :partying_face:

That isn’t too surprising. The way the button-press handling works now is definitely more efficient in terms of code space.

Thought it was worth suggesting, but it is not worth splitting the UI between lights with older and newer chips.

Thanks!

I’m adding a sunset / auto shutoff timer which works in both the ramp mode and in candle mode.

Trying to decide what the button press should be to activate it. In the old version, it was 3C to add 30 minutes… but 3C is already used in ramp mode, to change the ramp style. However, there is nothing on 4C yet, because I moved the config modes.

So this gives me a few options…

  • Use 4C to activate sunset timer. Also adds 30 minutes. (or maybe just 10 minutes?)
  • Use 4H to activate sunset timer. Adds 10 minutes per second until the user lets go of the button. Blinks each time to make it easier to keep track of.
  • Move “change ramp style” from 3C to 4C, and use 3C to activate sunset timer.

Can’t use 2H because that’s used for ramping down. Can’t use 3H because that does tint ramping. So 4H is the shortest hold action available.

For testing, I have it set to 4H… but I’m not sure if it’s the right choice.

There should be an easy way to adjust beacon brightness. I imagine this is a useful function e.g. when having a car breakdown or worser, an accident. But then is should be easily adjustable by press & hold and double press & hold. Right now I not even have an idea how to adjust it. I’m using manual memory. And the pulses should be shorter. While at it, it should go to the other blinkies-set with memory.

4C / 4H sounds good to me. How will the config modes be activated now?

Ramp to the brightness you want, then go to beacon mode.

People have asked for the config modes to be harder to access… so I’m thinking maybe 7C.

  • Ramp -> 7C -> ramp config
  • Tempcheck -> 7C -> thermal config
  • Battcheck -> 7C -> voltage calibration
  • Off -> 7C/7H -> aux LED config
  • Lockout -> 7C/7H -> aux LED config

Or perhaps 6C/6H, since that’s not used any more.

But with maybe one exception. Whatever sequence is used to go from the advanced UI to the simple UI, I’ll probably make the “hold” version of it go to the config mode for simple UI’s ramp.

The details aren’t set in stone.

Yes, I know. Still limited by the upper boundary. And just double clicking to max - off - beacon won’t give the intended result. I think this should be changed :slight_smile:

TK,
I vote for a shorter Sunset default. 5 minutes max, Two minutes would be even better.
Or make the initial default timeout programmable.

Just enough time to snuggle down in bed or sleeping bag.
Then extra clicks for more time if desired.
If the shortest timeout is too long, I’m not going to use it.

It needs some sort of indication that the user has activated Sunset correctly.
Also, going into Sunset, there should be no brighter blinks to blast sleepy eyes.

And I’d like Sunset to step down from whatever brightness the light is currently running at, as opposed to always dropping to a low brightness as default.
It’s easy to start the light where you want it at a useful brightness.
Starting at XX brightness - Everybody ready for bed?
Do the Sunset clicks and the ramp down starts from there.

Also I’d like a stepped down vs ramp for the fade out (an option perhaps?). Like the old Eternalight.
The steps remind me that it is going to go out and I need to be ready for that.

All the Best,
Jeff

In Anduril 1, sunset used a 1 hour timer with a fixed starting brightness, and candle mode used a timer with 30-minute increments at the user’s chosen brightness level.

Currently in Anduril 2, both use the same timer. It uses 10-minute increments, and starts at whatever level the user ramped to. The process is:

  1. Go to the desired ramp level or candle level.
  2. Do a 4H action (click 4 times, but hold the last one).
  3. Hold until the desired timer duration is reached, then let go to start the countdown.
    • While holding, the light blinks once per second. Each blink adds one timer unit to the duration. If the light is in a low mode, the blinks go up in brightness… but if the light is in a high mode, the blinks go down in brightness. That is to ensure the blinks can be seen regardless of the current level.

So to get the same effect as the old default of 30 minutes, it would be: Click, click, click, press-and-hold, wait for 3 blinks, then let go. (4H, blink blink blink, let go)

The ramp and candle modes may share a timer, but they act a little differently:

  • In candle mode, it runs at the given level until the final minute… and then it gradually dims for a minute and shuts off.
  • In ramp mode, it dims slowly and smoothly during the entire sunset period. The idea is to avoid any sudden changes because that might wake someone up.

The algorithm for “dim slowly and smoothly” changed a bit from old to new versions, but it mostly still looks the same. However, when it gets close to the end, the steps are visible because the hardware’s resolution is coarse at the bottom of the ramp. So it’s usually pretty obvious when it gets to the final minute.

The user can still ramp up and down with the sunset timer active… but it’ll fight back, especially when the timer gets close to zero. So I think perhaps ramping up should also “bump” the timer, instead of continuing with the original deadline.

I vote for the “Bump” That makes sense to me.
(And a shorter than 10 minute ramp down - if possible).
All the Best,
Jeff

A quick progress update:

I just hit the point where some build targets are running out of space. So I figured I’d summarize what has been updated so far:

  • Removed Muggle Mode and replaced it with a Simple UI.
    • Simple UI is enabled by default (and after each factory reset). (unless changed at compile time)
    • Simple UI uses a limited-range smooth ramp by default, like Muggle Mode. But advanced users can change this.
    • Simple UI has no turbo function. It can’t go above the ceiling level.
    • Simple UI blocks everything except a few functions: Ramping, battery check, lockout, factory reset, and version check.
    • All config modes are blocked while Simple UI is active.
    • Some settings are inherited from the main ramp: Style (smooth or stepped), aux LED config, manual/automatic memory config.
    • Button mappings:
      • Simple UI 8H -> exit Simple UI and use the full UI instead.
      • Full UI 8C -> go back to Simple UI.
      • Full UI 8H -> configure Simple UI’s ramp settings: floor, ceiling, number of steps.
      • Have been pondering whether it should use 10C/10H instead of 8C/8H.
  • Added some shortcuts for convenience:
    • Lockout 4C -> On (at mem level)
    • Lockout 4H -> On (at floor level)
    • Strobe 5C -> Momentary
  • Added a Sunset Timer in Ramp Mode and Candle Mode. Removed the original Sunset Mode.
    • In either mode, use 4H to turn the timer on and set a deadline. Each blink adds 10 minutes.
    • The time unit is not set in stone. Maybe it could be 5 minutes instead, but then long timeouts (like an hour or two) would be a pain to activate.
  • Added an auto-lock function.
    • If enabled, it goes from Off Mode to Lockout Mode after N minutes of being off, where the user can set N anywhere from 1 to 120 minutes.
    • Button mappings are similar to Manual Memory:
      • To turn on auto-lock: 5C from lockout, then enter a number into the prompt.
      • To turn off auto-lock: 5H from lockout.
    • Undecided question: Should auto-lock still work in Simple UI?
  • Moved Lockout aux LED config from 3C/3H to 7C/7H to make it the same as Off Mode.
  • Moved config modes from 4C to 7C, to make them harder to reach by accident.
  • Removed Beacon Config Mode. Instead, simply hold the button during beacon mode to configure the timing.
  • Added Voltage Calibration Mode.
    • Battcheck 7C -> Voltage Calibration Mode.
    • Allows the user to add or subtract up to 0.30V to the battery measurements, in 0.05V steps. (–0.30, –0.25, –0.20, –0.15, –0.10, –0.05, +0V, +0.05, +0.10, +0.15, +0.20, +0.25, +0.30)
  • Split the code into a bunch of smaller files to keep things cleaner and more manageable.

Three build targets have run out of space, so on these I didn’t include the voltage calibration mode: D18, ROT66G2, MF01-Mini.

Code is in the anduril2 branch if anyone wants to try it: lp:~toykeeper/flashlight-firmware/anduril2

I haven’t attempted to update the documentation yet, or the UI diagrams. I’m waiting until a few more things are decided first.

I like the changes. I guess I need to wait on some mods so I don’t have to disassemble again to reflash.

I vote for 10C/10H, since there are others out there that use that.
I there a reason for 10C vs 10H ?
I would think that 10H would work for going back and forth without the need to remember if I needed a H or C to change things.

Not sure about having lockouts or other functions with just 4C (well maybe strobe).
Does anyone actually need quick access to strobe? Or even use it at all?

Seems like that might be too easy to activate. 4H or maybe 6H seems less likely to the muggles to find by accident.
Clearly you are heading in the right direction vs the current version - Thinks I.
Makes my head spin trying to conceive a simple interface that’s just complex enough. Without accidentally jumping into never never land.

If you are running out of room, maybe sacrifice one of the other entertainment blinkies?
I can see the future now - A-ver 4.01a, only running on 64b OS - 512K flashlights….

All the best,
Jeff

That’s kind of the problem. I need to talk to some companies which asked for 10C as a shortcut to thermal config mode. If they don’t mind though, I’ll probably use 10C/10H for Simple UI stuff instead. Thermal config mode isn’t as important now that it can auto-calibrate during factory reset.

A big part of it is so we can tell people to use 10H to make sure they’re not in simple mode… and it won’t really matter whether they’re in it or not. Similarly, 10C to enter simple mode… and it again wouldn’t matter whether it’s already activated.

In the old version, 6C went back and forth between simple and complex. In the new version, 10H always goes toward more complex, while 10C always goes toward more simple. So there is no need to know where you are… only where you want to go.

This is to reduce confusion for both the user and for anyone trying to help the user. One-way actions are less ambiguous than two-way toggles.

Some people are pretty passionate about strobe modes, and think even “click, click, hold” is too slow. It’s part of the reason why momentary mode can now also do strobes. That way, it can activate as soon as the button is pressed.

Strobe modes aren’t enabled at all in the Simple UI. They’re completely blocked.

The general approach I’m using is… supported lights get as many of the new features as possible without removing old features.

Anyway, anything with attiny1634 still has plenty of room. It’s only a few tiny85-based lights which require compromises. And depending on how some other optimizations go, I might still be able to fit everything. I’ve noticed a couple more things I may be able to reduce in size…

It would be nice if the auto-lockout function worked in Simple UI. If I decide later on to raise the ceiling for Simple UI, the auto-lockout would help to avoid setting my pocket on fire.

it;s going to need a whole web page to explain it all!

it’s almost at the point now that you need [or it would be nice to have] a phone app to track all the config parameters

why not have it control them too??

wle

There are dozens of supported lights. Only one is capable of receiving data from a phone. So for most of the supported hardware, a phone app isn’t even possible.

On the one light which could potentially do it, there wouldn’t be much point. The hardware is difficult to reflash and the manufacturer has not been good about using updated firmware, so the new features would only be available to a few people. It would also require removing a bunch of other stuff to make room.