EDIT: 3/22/21 2:01 EST (full rewrite for clarity)
I’m looking for two things. 1) Help from a member here with the ability to write a new simple firmware 2) Feedback from members who are fans of forward clicky switches and wish there was better method for mode switching
Scope: Presentation of multi-mode UI/firmware for lights featuring a forward clicky switch and without a secondary mode selector like a head twist or side e-switch.
Problem statement: Currently, the use of a multi-mode driver with a light equipped with only a forward clicky switch means that you effectively lose momentary functionality. In other words, if you use a FC switch for it’s main feature — momentary activation — you will cycle through modes even when you don’t want to.
Proposal: UI that uses same old power interrupt methodology as every tail clicky firmware but that ignores the first few signals before switching modes. [ I will refer to a power interrupt to the driver as a ‘signal’]
The code would include an ‘initiation’ or ‘activation’ criteria for multiple signals within a short time period before it would begin cycling through modes.
For example, lets say 3 signals in 1 sec is required to ‘initiate’ mode selection. During those first three signals, the light would remain in the same mode. But 4th signal would begin mode switching as normal. Something analogous to ON-time memory closes out mode switching window after say 1 sec in the newly selected mode.
I know mode count / order / memory is a personal preference, so building this on top of something like a Biscotti multi-group code as a base would be ideal (with ~20 or so signals to enter programming). Either that or a STAR-like fw that uses solder jumpers to toggle mode order / memory / and moonlight.
No temp regulation necessary. I feel those interested in such a UI / light configuration have the mindfulness to step it down manually if it’s too hot. YMMV
My target application is dedicated budget throwers and tactically oriented lights that don’t have a secondary mode switch. It should give the predictability and control of a FC single mode light, but the added flexibility and runtime of multi-mode.
What do people think? Any FC lovers out there that feel forced into single mode drivers or other compromises?
Any programmers willing to take this on?
Thanks