[Design with Terry]Wurkkos TS32 15000+ Lumens Flashlight Concept

I like that idea of three steps (all throw, half-and-half, and all flood). It will still allow the use of both channels at the same time without taking too long to ramp between like it does on BLF LT1.

A few suggestions to make the light really high quality:

Regulated constant current driver.
Battery charge cut off around 4.14V. There are so many lights that needlesly push the batteries above 4.20V. The gain is minimal and the battery life is deminished.
Low Voltage Protection around 3V. The same as above + I have it when a light will keep going forever on 1lm, draining the last remnants of the battery. Let it turn off once it cannot sustain Low mode.

How many Amps will the Power bank function be able to give? With phones that support PD being the norm now, a PD supporting power bank at higher than 5V would be fantastic. Is there such a control chip that can be incorporated in the driver? It would make light realyl stand out, as there are a few lights now that have Power Bank fucntionality but none that I know that can do more than 5V, 2A.

Agree with you, ramp from the middle seems better.

For the center led, how about using the new XHP-50 “Hi” version (XHP-50.3), is like the SFT you are currently planning to use but brighter.

It’ll require a boost driver. The HI won’t come in 3V and surface brightness will not come close to the SFT without one bad-a$$ driver

Yes, new products will apply the design of TS30.

Oh, er, another possible method to control it, without making it slow, is to just make the tint ramp faster. It currently does 255 steps at 62 Hz, so it takes about 4 seconds. But it could skip several steps per frame and ramp in like 1 second instead. It’d just be harder to precisely pick blends in the middle.

TK, would it be possible to skip several steps per frame towards the edges of the ramp, fewer as it gets towards the middle and not skip any steps in the middle?

I like that idea. Tint ramping takes a little too long for me on the LT1. A 1 or 2 second channel ramp on this light would not be too bad. Would it be possible to allow the user to choose between a smooth ramp and instant switching?

What about stepped channel ramping? We have discussed previously but think it is possible. It should inherit the main ramp (stepped or smooth) for channel ramping and inherit the number of steps if stepped ramping.

If the user happens to be at a low brightness where the number of steps they have selected is not possible, just lower the number of steps in the channel ramp. That’s basically what it already does right? It starts out with a ton of steps at the top of the brightness range and then lowers down to three steps at the bottom of the brightness range, right?

This is kind of what I was implying with this comment: [Design with Terry]Wurkkos TS32 15000+ Lumens Flashlight Concept - #54 by dave1010

If you’re happy with more complexity in the code base then this is a way to please everyone. Attempting to please everyone with lots of options isn’t always the best strategy in the long run though!

The tint uses an abstract value from 0 to 255. When the user ramps the tint, it changes this value.

While setting the brightness, the tint value goes into a formula to convert it to a hardware control value. For example, if the tint is 100/255, and the brightness is 10, the hardware values are then 4 and 6.

  • cool = ((brightness * tint) + 127) / 255
  • warm = brightness - cool

Or with numbers…

  • cool = ((10 * 100) / 127) / 255 = 4
  • warm = 10 - 4 = 6

Since the hardware control values are all integers, the number of different tints possible increases with brightness. At a value of 2 brightness, the only possible values are 2:0, 1:1, and 0:2. With 3 brightness, it can be 3:0, 2:1, 1:2, or 3:0. And so on.

This is pretty simple so far, but in practice it gets more complicated. On PWM-based lights like the LT1, the hardware response is not linear… so it also has to add in a correction factor based on the current tint and brightness. The brightness dips at middle tints, as shown by the orange line here, and after adding a correction factor, it follows the blue line:

The correction function is a simple triangle wave which peaks in the middle, and gets added to the overall brightness values. So instead of having the hardware controls follow a straight line, they end up following a different shape of curve…

And there is likely to be an additional complication beyond that, on newer lights. I recently added a dynamic PWM thing to improve the resolution and ramp shape in low modes. This makes it so the hardware control values follow a more complex pattern. For example, here’s how the controls look on the KR4:

So if there was a tint-ramping light which also used high-precision dynamic PWM, the tint resolution would still be low at the bottom, but it would then increase quickly, turn around and become somewhat coarse again in the middle of the ramp, and then increase quickly again. The number of tints follows the orange line in that picture.

I did a test for this on my K9.3 prototype, and it works pretty well… but the code to implement it is pretty complex.

So… the tint ramping UI code really has no idea how many tint steps there will be. It’s a pretty complex calculation. Instead of trying to guess, the UI code just moves the abstract 0-to-255 “tint” value back and forth and lets the underlying hardware code interpret that however it needs to.

Currently, it moves that by 1 per frame, and the frames happen at 62 Hz because of hardware reasons. But it could move by 2 per frame, or 3, or 4, to speed things up… or it could move by 1 every 2 frames, or every 3 frames, etc, to slow things down. For a tint-ramp light, it’s nice to have high-precision control. But for a flood-throw-ramp light, speed seems more important than precision.

Another option is… depending on how the hardware works, it could just go to maximum throw mode (or perhaps maximum flood mode) at the top of the ramp, regardless of the current tint value. Like, on the K9.3 I tested with, there is a DD FET channel but it only powers one set of LEDs. So at the top of the ramp, that goes to full power no matter what the tint is. Tint ramping only works when the DD FET is off, using the two regulated power channels.

If that style is used, people could go to full throw mode and back just by activating turbo.

But I don’t know yet how this specific light will work. I’m just tossing up options for now, to see what sticks. I’m hoping for something simple though, because as dave1010 said, adding complexity to cover every possible preference is usually not a great solution.

Comment your thoughts below on TS32 dual switch version.

A dual switch interface would make me far less interested. If it comes with a single button and Anduril 2, that is an interface I already know. I can customize it to work exactly how I want and there is no learning curve. With a dual-switch interface I would have to learn how it works and it would be different than most of my other flashlights.

Is the dual switches, for independent control over throw, and flood? Like it's completely two flashlights, just sharing battery?

Why not 12 SFT40 + 1 SBT90.2?

Dual switch interface might be good. I like the idea of keeping things simple®. Being able to separately control leds will most likely be simpler and less bug prone than trying to control everything with single button. I must admit that I have only few times found use to Anduril special modes. So not a big loss for me.

I once suggested Wurkkos to introduce a dual switch design, e.g. for the (non-existing) WK30S model. Here's a possible UI draft of mine for a multi-channel light with different emitters and "channel-ramping" or tint-ramping as mentioned here. For illustrational purposes, switch symbol design is adopted from Fenix. Of course, this very UI here would require proper changes to fit to TS32.

@Lux-Perpetua - I don't see how that design could be better, than just dedicating one button to operate one type of LED, if we just have 2 of them (one for 12 x SST20 and one for 1 x SFT40).


FC40 is great LED but is more like floodier compared to XHP35. Also please don’t use LED with different color temperatures. I like to see 4000K or 5000K version. Also mix of throw and flood is very usefool if you want to use that light on the bike like me. Mix with SST40 with LH351D I think will be good idea because SFT40 exist only in 6500K version.

What would the UI be like?

Would 1 switch control the flood LEDs and 1 control the throw (each with a normal UI, like FC11). So you could have 1 low and 1 high for example. This would give more control but would mean you have to use 2 switches to get to full brightness.

Or would 1 switch control brightness and the other switch control which LEDs are on (click to cycle between flood, throw or both)?