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

I think you should err towards B as well. Whether it's the full-on "drop straight to regulated" or altering the ramp-down to be a lot more aggressive, it seems clear the "invisible" stepdown just doesn't work. It wouldn't on the D4 either. About how long will it run on turbo before stepdown?

I definitely think the quicker step down should be standard. If there is enough memory, maybe an option can be added to turn it off in programming.

If not too late, please put me in the list for one (1).
Thanks

Option A.

I'm in for one thanks.

Please add me to the list for one!

Respectfully

You are number No. #728 on: Interest List , Post # 4 , ” Page 1 , “:FW3A, a TLF/BLF EDC flashlight - SST-20 available, coupon codes public - #4 by FW3A_Team

See:

For a total of 1 lights .
How many Flashlight do you want in total? … x … units? .

I would prefer option B (with a fast but smooth step-down over the course of a few seconds).

I don't like lights that can become too hot to hold (and I don't want to have to worry about the light). Also if the light becomes too hot (with option A) it could potentially cause the thermal regulation to overshoot (which is of course undesirable).

BTW: have options to lower the sensor lag been discussed? For example these silicone rubber things could improve things a bit.

Pepinfaxera, sometimes people forget they already joined the list. If they ask for one light multiple times, they are still asking for just one light. :wink:

:+1:
But, you must ask them

Coffee without coffee?
Powerful flashlight without power?
.
*That’s a lot of 3000 lumen? Make it 2500 lumen.
.
5 or 10 second turbo? I don’t accept it.
If that’s what it is, I don’t buy.*
.
I have two, D4 Emisar, with Nichia 219CT 83CRI, 5000K and XP-L hi,
Nicha gets very hot.
XP-L hi also heats up, but less so.
Step Down works
and the leds don’t burn out.

My bad.!

Just one light please!

D4 managed to have a generic algorithm. Is FW3A hardware harder to regulate?

On which side of the driver is the MCU? Does if face battery of shelf?
Maybe it would be possible to shorten the thermal path by installing a silicone cube or adding a blob of thermal glue in the factory?

There’s really not room for a thermal cube. A blob of thermal glue between the MCPCB shelf and MCU might work, but then it makes the light significantly less mod-friendly.

The D4’s regulation algorithm worked, but its initial peak was too hot and it had a tendency to overshoot, oscillate, and jump around. It has a reputation as a firestarter or a “nut roaster”. The FW3A improves on those things, but the initial peak is still too hot. So I’m pondering whether to make it initially act more like a turbo step-down before handing control back to the usual regulation algorithm.

In either case, the user can still force it to stay at turbo by setting the ceiling to max, ramping up to it, and holding the button down. Or they can change the thermal config values to make it run hotter, which will extend the turbo time.

My intention is to leave ceiling at 1100 lm (or even lower it some) so I don’t really have a preference about thermal regulation at higher levels.

I’ll sign up for one more light, making it a total of two (2) to my name.

Need one as backup/giveaway

I would prefer option B. I always prefer one or two hard drops vs a slow dimming.

TK, could it be that your thermal control works better at the lower levels because a lot of the heat is being generated in the 7135s rather than the LED. The 7135s being closely thermally coupled to the MCU and its internal temperature sensor. I suspect you are mostly controlling the temperature of the driver, not the LEDs.

ISTM there are two cases here:

A: Power (manageable) burned off in the 7135s, controllable. Driver temperature is a reasonable indication of overall head temperature.

B: FET in use, power (lots) burned off in the LEDs, no good thermal path to MCU, long time constants, driver runs relatively cool since most current passes straight through the FET.

Without having a temperature sensor on the LED MCPCB itself, I suspect trying to control it in B: is a difficult exercise. So a timed step-down bringing the 7135s back into use seems the most practical way forward.

Otherwise I think you would need two different control algorithms, but then it gets even more complicated as cell voltage drops, and in the transition region between 7135 only, and full FET.

TBH getting rid of the FET could make things much easier. A straight linear driver is the way to go in future IMO.

I’m all for thermal regulation B.

Reason: I have a D4 that I like to pocket-EDC but the lock-out requirement (manual or via software) makes a stiff tail-clicky EDC much more convenient. I really tried: my S2±shorty switches itself on spontaneously in my pants pocket about once a month (starts at low), the D4 does that at least twice a day, and in one occasion I found it (actually my nuts found it) on turbo.

The FW3A has the e-switch at the tail and that should help a bit but I expect not much.

So with some mapping using perhaps two different emitters you could make the stepdown start at the very first detection of rising temperature. Perhaps even use the first half second after first detection to detect the rising speed as recorded by the MCU, correlate that to what the actual temperature course is of the flashlight head and calculate an appropriate stepdown response. This could also work to get the correct stepdown when not fully ramped (but over sustainable current).

But your current temperature control algorithm may already work at this level?

My first reaction is to say to either use the universal method, or to use a significantly more aggressive regulation behavior when the fet is active but NOT go as far as to force a fast stepdown like with option B. Mostly it’s just uncomfortable to the user rather than actually harmful when the body rises above the setpoint momentarily; actual burns are from having things in front of the beam.

I’d say use normal behavior up to max 7135, then in FET use a more proactive mode. (Would a trend projecting part work here?) If there isn’t a set of parameters that can make the regulation work right at fet mode (a set which would have been too jumpy at lower modes) then maybe loosen up the constraints a little. Let it get a bit hotter than normal while it quickly regulates down to somewhere between turbo and the 7135 mode (it will be visibly changing, but that’s not nearly as bad as a fast forced stepdown). I should try some of this myself, of course. Hmm…