Anduril ... 2?

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.

So that’s 5 low, 50 high and something like 25/30 mid? Would be good. The lumens I mention are just an indication. If on top of that I can configure a turbo I got all I need.

If I have to swap cells once every 4 hours I’m pleased. Even a AA does that with ease (Tool AA, wish I could reprogram tha one)

So the levels are hard coded? Bit of coding likely won’t cause much of problem. My bigger challenges are finding a light with the right chip that’s not glued down or something like that.

So it sounds what I want is possible with some tweaking.

Is it absolutely not possible to fix muggle mode? Tom said the newer versions are glitch free but this just isn’t true.

Me? I never wrote code that was glitch (feature) free and don't expect it of others

42 years in the biz and you lose all your ego...

I shall just continue to tell people not to return their flashlight because Muggle max ramp keeps dropping back to Min ramp.

(regardless of thermal settings)