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

Maybe, but it’d add UI complexity that I’m not sure is worthwhile. The ROM is also getting close to full, so I’ve been a bit picky about what I add. I’m hoping it can be decided by vote instead of using most of the remaining space for ramp blink options.

Other things that space could potentially be used for:

  • Make ramp memory optional? (always turn on at same brightness)
  • Add a sunrise / alarm clock mode?
  • Make muggle mode fancier? (simplified ramping or low/med/high or something)
  • Factory reset function?
  • Add another “mood” or blinky mode?
  • Optical programming mode? (configure the light from a web page, like a Lux-RC driver)
  • Leave room for enabling non-default compile-time options, like dual-switch support?
  • Leave room for other people’s mods?

If I give it weights of (1, 0.5, 0) instead of (1, 0, –1), things might look a bit different:

  • A: 6.0
  • B: 11.0
  • C: 16.5
  • D: 11.0

Or if those are expressed as a percent of total votes:

  • A: 31.6%
  • B: 57.9%
  • C: 86.8%
  • D: 57.9%

Perhaps it’d be best to use the percent, and set a threshold for what’s high enough. Like 50% or 66, maybe. The positive/negative weighting kinda implies a threshold of 50, but that might not be ideal.

Oh do not,

Just warn not to close the purchase group and stay out.
. -
. -

Edit: Do not be this what I want to say

Google translator error
. -

I would say only add those blinkies that are functional. You mentioned that the pause at B and C are too quick for anyone to respond to stop ramping from going beyond regulation (when ramping up). Therefore I would say it is not functional in the sense that you can actually do something with it, (although it does provide information, there isn’t something you can do about it in the moment. You would have to stop ramping up, and start ramping back down, and stop slightly lower than regulation). Whereas A and D give you a definite indicator - we’ve reached our destination, (programmed or otherwise) - you can now release the button.

You could just program a function that will set the light to the different regulations. It could be another mode, but I would rather have some of the fun functions you outlined above. I like:
“Add a sunrise / alarm clock mode?
Make muggle mode fancier? (simplified ramping or low/med/high or something)”

I vote for A and D

Can you place me on the list for 2 please.

in for 1, thanks

A and D.

And I would be happy with either B or C, I normally top off my cells pretty regularly, a blink at either B or C would tell me I have 8hrs or 1hour runtime, respectively.

Weird, off the wall suggestion, would a “max brightness at runtime X” work?

Ie, in a config mode, select runtime required (one click per…half hour? So 5 cicks is 2 1/2 hours), light blinks clicks back as a verification of required time and goes to the brightest output the cell can sustain for that amount of time. A full cell will obviously output more lumens than a 1/2 full cell, but both would run for the same 2 1/2 hours.

I assume uncalibrated voltage measurements from the driver would make this unworkable though.

I vote A and D, especially if auto reverse is implemented. The changes at the extremes are the most difficult to perceive, so I find it useful to know when to let go of the switch.

The mid blinks serve little purpose to me, as mentioned above the ramp rate is so high, it just tells you that you passed the point - like a mile marker that you can’t see until you pass it going 60.

Ramping Muggle Mode sounds great.

Another “mood” mode? Tell us more! I love Candle Mode in Andúril.

Optical programming would be amazing. I remember you talking about it a while ago, and I’ve seen your video demonstrating it.

Back in the 90s, I played around with a Timex Datalink watch that had a similar data transfer feature. It still seems very high-tech! :laughing:

Edit: since it stops on the lowest mode, and highest regulated mode, I see no need for any blinks.

Just ramp downward.

The ramp stops at the top and bottom. To turn around, let go of the button and then hold it again.

The top/bottom blinks were initially added as part of an auto-reversing UI, but I’m not sure they make any sense in a UI which stops on its own. It’s not generally hard to tell that it has stopped, especially at the bottom end. However, it can be difficult to gauge how far up the ramp the light is. I configure mine with a blink at channel boundaries only. This lets me know if I should expect more than 8 hours of runtime, between 1 and 8 hours, or less than 1 hour.

None of the options should be an issue for anyone with firmware flashing tools, but I hope to make the default agreeable to as many people as possible. So far, it sounds like that means option C only, a blink at the highest regulated level before the FET kicks in. That also happens to be where the ceiling is set by default, which would mean it has a blink at the top of the ramp unless the user changes the ceiling level.

Since there’s also a configurable stepped ramp which can be used to consistently reach precise levels, I’m leaning toward relatively few blinks. Set your preferred floor, ceiling, and number of steps, and it’ll give you a mode with evenly-spaced levels (plus turbo, if not already in the ramp). For example:

  • 3 steps from 20 to 130: 11 / 240 / 1100 lm (plus turbo)
  • 4 steps from 10 to 130: 3.3 / 84 / 394 / 1100 lm (plus turbo)
  • 5 steps from 3 to 150: 0.8 / 47 / 246 / 741 / 3000 lm

It can be whatever you like.

I would definitely prefer to have ramping automatically stop at the set boundaries.

Now this makes a lot more sense: Since floor and ceiling can be programmed precisely, and likewise for various precise steps, it eliminates the need for blinks, other than when ramping is set to go beyond regulation and into FET.

So C informs about potential high power draw. I guess that can be helpful for people who are in a situation where they want/need to preserve runtime

I would definitely prefer to have ramping automatically stop at the set boundaries.

Now this makes a lot more sense: Since floor and ceiling can be programmed precisely, and likewise for various precise steps, it eliminates the need for blinks, other than when ramping is set to go beyond regulation and into FET.

So C informs about potential high power draw. I guess that can be helpful for people who are in a situation where they want/need to preserve runtime.

How do the steps work? Does it pause at each step?

That would be tricky. The voltage measurements aren’t very precise, and it has no idea what kind of battery is being used or how its discharge curve is shaped. Could be a 2500mAh 18650 with a sharp elbow in the discharge curve, could be a 3400mAh 18650 with barely any elbow at all, could be a 700mAh 18350 cell with a spacer or short tube, could be 4x18650 in parallel, could be something which isn’t invented yet. I’ve been trying to avoid adding anything hardware-specific when possible since it’s intended to be portable across a wide range of drivers.

I’m currently using FSM-based UIs on the entire range of Emisar lights, the FW3A, the BLF Q8, and a lightsaber… and plan to add BLF GT support as soon as I have hardware. They’re all running Anduril, except for the lightsaber, which has a fancy rainbow synthesizer UI instead.

Last time I asked, there wasn’t much consensus on how muggle mode should work… so I went with the simplest option. That can change, if people want it to. Some options:

  • Dead simple style: On/off only, ~150 lm. <— current option
  • Traditional style: Low/med/high/off sequence, 10/80/300 lm.
  • Training wheels style: Simplified smooth ramp, 5 lm to 300 lm.

About another mood mode, I don’t have anything particular in mind. But if someone has a good idea, maybe it can happen.

I’m not sure if there’s enough space left for optical programming or not. It’s definitely the most work out of the things I mentioned, and I’d need to physically modify this FW3A prototype in order to do the development. Perhaps after the second prototype is made, I can turn the first one into a dedicated development host. For now though, I need it intact for thermal testing.

It works the same as the smooth ramp, except it only uses the configured steps, and each step is held for about 0.4 seconds. It’s similar to an Olight Baton interface, plus the ability to go down instead of only up. If the button is held, it will keep ramping until the user lets go or until it hits the end of the ramp.

BTW, I’m not clear on what your vote is now. It was AD, but now it sounds like maybe C or None?

I like option C also, as well as the dead simple muggle mode. I’m not going to complain however it works out though.

Nice! It will be manipulated according the user’s will! :+1:

I suppose that Crescendo is the case you mentioned. I’ve been using it (and like it a lot!!! Thanks TK!!) in a modded light but the auto-reversing is a bit “awkward” specially comparing witrh the Emisar D4 UI. It takes longer to get used to.

This said, I guess that sometimes it is harder to see when the top is reached, not the bottom. And that was the reason why I posted C and D as my options. The highest luminosity seems harder to control or to “eye-measure” than the lowest.

I still think that the blinks make sense to avoid pressing the button like there was no tomorrow and to mark some points while ramping.

This might be the only thing why I wold add the B mark, to know what to expect in terms of battery, as the highest regulation surely implies more drain than the 1st 7135 limit.

Still, so far I maintain my suggestion C and D.


Also, I have one question. Would the passage from full regulation to FET work as in the Emisar D4, meaning: after passinf that limit, and depending on the use LEDs that will be used, is it probable to see a “tint shift”? I have the D4 with XP-G2 S4 3D and I experience that “shift”. Don’t know how others react, and also don’t know it is supposed to expect that change on the new setting, after the regulation passage.

Please ignore my question if it is nonsense :innocent: And thanks again for the work done so far.

I want all blinks.
A
B
C
D

What I find interesting from the runtime table:
You gain 2h runtime if you go from 65 down to 62

Can we have the default level for power on set to level 62, please?

I dont think someone see a difference between 142 and 160 lumen and the 2h more seems to be a good trade-off.

Optical programming seems the most promising. But a lot of work and time.
I want that in a later premium edition of the FW3A with 90 CRI Nichia LEDs :slight_smile: not now

A sunrise mode, please no. I think it’s to hard to set with the lamp. And the µC cant sleep.

Leave room, it’s already feature packed.