I’m still working out some things, but plan to do a bunch of testing today and hopefully improve more internals.
Like, for HSV to RGB, I’m using a standard model where the hue is segmented into 6 different sections, and each section has a linear crossfade between 2 colors. But I don’t really like the end result… it has something similar to Mach bands, inside of the color space. So I’m considering a cosine-shaped crossfade instead. And maybe some sort of additional correction on the brightness.
This also applies to the 3-way auto-tint, which uses a linear crossfade from red to cold white, with a triangle shaped crossfade up and down in the middle for warm white. I think perhaps that should use two sine crossfades instead of one complex linear fade.
Debating whether I can sneak in a “soft start” / “smooth steps” feature too, while I’m at it. And if so, whether it should use a ramp-linear animation or an analog-rise-time shaped animation curve.
There are also complications which arise from having 8-bit on one channel and 16-bit on the other two channels, with a different ramp shape for each. Would be nice to have 3 16-bit channels instead. I may have to calculate a separate ramp just for this, and then convert it on the fly to what the hardware actually needs.
… all just to make things look and feel natural to the user. It turns out that “natural” involves a lot more math than one might expect.
Oh, and it’d be cool to have a multi-candle mode with each LED flickering in its own unique pattern. But that’s tricky too, because the different channels share a single timer/counter in hardware, so I can’t do PWM=5/3789 on one channel and PWM=32/654 on another. The denominator must be the same, so there’s yet another place which needs to hide the hardware details by using math to make the quirks invisible to the user.
sneak in the soft steps. wk30 ui feels like soft stepping or what i think it is. or you mean more like what acebeam has on their 75model. double click turbo ramps up instead of instant.
either way, i like the “soft step” feeling of the wk30
wow. so many things possible with anduril. anduril really is the future
Maeerxus in stepped mode do the same thing as what I think they mean, if you have any of those. Quickly ramps up to turbo over about a second or half a second or so (don’t have a battery in either of my maeerxus right now so can’t time it)
Personally, I prefer turbo to just jump to turbo without ramping, generally when I want turbo then it’s because I want to quickly blast it somewhere, but it might be nice to have as a 9H menu option.
Could you explain the difference? I guess it wouldn’t matter much in the short animation timeframe. I think it shouldn’t be longer than 200-400 ms, same for each animation independent of the difference in brightness.
“Soft start” sounds great especially for 2C : It would probably solve the most unnerving aspect (relatively speaking ofcourse) of seemingly random flashes anytime we need more than 2 clicks (configs, channels etc.).
No longer needing to cover the optics before accessing 2+ clicks, especially when there are other ppl around, it would/will be less annoying (and less awkward too, to be honest).
Soft turn off would be great on my warm night lights, I would probably set it to a long full second or two.
For turbo access with a hold (off 2H and ramp 3H, if available) probably don’t need soft start, but maybe I’m wrong… It could give a sci-fi vibe to it, especially if it ramps up exponentially : “set phasers to maximum stun!”
It would also probably work great for the blinkies, be easier to read.
Math is just a model for reality – and reality is always more complicated than any model – even the most perfect, comprehensive (and therefore complicated) model necessarily leaves something out – the question is always what you’re willing to leave out to keep things manageable.
As @wolfgirl42 pointed out, there is a compile time option for that. When turning the light on or off, the timing can be configured. There’s the moment the user presses the button, the moment they release the button, and the moment the torch stops waiting for more button presses. The default “turn on” behavior is when the user releases the button on the 1st click, but it can instead be set to “when the torch stops waiting for more button presses”. That way, the light doesn’t turn on during the middle of a 3C or 4C or whatever. It waits until the user finishes pushing the button, then responds.
If you’re able to compile the code, maybe try this option. It sounds like you are exactly the sort of person it was written for.
Thanks to you both! Also I just realized that I was wrong about 2C flashing, only the 1st click “shows” (memorized brightness) when switching to simply ui for example.
So I would use b_timout to add a delay after the button release, right?
And what about an eventual soft start? Did I understand correctly that it could be used here instead of a timeout? There would still a flash, but it wouldn’t have time to ramp up to the memorised brightness before the second click, so it would always be a low brightness flash.
I added soft start / smooth steps, and have been testing stuff before uploading anything. It seems to work pretty well, aside from a minor delay at the final step before shutting off.
However, it doesn’t help very much with avoiding the flash on the first click. For that, you’d still need to add a line to the build config file:
#define B_TIMING_ON B_TIMEOUT_T
This tells it not to turn on until the input sequence is finished.
The default setting is faster, and activates as soon as the button is released on the first click:
#define B_TIMING_ON B_RELEASE_T
There’s also B_PRESS_T, which activates immediately (at moon level) as soon as the user touches the button. It used to be the default, but a lot of people found the moon pre-flash didn’t suit their taste, so I changed it to have a slightly slower response.
First of all, thanks Toykeeper for the years of work making this amazing and customizable firmware for all kinds of lights (huge understatement)!
It occurred to me to ask, have you considered that with all the excellent multi-channel upgrades and improved functionality, it could be a good time to declare a new major version of Anduril, i.e. Anduril 3?
A new version would bring clarity to any UI changes. Manufacturers can continue to use Anduril 2 as a stable target for new lights (Convoy released a new Anduril 1 light in 2023!).
And “Anduril 3” fits perfectly with the new triple-channel light(s) from Noctigon/Emisar as the new state-of-the-art for other manufacturers to aspire to.
Thank you for your consideration and I will remain an Anduril user no matter the version name.
I think Anduril 3 can start after Bluetooth or Wi-Fi connection or when we add new specifically things in flashlights that change UI mode for the human.
Probably the 3 channel is Anduril 2.1 immo
I changed it from Anduril 1 to 2 when I made major backward-incompatible changes to the UI which impacted the user, to make it more clear that there were things to learn in order to use the new version.
However, I haven’t done big backward-incompatible stuff since then, so the name has remained “Anduril 2”.
If I make Anduril 3, it’ll probably have much bigger, deeper changes… like onboard calculations for the ramp instead of using a lookup table, meaning that the user could adjust the ramp shape without reflashing. Truly smooth ramp instead of a 150-step ramp. Completely rewritten internals. Reworking the UI in backward-incompatible ways to make more advanced features fit better. Maybe switching from AVR to STM32L4. A bootloader. Maybe bluetooth or an optical dongle to reflash or configure it. Plus hopefully USB support and some sort of app to configure deeper options like ramp tweaks and thermal response. And it would probably not run on Anduril 1 or Anduril 2 hardware.
The main thing is that a name change signals large breaking changes. The “2” in “Anduril 2” isn’t a version number; it’s just part of the name.
Thanks for the response @ToyKeeper , in that case, long live Anduril 2!
I like that approach as well, similar to what’s described at semver.org
MAJOR version when you make incompatible API changes
I only have single-channel A2 lights so after much reading (hence username) I got the impression that the UI was going to have big changes—but it sounds more like nothing is breaking and instead new optional functionality is being added for lights that support it?
