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

Please add me to the interest list please.

Please add me to the list.

Updated list : … Post moved to Page 130 , FW3A, a TLF/BLF EDC flashlight - SST-20 available, coupon codes public - #3870 by pepinfaxera

Short list, Last requests .
.
.
.

any word on further prototyping/progress now that the GT is out?

I posted about progress five comments ago. Working on thermal regulation upgrades.

I trust your work with the drivers sight unseen,lol. More interested in the hardware!

Neal asked us to for feedback on the prototype. So we’ll compile a list of issues and things we’d like to be changed soon.

interested

I get the feeling that this could likely be solved even more elegantly. I do control engineering for a living, so when I get the time I might take a look at this.

This thermal regulation is, in my opinion, the greatest advancement in flashlight tech since the XML was released way back when. When the temps are cold this time of year, the light is smart enough to know it doesn’t have to ramp down as much, if at all.

Thanks for your efforts in perfecting this.

Because the design has chanced any change that it will be made of a straight / thicker tube for more thermal mass (and so a better temp regulation and a longer higher output)?

Please add me to the list. Thanks!!
Robert

Just want to throw in my hopes for Nichia, and also a smooth finish. I will obviously be very happy with whatever the team thinks is best in the end though. I do not think the bead blast or the taper looks bad. In fact like others I enjoy both designs :slight_smile: Was originally just expecting a different look with the way it is described on page 1. Really love the original look like it was fresh off the lathe. Looking forward to this the most out of the last few BLF projects I have participated in! Think this is going to be an amazing edc light. Hope everyone had a great time during the holidays as well.

This sounds like you are developing a PID loop. I think, if I am reading right, you have the P & I, essentially leaving D as zero.

Is there going to be a team account takeover of the top post like the GT thread? There probably should be based on The Millers hiatus.

Actually, accounting for the future is more like D action. Trying harder when it doesn’t work is integral action. We should do a bit of system identification on the driver and set a properly tuned PID controller and I bet things would work beautifully.

Maybe, but the GT team is swamped right now. The GT group buy is closing so there is tons of stuff going on.

Who knows, maybe The Miller will take over this FW3A GB again. :+1:

What I have now is more of a “PD” sort of system, with a small “I” component used mostly to reduce the effects of noise in the measurements. I tried making the “I” stronger but the results weren’t very good.

Specifically, it measures 4X per second, averages the past few values, and builds a temperature history using the averaged values. From this, it projects trends forward a few seconds to guess where it’ll be in the future. This is the “D” term. It keeps a few seconds worth of projected values, and takes the average, which is where the “I” term comes in. If the average projected value is above the ceiling, it sends an overheating signal to the UI code with the over-threshold magnitude (the “P” term) as a parameter. If the projected value is below the floor, it sends an underheating signal to the UI code (with the under-threshold magnitude as a parameter). Signals are rate-limited to avoid warning too often.

From there, the UI code decides what to do with it. In Anduril, it sets a new target ramp level based on the current level plus or minus the reported magnitude, with some bounds checking to keep things from going too high or too low. Then, on each clock tick, if the current level is different from the target level, it adjusts by the smallest step possible. Time between adjustments depends on how far it needs to go, so it could be anywhere from 0.016 s to 2.0 s per step. This interval is recalculated at each step so it decelerates as it approaches its destination.

In my testing, I’ve found it’s a bit tricky to hit the right balance between adjusting too fast (overshooting, oscillating) and adjusting too slow (overheating enough to hurt someone or cause damage). So most of what I’ve been doing is trying to make it reliably hit the Goldilocks area between.

Quite right.

Please add me for a second