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

No worries! As I mentioned to pc_light, I like it, but don’t want it permanent. I’ll make it a setting than can be enabled/disabled.

Cool :sunglasses:
:beer: :beer: :beer:

I don’t know if Crescendo has it, but there has been some work done with switch timing for clicky switch drivers, allowing a range of “Short” and “Medium” and “Long” presses. Somehow the driver counts the decay between the time the driver loses power and when power is resumed. If it is X amount of time, it is counted as a “Short” press. If it is XX amount of time it is “Medium” press and if it is any more than that, it is a “Long” press, basically a complete off cycle.

Different terms used I guess. I have the exact same functions but I call them short press, long press and off. Short press is up to 1/4 second, long press is between 1/4 second up to a full second, and anything longer than a full second is a power off cycle. The OTSM method allows rather exact timing. Old fashioned OTC is more difficult to get exact timing for multiple press durations.

I hadn’t noticed this thread until today, but it’s full of good ideas. I might refer back to this later when I’m working on UI designs. Apologies in advance for a long multi-reply.

These look really interesting. I don’t have any tiny1634 drivers yet, but I hope to add support for them sometime. I’ve already started on tiny841, and after doing that I imagine it’ll probably be easier to add a third type of MCU.

I’m glad to see people describing interfaces this way. It’s simple, it’s precise, and it can be translated almost directly into executable code without much effort.

Something I’ve found useful to make configuration easier is context-sensitive config menus. Basically, attach a short config menu to each configurable mode. I’m using 4 e-switch clicks as “enter config mode”, but it could be anything. For example, to change the timing of beacon mode: Go to beacon mode, click 4 times, then enter a value at the menu prompt. Or to configure the ramp parameters, go to the ramp mode, click 4 times, then enter a couple values in the menu prompts. It’s faster and easier than scrolling through a master config menu.

In case anyone wants a quick way to calculate evenly-spaced mode levels, I made a ramp calculator script. Basically, give it a few parameters and it’ll spit out the raw numbers needed in the firmware to produce a perceptually-linear ramp. The ramp shape can be several different formulas, and I find it’s helpful to tweak the shape for each type of light. Sometimes logarithmic works, sometimes cube-root, sometimes ninth-root, or whatever.

The numbers from the ramp calculator can be used directly for a smooth ramp, or used algorithmically for a stepped ramp. Basically, the user configures the brightness of the lowest level and the highest level, plus the total number of steps, and they get a custom set of evenly-spaced modes. No need to configure each level individually, and no need to include hardcoded mode groups in the firmware.

This should also work with the FAT-3 / SLIM-4’s control system, using an integer number of mA… though the driver will need to do the ramp shape calculation onboard, and that can be a little tricky on these MCUs. So I’ve been doing those calculations on a computer instead, and using a hardcoded ramp on the driver itself.

Yes. +1. Thumbs-up. Menus on clicky switch lights are really hard to do well.

If you have OTSM working though, that probably simplifies things a lot. Instead of rebooting on each tap, it could keep the program flowing forward and continue from the same state. I’ve been meaning to add support for that to FSM, but haven’t done it yet. I imagine I’d just make “short tap” and “medium tap” their own UI event types, and otherwise handle them like normal button presses.

I have a compile-time option for this… Instead of a brief “battery is connected” blink, it turns the light on when power is connected. Normally it uses the last-ramped level, but if the e-switch is held at boot, it goes to moon instead. Would that work?

It’s definitely annoying to have to lock and unlock a light frequently. I don’t know the best solution, but I’ve found it helps to make lockout double as a momentary low mode. At least then it doesn’t need to be unlocked for quick tasks which don’t require a lot of light.

Another suggestion I’ve heard is to do a two-level momentary during lockout. Normally it’s just a momentary low, but if the user does a quick click-release-hold, then it becomes a momentary medium.

I’m not sure what the clock speed is, but if it’s 10-bit fast PWM, what does the PWM speed itself work out to? If I’m doing the math right, 8 MHz with 10-bit fast PWM should be… about 7.8 kHz PWM?

On tiny85 I’ve been using 8 MHz with 8-bit phase-correct PWM — 15.6 kHz. But on the lowest levels, I drop the clock speed to slow down the pulses and make the output more stable. I forget if it goes down to 2 kHz or 4 kHz, but it makes PWM level 1 usable. And at that low of a brightness, the slower PWM speed isn’t very noticeable.

I’ve seen three styles:

  • Anduril immediately turns on at the lowest configured level as soon as the button is pressed. When the user releases the button quickly, it then goes up to the memorized level. If they keep holding instead, it’ll make a brief blip when the timeout threshold has been reached, letting the user know they can release the button to stay at moon… or keep holding to ramp up. This is what I refer to as “immediate on”.
  • NarsilM waits until the user releases the button before turning on at the memorized level. Alternately, the user can hold the button a bit longer and it’ll turn on at moon after the hold timeout has expired. This is what I refer to as “delayed on”.
  • If I understand correctly, the FAT-3 / SLIM-4 interface waits until it’s sure the user has stopped clicking, and then it turns on. I guess this would be a “fully delayed on”?

There’s a similar thing for turning off:

  • Some lights turn off (or change modes) as soon as the button is pressed. I would probably call this an “instant off”, since it’s the fastest UI option. But it’s not very compatible with “hold to ramp”.
  • NarsilM waits until the user releases the button before turning off. I’ve been referring to this as “immediate off”, even though it’s not technically immediate. It should perhaps be called a “delayed off”, to keep things in line with the naming scheme for turning on.
  • Anduril (and if I understand correctly, FAT-3 / SLIM-4) waits until it’s sure the user has stopped clicking, and then it turns off. I’ve been calling this “delayed off”, but perhaps it should be “fully delayed off”.

Maybe instead of immediate, delayed, and fully delayed, it should be press, release, and delayed? Words are hard.

Anyway, each method has its tradeoffs, and people are pretty passionate about their preferences on this, so I’ve been meaning to make all this a compile-time option in Anduril… but I haven’t yet.

The double-press-for-turbo action is pretty fast. I’m not sure how long, but the timing window is short enough that I occasionally miss it when trying to do it on purpose. But it’s also long enough that I frequently hit it by accident when I’m trying to change modes quickly. I’d guess probably about 200ms.

That sounds a lot like Crescendo, but better. You’re using a driver with short/med/long press detection (or short/long/off), so it can have a nicer UI. However, Crescendo and the guppydrv drivers can’t detect medium presses, so they use a somewhat more primitive interface. It’d be nice to have three levels of “off” instead of two. I’d definitely design things differently if it had a medium press.

Anyway, sorry again for the long post. I’m really happy to see this type of discussion and development happening.

Initially I though:
Yes!
It’s a little awkward and for me would be impossible to figure out on my own. But would work.
But actually…

Current option:
Screw the tailcap back, find the button, click
Proposed change:
Find the button, click, screw the tailcap back

May have 1 grip change less in some cases. Not sure, I will practice the motions while I return from work but as of now it doesn’t seem substantially better.

Recently the concept of a configurable default mode has really grown up on me.
Some want lights to normally start with the last mode
Some want lights to normally start on moon
Some want lights to normally start with some intermediate mode (like 350 mA)
Some want them to normally start high

Being able to configure some default mode should work for all of them….and would work better in the case of turning the light on as the power is connected.

Thanks for your long post TK, it’s well worth reading. :slight_smile:

Yes - In NarsilM, one full click (quick press&release) is ON and OFF - no delays. Again, calling a press&release a delayed on implies this operation is delayed -- it's not delayed, it's very quick in fact. I kind of tweaked out NarsilM for fast operation, some find that difficult, or difficult to learn but priority is always on quick responsiveness - I dont' like UI's forcing delays and try to avoid them. I don't care much for dbl clicks, triple clicks, etc. but we kind of have no choice there.

In NarsilM, a multi click sequence always acts on the first click (ON to last level -- priority given here), but 2nd, 3rd, etc. clicks are not acted on and the delay to action is minimized but configurable in a source code constant. I don't want someone doing a triple or 4 click operation and getting flashed with turbo on the dbl click.

Yes; I’m just not sure what to call each style. Perhaps press-on, release-on, and delayed-on? Normally I would describe it each time, but it seems to come up often enough that it’d be useful to have a name for things. I don’t really care what the name is though, as long as it’s reasonably easy to understand. Does this seem okay?

Press: Instant. Fastest possible response.
Release: Very quick. Wait until user releases button or holds long enough to be a “hold”.
Delayed: Unambigious. Avoids false starts in the wrong modes.

On

Off

NarsilM

Release-on

Release-off

Anduril

Press-on (moon), Release-on (mem)

Delayed-off

Mike C UI

Delayed-on

Delayed-off

I’m also not sure what to call the UI Mike C created. Does it have a name?

Why do you do this? Would you do this if firmware lockout is very easy and you knew that the driver has very little parasitic drain? I mean like taking over 1000 years to fully deplete a cell (if only considering actual current drain) ?

Physical lockout tends to be quicker to activate and deactivate.
Also it lets me work around what is a misfeature for me - mode memory.

If I had a light with no memory, good e-lockout ergonomics and OK drain I would probably prefer e-lockout.
With features like TK’s low momentary I would prefer it for sure.

As promised in another thread I’ll send you over some simple boot strapping stuff. I’ll make a zip file and PM you where to get it.

That’s a good suggestion, thanks. I do have a quick shortcut for a feature only available for my ramping UIs, I could use the same shortcut to make quick changes on “normal” UIs.

Personally I’ve focused on making it easy to adjust each brightness level while operating the light… No need to run any scripts, and no need to flash again if the spacing wasn’t right the first time.

OTSM simplifies things a lot. I don’t reboot on any short or long off press. I only reboot if off time is long enough to be considered a power off cycle (above 1 sec), or changes have been made to light configuration. My code for clicky switch actions is identical to my code for e-switch actions. It’s only the actual detection method of the presses that is different.

Currently I have a have a solution with E-switch that I like: Pressing and holding the switch on startup enables moon mode. If the light is locked it will turn off as soon as the switch is released. If it’s unlocked moon will stay on until switch input. So moon mode always works, regardless if light is locked or not. I haven’t found a satisfactory way to do this “moon while locked” with clicky switches. I haven’t yet implemented different lock levels either, but I’ll get around to that soon enough… I hope…

I did forget to mention the rather significant detail that I am using clock speed of 1 MHz. Fast PWM is pretty slow at 1 MHz. But I’m only using PWM on ~50mA, I don’t notice any flickering. Everything above ~50mA is constant current without PWM.

Correct. My E-switch multi-press detection is set to just under 1/3 of a second. My E-switch ramp down is double click and hold on that second click. I’d really hate it if the light did something between those two clicks. I did a trial with what you would call “delayed on” while keeping my “fully delayed off” but that was even worse, much better to have the same delay behavior for everything. I can live with a 1/3 second delay, I prefer that over having the light do things between clicks. Like my 3 press short cuts, I don’t want the light to do anything while I’m entering that 3 press shortcut, it would annoy the heck out of me.

I’ve now implemented the double tap. MascaratumB and chadvone gave me some valuable input for this, I’d never seen it before (locked in my own bubble). I now use it in two of the UIs, one of them is a new ramping UI I made specifically for this way of operating clicky switch lights. 200ms is actually the time I settled on after a fair bit of testing.

Yes, it’s OTSM makes this possible. With OTC it’s very difficult to get consistent results while detecting multiple off press durations.

Not really. I have 6 different UIs to choose from, and they all behave differently depending on which switch configuration is selected (off-switch, e-switch or dual switch). So using the name for the entire firmware doesn’t really work in this case. I don’t really have a name for the firmware either, rather low on imagination for that sort of stuff.

Glad to see the progress on this Mike :wink:

About the name… I guess it should be called: Excalibur :sunglasses:
[it gathers several UIs at the same table driver and only Mike rules them :smiley: ]

I think there are enough swords as it is. Besides, my firmware doesn’t need a name, it’s specific for my own drivers and won’t be adapted to any other drivers.

I was kidding Mike! :wink: I guess we are all OK with no names here :wink:

Ahh, no worries.

Progress is a little slow here as usual but lately I’ve got some stuff done and worked out some quirks so I should be able to get some of these drivers out the door soon. I have to take a break now though, heading out the door for another work trip, gone for almost two weeks.

Eheh, have fun and come back with new ideas :+1:

NO! No new ideas! I want these test drivers to ship! :innocent:

David is right… Just ask how long he has been waiting on one of my drivers… I think as far back as the good old ATtiny85 days even :blush:

I’ve got a few more suggestions from this thread that I am going to implement when I get back from work travels, then I just want to start sending some. Changed working conditions unfortunately means less time for this stuff, but I’m hoping it won’t be much longer.

I hope you know I said that in the most lighthearted and not-pushy way possible. After all, this is a hobby for all of us, and you have a right to your own time. Not only that, but I’ve been busy lately myself and have gotten way behind on stuff, including some projects I’ve promised to do for other people quite a while back. So I really do understand completely. :person_facepalming: