That sounds like exactly what I want: switching modes when on would mean first turning the ring to the target level and then clicking twice to execute the switch. For example, from off, turn the ring to “e-trit” and click to turn on, then turn the ring to a standby mode (say, medium) and pocket the light. When it is needed, pull it out and click twice to activate.
And if flashpads are available, this would provide the added bonus of allowing me to reconfigure the light’s modes and their wheel positions, thermal limits etc. by compiling and installing a custom Anduril. If OP could support this with a desktop or web UI, this would even fulfill a request I have occasionally seen made on this site and on Reddit.
Then I’m living in ignorance. Glancing at it, seems likely the magnet is under the rigid boot as I had speculated.
Power-interrupt UI limits options for signaling. Brief off-on cycles modes. Long off then on delay returns to default brightness level (typically lowest level). Mode memory would help for long delay, or some means to set default mode to one’s choice.
This is why I want the rotary wheel without any other mode switching or memory. Brief off-on would not cycle modes. Long off would not return to default.
i logd in for this just to say this this is what i need in ma edc light a battery thats gonna last a long time and a button on the side or a ring would be cool i dont need much
I’m not sure I follow the desire to use Andruil for this light, surely just the rotary dial plus rear forward clicky would be sufficient?
Ultimately, what it appears you want is a slimmer version of RRT01, whether this is physically possible with the rotary dial, I do not know, but I’d be interested in something similar.
Do note that the mechanical clicky is, by it’s nature, going to add length to a light, and an e-switch will always have some (small) standby current.
It does appear that the RRT01 is the closest (only) available light if you desire a rotary switch, else, if you want to compromise on a rotary ring, one of the tail-eswitch clickies in production (emisar, TS10 or FW series) might not be far off what you need?
This was in response to @yhanz who stated that efficient dual-fuel regulation in my desired form factor is challenging. I just remarked that KR1AA manages this (through Anduril). I do not primarily desire Anduril but I thought that this hacky “mechanical Anduril boot menu” might be a simple way to achieve efficient regulation.
However, I may have misunderstood what Anduril does exactly. If KR1AA-like regulation is possible without Anduril I am fine with that too. (But I also think that having well-documented control over the device firmware is desirable, and that FOSS firmware is valuable in its own right.)
More like a shorter (≤80mm) version of RRT01, though slimmer would of course also be nice if possible. (My understanding was that RRT01 has linear regulation though?)
I think what I rather want ideally is a KR1AA with a wheel instead of electronic mode memory, with zero parasitic drain and momentary-on. Given it slims down in the middle, there might even be space for a wheel there, but if a forward-clicky mechanical switch further adds length then what I want could be impossible. (Unless the head could be shortened, at least for my desired floody configuration… is mule + flat diffusor a thing?)
I also like the TD07 wheel in principle, which could probably even be made a bit slimmer, but the rest of the light and UI does not fit my criteria.
I actually already ordered a KR1AA, but if OP makes a robust light as specified I would still buy it and probably switch.
Anduril is just the “operating system” for the hardware, it’s certainly possible to have hardware that doesn’t run Anduril; zebralight and Skilhunt have efficient drivers with their own user interfaces.
Right, I had assumed that Anduril was part of a control feedback loop, adjusting driver parameters in response to changing conditions such as temperature and potentially voltage. But I admit that I don’t know if that’s actually the case. Other firmwares are obviously possible, I just thought that the possibility of adapting an existing FOSS firmware that’s proven to support what I asked for would alleviate OP’s concerns.
More specifically, FSM is basically the kernel and UI toolkit, and Anduril is an application running on top.
FSM is designed to make it pretty easy to build whatever application you want. Or in other words, build whatever UI you want. And if what you want is a brightness control ring with a forward clicky power button, you’d basically just need to write a bit of hardware driver code for the control ring, and a really minimal UI to read the ring position and set brightness. FSM handles pretty much everything else.