My vote is instant switching. I see the appeal of being able to ramp between them but I think the slow ramp would be annoying and instant switching would be better.
I think the best solution is to include a flat top cell adapter like Convoy does with the 4X18A and 3X21A.
Thanks Dave for the great suggestions, hopefully it will go well with support from you guys.
I’m impressed Terry. The first pass design is pretty well executed IMO. I really think the SST20 and SFT40 combo is the right one. Arguments could be made for LH351D, most notably the availability of 5700K 90CRI to better match the SFT, but the 3535 footprint allows this to be an option later.
Only idea I’m going to throw out there is a dual switch UI. One for throw, one for flood. Both with the same FC11 or Anduril UI. Already have two output channels, why not have two input channels? Curious what others think here. I can see it both ways.
That is really helpful, and we can also supply button top 21700, then we don’t have any issue with the battery.
Thanks Toykeeper for pointing out this potential issue, and tactical_grizzly for solution to solve.
Hi all, thanks for your constructive post/suggestion, now I am chating with Toykeeper about the throw/flood ramping, maybe not smooth from throw to flood, but ThrowOnly—-FloodOnly—-Throw&Flood(3 emit styles) similar to tint ramp of LT1 Lantern, once emit style is selected, you can ramp from 1% output to 100%(this part is still unknown, should be workable, but still need confirm from ToyKeeper), feel free to comment how you think about this.
Please join us, comment, speak out your idea, and let’s make another great light to this community.
Hereby, I would like to thank Toykeeper a lot, words can not express well.
please be sure to have a high bevel, between the threads and the o’ring, as in TS30s
On DL70, one o’ring is protected by bevel, but the second o’ring is right next to threads…
You can thing about double o’ring for this flashlight, as in DL70, but it’s not necessary
Seems like 2 switches, one for flood, one for throw, both with their own Andruil, might meet the needs of many customers.
In the FD65, the switches are for starting at low or high from off, and after on, and a short press of either ramps one mode lower or higher. Instead, one switch for flood, one switch for throw.
I’d really prefer an aspheric, or very tight TIR for the center LED, like the Olight marauder 2.
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.