Using ToyKeepers “Spagetti Monster” base code I designed and tested probably ALL kind off UIs. Best and most intuitive e-swich UIs is simple UIs like “Baton” but with more modes and the very best is saw-saw or swing UI .
Could you summarise please to save me trawling through olights website?
The Baton UI, basically:
- Single click on/off, with memory.
- While on, hold to ramp up in steps. After high, it goes back to low and repeats. (upward sawtooth pattern)
- Hold from off for moon, otherwise hidden.
- Double click for turbo.
- 3+1 steps. (low/med/high + moon) Also turbo might be above high? I forget.
It looks like Quadrupel’s swing UI is the same, but with a few changes:
- 5+2 steps instead of 3+1. (the bottom 2 levels are semi-hidden instead of just the bottom 1)
- It looks like 2H is added to ramp down, and can reach the bottom 2 levels.
- Instead of looping a low-to-high sequence, it ramps back down after hitting the top. Triangle wave pattern (a.k.a. zig-zag) instead of sawtooth pattern.
Anduril in stepped mode with 7 steps is very similar to the swing UI, but:
- The bottom 2 levels aren’t hidden.
- The up/down zig-zag pattern goes up, down, stays down, then goes into lockout mode. It’s meant as a protection against accidental stuck buttons, not as a part of the UI people should use on purpose.
- A hold immediately after another hold goes the opposite direction (a.k.a. auto-reverse).
- Has a lot of other features and options.
2 Thanks
Damn, I regret being lazy now, thanks so much for the summaries!
ToyKeeper, Thank You for your attention. One of the reasons why “Swing UI” was created is that I couldn’t find another way to easily set manual brightness levels in Baton and Anduril code. Swing UI is coded to add easily any brightness level in any mode. UI is polished , but have some old bugs like no aux LVP and floating stepdown timer… and amateur coding 
If you like i can share it with you and you will fix all bugs in no time. I think its an ultimate UI and should be represented as an alternative.
Oh, cool. I didn’t realize you created it. I’m sure I missed some things, having only seen a short video of it.
You wanted to manually set the level for each step, to get better spacing?
Usually it’s easier to adjust spacing by changing the ramp shape… give it a different exponent to bend the curve up or down. Like, x ramps up the low modes faster than x2, and dedicates more of the ramp to high modes. And x2 has fewer low modes than x3. And so on. To really devote a lot more of the ramp to the low modes, sometimes I’ve bent it as far as x9. But if the lowest power channel doesn’t have enough resolution for that, you could end up with a bunch of 1’s in a row at the ramp bottom.
Manually setting the level of each step seems like an effective way to get visually-linear steps without a visually-linear ramp. But when possible, it’s usually easier to fix the ramp shape instead.
About aux LVP, it’s usually pretty easy. It just takes a few extra lines, and the hard part typically is whether there’s enough space in ROM for the extra code. I avoided adding it for a long time because I was trying to squeeze out every last byte.
Yes indeed.
WTF is x2…x3.x9… dont mind it . Like i mentioned before i can send you a code and you’ll see what is what . You can test it with fet+1 driver.
Just regular math. x2 is x * x, and x3 is x * x * x.
Anduril’s ramp calculator script takes an exponent as one of the parameters, and this exponent determines the ramp shape. The higher the exponent, the more it squishes the ramp down, meaning it has more low modes and fewer high modes.
Usually x3 is regarded as “visually linear”, but that’s a bit of an oversimplification. Calculating a good ramp usually takes more fine-tuning.
The parameters are usually given for each build target in the cfg.h file, to make it easy for people to adjust. If the mode spacing on a particular light seems bad, copy/paste the command in its cfg file, and start changing values to produce a better ramp.
Thanks. I just took delivery of the FC13. Pretty impressive performance and the Anduril 2 is very well done and fairly easy to navigate. Easy access to low and high from the off position was no problem. Other nice features like the find in the dark aux light etc. etc.
However, it’s considerably longer and about 40% heavier than the SC64 with a terrible pocket clip. So it will definitely not replace the SC64 as my EDC but will be a good backup light and useful to take on trips as a spare.
In case some visuals might help, here’s a graphing calculator showing some of the ramp shapes I’ve used in different Anduril lights.
From left to right, the shapes shown are x2, x3, x5, and x9. But the exponent can be anything, even 3.7231 or whatever… to really fine-tune things.
Usually I find the best ramp shapes are between the blue line and the green line, but not always. It really depends on the specific light being calibrated.
21700 without a counterweight unbalances the light sometimes, D1 already felt nicer with the short tube than 18650, surprised that Hank went for a d1k, not a 21700 d1s.
And it also depends on balance preferences, length restrictions, and battery life and throw needs. I’m more averse to length than bezel diameter, which is why I like the dt8 and d1 with short tube more than 18650 lights. Given the cheap b35am option at the moment, I think the D1 is my default rec to people, the only nit to pick is the moonlight output.
@samsat Looks like the SC64c LE is back in stock now:
OK great, that’s comforting to know. Thanks.
I’m aware of that, but my comment was a response to the comment I quoted recommending lights with Anduril firmware and FET drivers.
Im huge Anduril fan, thanks for all you do.
Feature request, OPTION for Nitecore D10 Style Ramping:
Alternate the direction of ramping, using the same 1H command.
With the OPTION enabled, there would be no time limit, to alternate direction up, down, up, down… etc
I highly doubt that would be very popular. That would mean that if I last ramped up and then minutes later wanted to ramp up more I’d have to first 1H ramp down, then 1H ramp up. Sorry, this is bad UI. There’s a good reason the “1H alternating ramp direction” resets after a short time delay.
1 Thank
Dont worry…
You would not have to use the OPTION if you dont want to.
I also doubt it would be added as an option since flash space of the MCU is at a premium (for some devices).
That said, it would be fairly trivial to make the code change to make this the default behavior and compile it for your various devices.
Would you please build me a Hex for the SC21 Pro and TS10?