Any firmware developers willing to help? (Simple but novel clicky UI)

8 posts / 0 new
Last post
JaredM
JaredM's picture
Offline
Last seen: 1 day 5 hours ago
Joined: 10/31/2011 - 13:33
Posts: 1870
Location: Pittsburgh, Pennsylvania
Any firmware developers willing to help? (Simple but novel clicky UI)

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

Edited by: JaredM on 03/22/2021 - 05:51
chadvone
chadvone's picture
Offline
Last seen: 3 days 4 hours ago
Joined: 08/28/2015 - 23:48
Posts: 1939
Location: Iowa

I am a FC lover. I spent some time years ago working on a Forward/Reverse clicky. Not sure I still have it.

Rusty Joe
Rusty Joe's picture
Offline
Last seen: 1 month 1 week ago
Joined: 07/24/2011 - 00:22
Posts: 3424
Location: Houston, TX

Unfortunately, I don’t have much skill for modding, so it’s easier to buy a switch that is a forward clicky. I’d definitely invest in one I knew would fit.

JaredM
JaredM's picture
Offline
Last seen: 1 day 5 hours ago
Joined: 10/31/2011 - 13:33
Posts: 1870
Location: Pittsburgh, Pennsylvania

Rewrote OP while not actually in a huge rush this time..

Unheard
Unheard's picture
Online
Last seen: 8 min 53 sec ago
Joined: 01/16/2019 - 11:38
Posts: 1890
Location: Germany

Nice idea! Thumbs Up

Please don’t forget Morse code blinkers. Within a second you blink out an “S”, so I’d lower the timeout. But that’s no critics, I guess final parameters can be found only after trying such a light.

Smile, you cannot kill them all.

JaredM
JaredM's picture
Offline
Last seen: 1 day 5 hours ago
Joined: 10/31/2011 - 13:33
Posts: 1870
Location: Pittsburgh, Pennsylvania

You are correct, playing with the timing in an actual light would be how I determined the final values. But I’m thinking that ~5 initiation signals in an ~800ms window seems like the range I’d prefer.

Experimenting with an online interval stopwatch, I did some Morse SOS sequences to see how long a reasonably fast ‘S’ would take, and to my surprise it was on average 14ms per dot, so about 3 signals in a half second. Faster than I thought. My dashes where a bit over double that at around 34ms. So 3 signals in one second is probably quite conservative.

chadvone
chadvone's picture
Offline
Last seen: 3 days 4 hours ago
Joined: 08/28/2015 - 23:48
Posts: 1939
Location: Iowa

How about no mode changes unless light is on for 3 seconds. And that rule resets after light is off for 3 seconds.

Scenario 1. Signal like a strobe light if you thumbs fast enough. Morse Code. Attention getting… as long as light has not been on for 3 seconds there will be no changes.

Scenario 2. Walking with light off. Hear something, Press to watch a raccoon run off(over 3 seconds). 3 seconds later you can do same thing without mode changes.

Scenario 3. Walking with light ON (over 3 seconds). Hear something, click OFF-presses to find your output.

Drawbacks- light must be on for 3 seconds to change brightness.

It early and I have not had my coffee….

wle
wle's picture
Offline
Last seen: 5 hours 13 min ago
Joined: 01/07/2015 - 13:49
Posts: 2251
Location: atlanta ga

it SEEMS like you could do that with a capacitor across the battery, that would effectively keep the processor alive during short button presses

wle

"You never have the wind with you - it's either against you, or you're having a good day."
    Daniel Behrman, "The Man Who Loved Bicycles".
It never gets easy, you just go faster.   
-Greg Lemond.
       ,ø¤º°`°º¤ø¸,ø¤º°`°º¤ø¸,ø¤º°`°º¤ø¸