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

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…

In for 2

Also would prefer option B

Unless there’s only a handful of bytes left, maybe this could be a config option; it does seem like people could have good reasons to go both ways.

You know, there is a body of evidence that argues otherwise. :wink:

The loudness war, decreased complexity of chords & melodies, fewer instruments, less diversity in lyrics, increased use of sampling, the growth of assembly line song writing (ie ‘track & hook’).

Does this body of evidence also have a source other than your subjective perception of today’s music? Would be interesting to read up. :+1:

Then there is the Auto-Tune.

Bland insipid pap from “celebrities” who wouldn’t know how to compose a lyric or a tune worth anything. Or sing in tune.

Nor write poetry, or inspire anyone to lead a better life.

Never mind have any musicianship, or know how to play any instrument. Leave that to the session musos who are great, but getting older.

You don’t know what you (had) until it’s gone.

Streaming has been the death of music, I’ll stick to my vinyl and CDs curmudgeonly.

Silicone cube doesn’t have to be 1 cm thick. A piece of silicone thermal pad of whatever thickness might help.
A silicone-based thermal glue shouldn’t impair mod friendliness significantly.

I can remember a time when audiophiles were bemoaning that CDs were the death of music.

Option B sounds good. 1100lm after Stepdown is still awesome.

The one thing I don’t want to happen with the thermal stepdown is to have it just keeping ramping down indefinitely.

My D4 copper starts out great on turbo. But within a minute thermal rampdown has dropped the output to maybe 50 lumens. That’s WAAAAY too low. It should stop ramping down well before that point. Maybe at 500 lumens.

This is one of the things I like about my Eagtac DX3B… it stops ramping down at 70% no matter what the temperature sensor sees.

For Anduril, maybe have a user configurable floor on the rampdown?

That’s when the rot started, with digitisation. Philips didn’t realise what a monster they had made, or how easy it would soon become to rip the stream or just copy the things. Then Fraunhofer came up with codecs, such as mp3. Winamp, Shoutcast followed.

The rest is history

I still think my MiniDisc sounds very sweet, ATRAC encoded.

Now, an analogue master tape, straight to vinyl with some sympathetic balancing through a Neve desk = heaven. Through my Garrard 401, SME tonearm, homebrew pre-amp, QuadII valve amps and a huge pair of KEF transmission line monitors. Have to wait until the neighbours are out at work before turning it up though.

A bit different from some Spotify through a cruddy bluetooth speaker.

I honestly thought you wrote: meltdown ..

Brings me to the next question: how hard is it to add a meltdown mode to the FW3A?


An option against to much heat can be different ceilings for SMOOTH RAMP and STEPPED RAMP. For your preferred ramp lower the ceiling, with 3 clicks you can switch to the other ramp where you can have full power if you need it.

Several things to explore (perhaps they already have been):

  • Improve the thermal path as best as possible (thermal glue or what not)
  • When it is turned onto turbo, increase the scan rate and/or turn up the derivative (D) of the thermal regulation PID to help with lag and make futurecasting more aggressive.
    -Switch modes/tuning when the button is pushed.
  • Have a straight-up timed step down, but do it in small increments to appear as a ramp down to a certain level where the PID loop would take over.
  • Add a true sensor (are there open pins/space for that?)
  • Others I haven’t thought of.

I have no idea how much coding space there is/isn’t.

I’m in for one thanks

Yes, that is a significant portion of the difficulty here. The 7135 chips eat the extra voltage and produce heat at the driver, which allows the MCU to sense the heat much more quickly… while the FET burns it all off at the emitter, where the MCU can’t feel it as much.

However, the 7135 chips are still active at 100% in all FET modes except for level 150/150, full turbo. This hybrid method helps spread the tint shift over a wider span of levels, and reduces visibility of PWM.

What I have now already uses two slightly different algorithms depending on whether the FET is active. When the FET is engaged, the algorithm does thermal adjustments 4X faster. And the adjustments run at 8 different speeds depending on how far above or below the target temperature it is, which also increases the drop-down speed. So it changes at anywhere from 31 steps per second to 1 step every 8 seconds, depending. There are 512 total steps in the adjustment range.

Instead of simply adjusting 4X faster, but still doing it proportional to the measured amount of excess, I’m wondering if I should just make it drop directly to the highest non-FET level as soon as it detects any overheating at all. This could still be smooth, executed over a period of 4 or 8 seconds, but it would not even try to regulate between ~1100lm and full power, because 1100lm isn’t sustainable unless the light is in a very cold environment.

Yeah, it says a lot that people who have a D4 have been suggesting option B.

Physical lockout isn’t as feasible on the FW3A, but soft lockout is a lot easier to access. Using 4 clicks instead of 6 may not sound like much, but it helps. And the lock/unlock blinks are like 50X faster. So, locking or unlocking takes about 1 second instead of 3+.

Plus, it works as a momentary mode at the current ramp floor. So, it doesn’t even need to be unlocked for quick tasks.

Yes, it already tracks rate of change and calculates predictions of what the temperature should be in the near future. It then adds together several predictions over time so the response will also be proportional to how long it has been too hot or too cold. And the response is proportional to the sum of the predictions. If I understand correctly, this makes it a PID algorithm. Response is [p]roportional to an [i]ntegration of [d]erivatives.

Problem is, as far as I can tell… the MCU doesn’t feel the heat fast enough to correctly steer into the turn, so it slams against the wall before sufficiently correcting. So I might make it steer as hard as possible as soon as it senses a turn coming, so it won’t hit the wall on the first turn. After that though, it seems fine.

That’s fixed already. The D4’s thermal floor was too low. This is adjustable at compile-time, but the current thermal floor for FW3A is the 1x7135 level, or about 160 lm. I find that, while hand-held, it can sustain about 700 or 800 lm, or while tail-standing in a room at 70 F / 21 C it can sustain maybe 300. This 160 lm floor gives it a bit of extra adjustment room, but is still quite a bit brighter than the D4’s floor.

Additionally, the updated algorithm is less prone to overshooting and oscillating, so it’s less likely to hit the floor. And if a more direct turbo step-down is implemented, that makes it even less likely to hit the floor since it won’t have as much heat to shed while regulating.

Things are a bit different in muggle mode. In that case, it drops to about 10 lm when hot. No regulation is attempted. The goal there isn’t to maintain the highest possible output level, but to make sure a 3-year-old won’t start a fire.

Already implemented. It’s just intentionally difficult to do. The user would either have to hold the button in momentary mode at turbo (ouch), or configure the thermal parameters to have the highest possible ceiling and lowest possible sensor calibration (stick the light in a freezer and tell it it’s like 50 C).

But … don’t.

Exactly. The user can have full power in one ramp and a lower ceiling in the other.

By default, both ramps only go up to ~1100 lm. And one starts at moon, while the other starts at ~10 lm. But those are easy to change.

Not sure if thermal glue is going to be feasible or not, or how helpful it would be. I tried a sheet of thermal transfer material at one point, but it didn’t seem to help a lot. I think the attiny gets most of its heat through the legs, not through the surface of the chip. And I’m very reluctant to slather glue all over it.

When the FET is active, it already increases adjustment speed by 4X or more.

The step-down, if implemented, isn’t timed. It’s still temperature-based, but would have a big response and would be easy to activate. A hair trigger, so to speak. Step-down would probably go smoothly over a period of 4 or 8 seconds. Afterward, the regular PID method would take over.

A true MCPCB-mounted sensor would be nice, but is probably not feasible on this light.