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)?
I like option 2. The one switch to control the throw and flood and another one turn on and brightness of light. With one switch you can have for example 1C to switch between some fixed modes throw/flood, 2C only throw and 1H flood beam. With second switch to control all another modes of Anduril but TK must implement that dual switch support in firmware.
This. Familiar adruil 2 for each.
I think you’re on the right track. This looks like an awesome light. SST20’s behind TIR’s is a great idea. A lot of other lights do this successfully like FireFlies. I would like to see the SST20 FA3 behind those TIR’s. They are great for tint and okay for output, but for more output use the 6500K version. The SFT40 is a great choice for the throw emitter. Way better than XP-L HI, XHP35.2 or XHP50.2. The only other emitter I’d recommend is a 6 volt emitter (SST70), but wouldr
Definitely try to put in a current regulated driver (buck driver) if you can. I think we all agree that consistent, fully regulated output is preferable over ultra turbo mode and only 5-10 seconds of 15,000 Lumens. How about a few minutes of 5000-6000 Lumens? It’s definitely feasible. You could still have a turbo mode for that, of course.
I also like the idea of 2 buttons for throw/flood. I reviewed a multi-emitter headlamp with dual switches for the throw/flood LEDs, and it worked perfectly. I like Anduril, but it can be a little complicated for some users to manage at first. If you could make the throw/flood ramping work, that would be a great single-button solution, but for now I think the 2-button design is preferable.
Maybe it’s crazy, but I’d go for double ended flashlight if you do want to combine flood and throw.
Current setup is likely to be only “some” throwy, because of the limited reflector size.
Having a regular size reflector on one end and floody TIR (or mule Leds) on the other would work far better (imho) than having both combined on one end.
See the UI above.
I still want to see how ToyKeeper to implement Anduril UI in TS32, but the progress is a little slow, so let’s hope we will have TS32 Anduril version in future.
In that case we may not be able to push full power of both at the same time, not sure I am correct.
This part is great, but not sure how it sound to TK, FYI, TK has very limited time to work, so huge change may take even longer time. We don’t want you to wait a long time, that is why we launch plan B, dual switch.