Anduril ... 2?

Don’t know if it’ll help but per the anduril 2 manual
in the lockout section :

“2H: Light up at the highest floor level.
(or the manual mem level, if there is one)”

So your 2H is probably your manual mem setting…

Yup this is it thank you! Lockout 2H was my memory setting… This is probably why the Anduril2.hex was just published, that line of the manual wasn’t there on the 25th!

Anduril is great. Thank you Toykeeper and other helpers and contributors.

Take note that hybrid memory seems to affect the Lockout 2H as well, until the timer is up it will use the highest ceiling setting rather than your manual mem level. I was confused why this was happening until I let the light sit for a couple min.

D4Sv2 and KR4 are both using the 9/25 firmware and have been working perfectly so far. Haven’t done any graphing or real measurements other than a quick check with an IR thermometer, but thermal management seems to be functioning well- definitely stepping down when it needs to and smoothly as far as I can tell.

Lockout mode uses the manual memory level for 2H, if that level is non-zero. Otherwise it uses the higher of the two ramp floors. The hybrid memory timer is not even considered… and neither are the ceiling levels.

If your lockout 2H level changes after the light sits for a few minutes, something is broken.

The code is a pretty simple algorithm:

  • If the user pressed 2H:
    • By default, use the highest of the two ramp floors.
    • If manual memory is enabled (at all), use that level instead.

That’s all. There is no logic to change brightness based on the amount of time it has been locked.

Indeed this is what I also experience: 2H is always the manual memory (unless manual memory is disabled) (on the older software compiled by myself the 25th).

Yeah, the “lowest floor first, highest floor or manual mem” thing was added on 2020-08-05. So it has been that way for a while. I just didn’t remember to update the documentation until a month and a half later.

Full details are in the revision history, for anyone who cares enough to look. There’s a lot of detail though, since there have been almost a hundred revisions in the anduril2 branch alone… in addition to the ~1160 or so revisions currently in the parent repository.

Just tried it again, must have hit the the first of the manual/hybrid mem menu options by mistake and disabled manual mem. When properly set 2H-lockout functioned as normal with hybrid mem enabled. :+1:

Does anyone know the version that would work with the FT03 sst40? I was gonna red lash but it’s running narsil

Do you want Anduril 1 or 2 for the FT03? The driver requires some patches for the “uncommon” channel configuration. Here are the necessary changes:

If you like I can rebase it on the latest version of Anduril 2 tomorrow and send you a build.

@ToyKeeper
Would be great if you add a way to make this work upstream. For the 1634 the definitions are already in the hwdef config, maybe this should also be done for the 85.

Yeah that would be great, thank you so much

@Pathoz
Here it is. Haven’t tested this build, but one a few revisions ago.

Just flashed my PL47G2 with anduril 2.When pressing 3C from off,I got this sequence:
-batt check
-beacon
-temp check

1)The sequence is different than explained in the manual(batt check,temp check,beacon, sos), is that normal?
2)Any idea why I don’t have sos mode?

SOS is probably disabled as a default. I always understood the order to be batt/beacon/temp - this is how Anduril and Anduril2 work, as far as I know. With Anduril2, you can disable beacon too ()

Thanx, any idea how I can enable it?By editing the firmware file or by button presses?
I cannot find anything about it in the manual…

In config-default.h:

// boring strobes nobody really likes, but sometimes flashlight companies want
// (these replace the fun strobe group,
// so don't enable them at the same time as any of the above strobes)
//#define USE_POLICE_STROBE_MODE
//#define USE_SOS_MODE
//#define USE_SOS_MODE_IN_FF_GROUP // put SOS in the "boring strobes" mode
//#define USE_SOS_MODE_IN_BLINKY_GROUP // put SOS in the blinkies mode group

So, you have to edit this file, or add the #define's to your cfg file. It's compiled in or out, so you can't add it via the UI.

Thank you very much :wink:

Is the following possible?

[a] 3 stepped modes + optionally a hidden turbo
[b] Configure all 3 (or 4 in case of turbo) of them with whatever lumen value I like.
[c] Optionally: Groups

I tried all sort of stuff and always come back to something simple.
[a] I have in both my favorite lights, but [b] would really set it aside from other UIs. It would instantly solve all complaints about bad mode spacing.

[c] Very much like the Convoy groups. But this time the user defines the values as described in [b]
Just a few groups would be great. I would make a Indoor, Outdoor, Speciality groups.

Is something like the above possible with the new UI?

Thanks! I’ll have to include this soon.

About the channel configuration, it could definitely stand to be refactored. It’ll probably require moving some setup code out of FSM though, and into each tiny85 hwdef file. That part of FSM was written when every device used the same pins for PWM, so it didn’t need the extra flexibility used in the later hwdefs.

Looks like this was already answered. SOS isn’t included by default, since every time it comes up, people almost unanimously say they don’t want it.

I’m probably going to change the order of the blinky modes though, before calling Anduril 2 “done”. I think Tom makes a good point, so I’m thinking of changing the order to:

  • Batt check
  • Temp check
  • Beacon
  • SOS

… and some of these may or may not be included, depending on how the build target is configured.

I’m not planning to put version check into the blinky group though. It’s too useful for customer support purposes to hide it at the end of a hidden mode group. So it is intentionally easy to reach by doing “click a bunch of times (15 or more)”.

A. Yes. The stepped ramp and simple-mode ramp can both be configured to have 3 steps. Simple has no turbo, while the regular stepped ramp does.

B. No. It only allows setting the floor and ceiling levels. Intermediate steps are calculated automatically. However, you could adjust the ramp shape in the source code in order to change the spacing of intermediate levels. If you prefer more low modes, use a steep ramp like x^9, and if you prefer more high modes, use a gentle ramp like x^2.

C. Ish. There is a smooth ramp, a stepped ramp, and a simple-mode ramp. Each can have different configuration. Part of the reason why these exist is so people can have one configured for indoor use and one for outdoor use, with a quick and easy shortcut to switch between.

The default and recommended configuration is to use smooth indoors, stepped outdoors, and simple mode for when someone else uses the light.

[B] What I’m after is this: 5, 15, 30 lm, and turbo of whatever value the light doesn’t step down quickly. Likely in the 450-800 lm range.

Not sure if it helps at all, but I generally only use steps 1/7, 2/7, and occasionally 3/7. And maybe once in a while, 7/7. This gives me two or three decent low-to-medium modes and a burst mode… and the extras in-between may not get used but they’re also not in the way. It’s not like a clicky-switch light where the user must cycle through each mode while navigating.

Another way to configure it is with 3 steps, with the floor at ~5 lm and the ceiling at ~50 lm. Then it’s just three steps and there can still be access to turbo if you want it.

Or use the smooth ramp, so the number of steps won’t even be relevant.

If consistent runtimes are needed at such low levels, another option is to set manual memory to ~15 lm, go to the smooth ramp, and set the manual memory timer to a short value like 1 minute. Then it’ll always turn on at the same brightness, unless it was turned off very recently. It basically becomes a 1-mode light with the ability to temporarily adjust brightness if needed.

If none of these options are acceptable, sources are available including a UI toolkit and a couple simpler example UIs which can be modified to use arbitrary levels.

So… there are options. None are exactly as requested, but some can be pretty close.