FW3A, a TLF/BLF EDC flashlight - SST-20 available, coupon codes public

TK, isn’t it fun explaining the same thing over and over again? A simple look at the diagram explains the answers to all the questions.

The step-down from heat can also be adjusted through thermal regulation, so it’s not NECESSARILY 15 seconds of blast time. You’ll want to let go of it soon after that, probably, but if it’s a cold night and you have gloves on then it’s potentially a run-it-til-the-cell-dies scenario.

Edit: From post number 3… the UI diagram… set it up virtually however you wish. :wink:

Wow what a lousy (dick) comment about the original design, $5.00 E-Bay light? I’m so glad it now meets your approval your highness :person_facepalming:

There was nothing wrong with the original design, alot of us signed up for it just the way it was, and still like it that way!

a/ I signed up for the original version but
b/ I think the current version is even better but
c/ not everybody thinks that way but
d/ everybody is entitled to have his/her own opinion because
e/ there is no accounting over taste (which has helped evolution a lot) but
f/ the correct way to communicate that is to say that you see it different and not that the other person is a !@#$% blind sod.

DB Custom,
no, it doesn’t. Even with the text

e.g. I don’t know if the FW3A resets the memorized level to max7135 when you repower it.

And the blinks in the smooth ramp? I think there was a poll they should be in.

And some things are better explained in #2963 than in #3.

@Toykeeper

To enter ramp config it is 4 clicks
(from OFF you lock out with 4 clicks)
other configs are 3 clicks
What about: click, click, click, hold for all configs?
So it would be uniform and no problems when sb. wants the lamp to lock out while it is ON.
(So 4 clicks from ON would have no function)
And config would be a bit more hidden.

To late to join in? Man I want one!!

Interest list updated.


- TK

Please add 1 more for me (total of 4)

Thanks

Please add me for 1 of these, thanks :+1:

Well Joe, I reckon having the light in hand and running through the UI makes the chart make a lot more sense. I’ve been using Anduril in several different lights for a while now and it all works beautifully. A lot of us here have been flashing Anduril in our builds, so too much change now is sort of bad to the greater good. Not that we can’t re-flash the drivers we’ve built, but at some point it has to be good where it is and let TK rest.

Think about that.

What happened to MattAus when we used him too harshly, designing our drivers? He disappeared. What happened to Wright, also designing our drivers? Gone. Comfychair? Mr. Hawk? ChicagoX? We mean well I know, but when we have someone that knows how doesn’t mean we have to use them til they burn out. Change this, change that, re-design this, can you do that? Hell if we were paying her she’d quit!

Well it was a suggestion, adressing that people in NarsilM end up too easy in config.
And the command would be the same.
If she thinks it’s worthy she may implement it, if it is a brain fart then not.

The config is intentionally easy to access. I also used small mode-specific config menus instead of a monolithic master config mode, to make it easier to use. I always have to refer to the manual to remember what Narsil’s config options are, but I hope to avoid that need in Anduril.

In general, I tried to map inputs so the more common an action is, the fewer button presses it takes. For example, beacon mode. One click is “off”. Two clicks is “next mode”. So it takes three clicks to access beacon config. Then there is only one setting, the number of seconds per flash. Click twice for a two-second beacon (flash once every two seconds), click five times for a five-second beacon, etc. It could be harder to access, but there wouldn’t be much point.

In regular output modes, one click does the most common operation — turning on and off. A hold does the second-most-common operation, changing brightness (and if brightness is “off”, it changes from there by starting at moon). Two clicks for turbo. And throughout the entire UI, click-release-hold does the opposite of a hold… regardless of what hold is mapped to. So all one-press and two-press operations are used. That leaves three and higher for less common operations. Three clicks while on switches between ramp profiles, giving easy access to both without having to enter a config mode. Then to actually configure a ramp, four clicks. It’s not hard to access, but it’s also not hard to remember what the settings are… floor, ceiling, and maybe number of steps. This theme repeats in thermal config mode too — low and high in that order. If entered by accident, the menus are not hard to skip, since with only 1-3 options in each menu it only takes a few seconds to wait through the whole thing.

I could see maybe changing the beacon and temperature config modes so they’re on four clicks, for consistency. Then we’d have a global “three clicks for a special action, four clicks for a menu” theme. I wouldn’t want to make them unnecessarily hard to access though.

There aren’t many three-click “special actions” though.

  • Ramp: Change ramp style/profile.
  • Lockout: Change button brightness, if there is a lighted button.
  • Candle: Add 30 minutes to the timer. (not yet implemented)
  • Sunset: Add 30 minutes to the timer? (not implemented, currently hardcoded to 1 hour)

Also not many config menus:

  • Ramp. (one menu per ramp)
  • Beacon timing.
  • Thermal settings.

There was also a plan to make “factory reset” easy to access, but it doesn’t work on the FW3A due to the button being on the tail instead of the head. The factory reset on my other devices is mapped to “disconnect power, hold button, connect power, continue holding for 3 seconds”. On my lightsaber, for example, this function is called “self destruct”. It animates an increasingly bright red warning before the reset, then explodes into a fading blue-and-white pattern when the reset has finished. The user can let go during the red phase to abort.

Okay, I haven’t been keeping up with this thread. I honestly just came back to take a second look at it since MascaratumB is having a GAW for one of these and I wanted to see how things are going here. I like the new look of the prototype with the sloped/ramped side on the battery tube versus having ledges on both ends of the tube and smooth/flat in the middle. Then I looked at the FAQ’s and I have a couple questions now.

Why is this? The design I saw in the OP looks like it could be cut down to fit a shorter cell. Why couldn’t it just be shortened? I’m confused by this.

If you don’t want to do a host, that’s fine. But, this reason for NOT doing it looks more like a reason FOR doing it. Unless you’re saying that each light is literally a one-off because of how they have to be machined, and there’s no way to make a large-scale batch of these hosts (or it would be cost-prohibitive to do so). In that case, how is this GB even happening?

As I said, I haven’t kept up here. So, if these things have been addressed, please just point me to those discussions and I’ll look myself. No need to re-hash.

The back half of the light is, on the first prototypes at least, basically one piece. Usually a shorty tube only needs one extra piece to be made and swapped… but in this case it would need a new inner tube, new outer tube, new clip, and probably all the tail parts too because they don’t really come apart.

By “custom”, it means “not standard” or “not easily replaced by common parts”. For this light, an empty host would be the same thing as a full light, but without the MCPCB and LEDs. I think a Noctigon would probably fit, but I haven’t checked to make sure. The driver isn’t easily replaceable though, since it’s not a standard size or shape or layout. The tail bits are also not standard, and nothing legos with other lights as far as I can tell.

Also, I don’t think Lumintop does host versions. It’s hard to get them to even offer replacement parts.

The driver is at least reflashable though, and there are several compatible UIs available. It’s just a weird layout, to accommodate the tail e-switch.

Thanks for answering TK! I understand now. In the (original?) drawing that’s in the OP, the tail is separate from the tube(s). As for the “custom” host, I guess it does make more sense to just buy a whole light and make the small modifications that might be possible.

Way off topic, but do you have any videos of your lightsaber? It sounds amazing.

Hmm. I don’t have any Olight flashlights yet. I think a click for on/off and hold to change brightness might be good.
(my second choice for muggle mode would be the ramping but with less max lumens)

Since it looks like “smooth ramp” is going to remain the clear winner of the muggle mode poll, I went ahead and implemented it. I also made it save this state to eeprom so it’ll persist across battery changes. Six clicks to enter, six clicks to exit. And since it only uses about half the ramp, I made it ramp half as fast.

It took a bunch of extra room though, so I refactored all the config mode code to be smaller… and ended up close to the same size as before the muggle mode changes.

Oh, and I changed button mappings so all config menus are on four clicks… even if there is no action on three clicks. Consistency is probably more important than density.

Not yet. It has been too cold, and I still need to finish a few parts of the code. And probably redesign the driver. Here’s a preview of its UI though:

Color patterns are configured in a manner similar to designing a sound on a synthesizer. This lets each person make their lightsaber unique. It also lets people see in real time what it will look like, so they can basically tweak knobs until it looks good.

Thank you for the 4 clicks to go to config Toykeeper!

And also thanks for the detailed explanations!