Driver giveaway: Constant current 17mm drivers, winners (finally) announced, post #2.

People's too fond of super-low modes, they're handy for some situations. With regards to modes I prefer even spacing, up there I suggested 11.1% - 33.3% - 100% (by 3x each time), albeit for slightly less difference a smaller multiplier can also do: 16% - 40% - 100% (by 2.5x each time). Of course this is just my point of view, but please bear in mind whateverfold increases in driving current/power at the emitter do translate in lesserfold light output increases.

Cheers ^:)

Always great to see your work, Mike C, nice to have a chance to see what you have in the making.

I’m not in for the giveaway, for a reason you might understand more than anyone else: I don’t use what I can’t program myself :smiley:
And it would be a pity just to have such a great driver lying here, knowing that someone else might have use for it.

But I’m happy to chime in on your UI question.
I don’t want wrap around - ever. Which rules out about every stock clicky firmware in the repository…

1. clicky lights

- 2 to 7 modes, evenly spaced in brightness

- usually 4 mode groups: 7 modes, 6 modes w/o turbo (for muggles), 4 modes, 2 modes

- short press (tap): brighter mode

- medium press (1sec): darker mode

- no wrap-around = no accidental moon after turbo, no accidental turbo after moon (you know: wham! ugh! here goes my dark adaptation) and several short presses in a row always reliably result in highest mode

- 12 short presses to battcheck

  • 15 short presses to config mode (modegroup, memory, turbo timeout and LVP can be toggled)

2. momentary lights
a)
similar as the clicky UI (modegroups, battcheck, config mode) with

- no memory

- short press from off = moon

- long press from off = turbo

- long press from on (any mode) = off

- short press: brighter mode

- medium press (1sec): darker mode

- no wrap around
b)

- short press (tap): on/off with memory

  • hold when on: ramping up and down and up and down and…

Interesting idea, thinking out of the box, that’s for sure. I don’t think I would use it myself though, I mostly use my lights when moving underground and a simple UI with a few clicks will always be easier.

Oh yes, I understand completely! Be it a headlamp, bike light or hand held, if I can’t stick one of my own drivers in it I’ll either make a new driver for it or bin it :slight_smile:

I haven’t thought about it like that. It’s a good idea indeed, in particular for clicky lights. I’ll make a user setting for it. Thanks for that one.

This differs some what from most people. Almost everyone seems to prefer short press from any mode to be off, regardless of UI type. I used to prefer long for off myself but thought I was alone so I made some UIs with short off to see what the fuss was about. I had to put some effort into thinking about the other button sequences and ended up being converted myself, now I prefer short for off too. I did have multiple UI options for off selection in some older firmware, I might bring that back to life. In any case, it is refreshing to see other options than short for off. Apparently I wasn’t alone like I thought.

Thanks for the input!

Short press from any mode to OFF? WTF? And how the hell do you switch modes? Pretty ill-suited if long press or whatever, imho. :facepalm:

Cheers

Same here. After adapting my UI to short off I like this type more. And short off doesn’t confuse muggles if they get their hands on my lights.

Interesting, though it needs a tail switch. Otherwise locating the switch during the next use would be a problem
I love QTC twisties and this very much reminds me of one.
Among the things that QTC does well is the ability to fine tune the output easily. I’m afraid that preventing accidental output change during regular user movement could interfere with that. I’ve spent a while looking for solutions, I find nothing satisfactory.
So…I’m afraid it wouldn’t work as well as I wish it would, but I surely miss many implementation options and maybe I’m just exaggerating the impact of regular hand movements.

My Driver Setup For Single LED EDC

*Press and hold when OFF= Moonlight

*Single Click = ON

*Single Click = OFF

****Press And Hold When ON****RAAAMMMMMPIIIINNNNG!!! (I think that the way you setup these drivers the ramping would be super smooooth!!

*Double Click = 1st of 3 BRIGHT modes

*Double Click = 2nd of 3 BRIGHT modes

*Double Click = 3rd and BRIGHTEST mode

*Triple Click = Enters into mode 1 of 3 separate modes. (Bicycle Flashing Light)

-Single Click = 2 of 3 separate modes. (Battery Check 1 blink low * 5 blinks full *

-Single Click = 3 of 3 separate modes. (S.O.S.)

-Single Click = OFF

* When OFF, Double Click Then Press And Hold On 3rd Click = Lockout

* I REALLLY WANT ONE OF YOUR DRIVERS PLEEASE! I know Im new here but I really want to build a sweet Thrower with one of these drivers!!

A well defined set of proportionately scaled modes is a most standard configuration which can fit everyone. For a 2.5x order of magnitude and 5 modes total (4 plus moonlight) that would be, in percentage: 0.2, 6.4, 16, 40 and then 100% (2.5x-fold the previous mode driving current ensures at least doubling the light output). And bullshite anything else LoL! :-D

I noticed that no light serves my major use pattern well…
With e-switch lights I use physical lockout a lot. Light is on, I unscrew the tailcap to turn it off. When I want it back on I screw the tailcap back, find the button, turn the light on.

If the light turned on as soon as I screwed it back I could avoid the last 2 steps.

OTOH it would prevent using shortcut to moon and blast me and everyone around with whatever the default mode is.

I had literally 1 e-switch light where I didn’t use physical lockout. Not that it had one….but even if it did I wouldn’t have to.
Nitecore Tini. It has that annoyingly long click to turn on. I hated that. And it would turn on by itself from time to time anyway.
But maybe a more elaborate turn-on sequence would serve as well as a lockout? 2-click on?

I have lock out feature in my firmware, and with the ATtiny1634 I have the parasitic drain down to 1uA which is theoretically over 3000 years with a 3000mAh cell. I haven’t checked if the CN regulators leak any current yet though, but if they don’t there shouldn’t be a need for physical lockout.

I do detect weather power is back after cell replacing in E-switch only configuration. Currently I have it set to blink a confirmation that the cell is back, then the light goes back to sleep. I haven’t decided weather it would be better to just have the light turn on again, but just as you mention it could blast everyone around.

For the actual lockout I am considering multiple options. One full lockout that requires full unlock sequence, another partial lockout that requires simple sequence on each startup until full unlock is done. I had to have lockout on my BMF SRK because it almost started a fire in my backpack during a mine exploration, but it’s tedious to have to do full lock/unlock each time I take it out of the backpack for photo shoot (it’s off-switch light), so a semi-lock feature would really be helpful in these situations.

Also, an update on the drivers. I have built them now but bumped into an issue for clicky switch lights that I’m trying to solve without new driver design. Doesn’t effect E-switch configuration though.

Also, still working on putting together the firmware. I’ve implemented support for quite a few of the suggestions here, and it’s required me to re-write how my firmware works to support these options, so the suggestions have been appreciated! Keep ’em coming.

Suggestions?

Keep it simple, or as much as you feel fine keeping it. I understand certain people may be accustomed to a lot of driver features but that poses extra work which could pose a serious development hurdle which the majority of users won't really care about. I prefer it Haiku style, it already annoys me grabbing a C8T/C8F and needing to go to Sofirn's website or this forum with my smartphone because I do not @#$%ing know how to switch the group modes or whatever.

In any case, do it as you feel up to.

Cheers ^:)

Ahh, but the whole point of this giveaway is to get suggestions that I like, and then see if I can make them… for myself…

I’m not making these drivers for the masses, I’m making them for me… This thread is only about a driver development junkie looking for a fix, and paying for product with a few drivers :smiley:

Wellp, optimize then access and operation of functions in order of frequency of use. A well scaled mode set and battery check already does for me. Plenty of room for other's suggestions. O:)

Cheers ^:)

Woke up today and got idea of how to avoid seeking the button while avoiding turning on when it’s not needed.
But it’s one of those things that user won’t figure out by themselves within 2 minutes of playing with light. A bit of hidden complication.

The idea is: implement a simple twisty / reverse clicky UI. Unlike most clicky UIs - don’t turn on when the power is on but upon short disconnection. Bonus feature: add more than 1 shortcut like that and or allow more control of the light with just a clicky.

So you have a lighted tailcap that is on while the light itself is in sleep mode? I’d see this more of a lockout feature that only requires a short tap to unlock. I could certainly implement that as one of the lockout modes.

That comment was a followup on Driver giveaway: Constant current 17mm drivers, winners (finally) announced, post #2. - #69 by Agro
Unless I expect that I will use a light again soon I turn it off by unscrewing the tail to physically lock it out. I’d like to be able to turn it on by the tailcap only w/out having to seek the e-switch. As discussed, just turning the light on upon screwing back would be a disproportionate response as it prevents f.e. going directly to moonlight to minimise disturbance.

I believe that with dual-switch lights it would work the same - you normally have the light clicked off. You click it on. What happens? With a regular clicky-only firmware the light turns on. Quite a few dual switch lights do the same. But that’s just the unwelcome choice for e-switch only lights.
But user could click on and then make a short tap to turn on. That’s not something obvious but once you learn it - should be easy to remember.
And would enable basic operation with just the tail switch. Or just the tail cap.

I don’t know how are lighted switches affected.

Oh, so you mean turn on the light by emulating an off press by quickly tapping the entire tailcap?

With tail reverse clicky - just tapping the clicky.
With solid tail cap - quick quarter-turn to break connection and quarter-turn back.

I don’t think I’m fully understanding… why would you need it with tail reverse clicky?