Anduril ... 2?

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)

What issue are you referencing? I don't use muggle mode, ever, and am not aware of problems with it. Sorry if I misled you.

Well we’ve talked about it a couple of times in the past and many more have mentioned the issues here and there. Toykeeper has been made aware of the glitch several times too.

Like I said many times, you ramp to Max ramp in muggle mode and it steps down to min ramp straight away, the problem is intermittent.

Muggle mode is potentially an excellent feature/selling point and I do feature it a lot in my reviews.

The lumen outputs are not linear. Human perception doesn’t work like that. If it uses the commonly-accepted cube-root model of brightness perception, spacing which looks “even” would be 5 lm, 19.6 lm, and 50 lm.

Anduril uses a similarly curved ramp to make it appear as if the spacing is linear… even though it’s nowhere near linear in terms of lumen numbers or power usage.

As for power usage, if you’re only at 5 to 50 lumens and it’s using a 18650 cell, you can expect like ~15 to ~150 hours of runtime per charge.

… and for finding a light with an easily-accessible control chip, I’d suggest going to Intl-Outdoor and getting an Emisar or Noctigon light plus a reflashing kit. It’s well-supported and allows reflashing with no soldering. Just unscrew the battery tube, hold the pogo pins against the driver, and run a command on a computer.

There are a few different UIs included with FSM. Anduril is the largest and most complex, but there are others which behave like a ZebraLight or Olight, and the code for those is much much simpler and easier to learn from.

Huh?

Oh. That was fixed well over a year ago, in May of 2019, while people were receiving the first batch of FW3A lights. Maukka reported it while reviewing a pre-production sample, so I fixed it right away… but at that point Lumintop had already made the drivers for the first batch, so it couldn’t be included until the second batch or later. I’ve posted about it a bunch of times to let everyone know what exactly what was broken and when/how it was fixed.

So… it has been fixed for a long time. But I can’t magically update the firmware on lights which were produced with old versions, so people with old lights might still run into that issue.

The best I can do is send updated versions to every manufacturer who is willing to use it… which I did. That may or may not include Lumintop though. Last I heard, they rejected my updates and I haven’t had any communication with them at all since last year. None of their recent FW-series lights are using firmware which was intended for those products, so I’d advise caution there.

As for Anduril 2, it doesn’t even have a muggle mode. That got removed and replaced with something better, as described in this thread’s first post.

I’ve mentioned it every Anduril light I’ve used and get the same reply especially with Astrolux “They use an older version for some reason, the latest version is bug free” but this was never true, it was glitchy til the end. Unlike Tom I use and test Muggle mode. I’ve tested more Anduril lights than most.

I had one that steps down if you continually hold the button as a safety feature and that also has the glitchy muggle mode. I thought that was the final version. But I suppose it’s academic since has the ill-fated mode is set to be abandoned.

Sunset mode having brightness and time configuration is crucial. To get to turbo you have to be at max ceiling? that’s a no no. It’s all getting a bit vanilla. Call the new Muggle mode “Vanilla mode” lol.

Yeah, please fix it, I’m soooooooooooo sick of him noting it doesn’t work in every single one of his youtube videos :smiley:

TK would know better, but Hank with the Emisars and Noctigons keeps up to date with Anduril, probably the best of all vendors, plus the fact he sells the dongle to fit his lights for re-flashing.

Would be interesting if you have Emisars or Noctigons and have seen the problem or not. I know they are a bit pricier so not sure if realistic for resale in your biz.

True with outdated versions with Astrolux, Haikelite, and Lumintop - maybe others as well. Again TK has more info on the vendors/models support.

:smiley:

No… There have been 129 revisions since then.

Anyway, if you don’t believe the author of the code, feel free to check the code itself. Full history is in the repository, showing exactly what was changed and when.

The issue with muggle mode dropping directly to the floor level was fixed in May 2019, and the stuck-button safety ramp-down wasn’t added until four months later. So… I don’t believe that you saw those two traits in the same version. They did not exist at the same time.

There may have been an issue, but it wasn’t that issue.