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

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:

Yep, I got that. I didn’t interpret your post as being even remotely pushy.

I thought the standard terminology used by everyone is "click", being a full cycle of down/up, and then "press&hold". Reacting to the initial press, is of course, possible and a little quicker. A press without being a press&hold is unusual - not sure what manufacturer uses that, and how much faster a "down" is from "down/up"? I've played a lot of video games over the years, and sports with quick hand motions, so maybe I'm so quick and used to it I can't tell the difference?

I'd be more comfortable with: press, click, press&hold

I have a bit more work to do but should be able to announce giveaway winners shortly. I’m going through the posts with more detail, putting together a list of the remaining suggestions I’m going to implement.

While doing so I read a suggestion that I missed before:

I’ve never heard of this so I have to ask, why would you want this? If you have press & hold for brighter, and double press & hold for lower, why would one want this wave like behavior?
If you are on the back side of the wave where mode level is going down, the mode presses will be reversed. You’ll have to remember which side of the wave you where on. To me this would only make sense if you only have mode up function on your light, and no mode down. Or am I missing something?

The Folomov 18650S has this sequence - dunno, some complained about it, some like it.

Does that light only have ‘next mode’ function? No ‘previous mode’ ? That would explain it for me.

Ahh, think so... Don't have one here with me to check, but pretty sure that's how it works.

MikeC, you’re not missing anything, I was - Press&Hold for up and Double Press&Hold for lower is much better. My early suggestion was more for a rudimentary cycling UI that doesn’t offer a method of reversing direction and I didn’t realize how sophisticated your’re driver was/is getting. Looking forward to it.

Things have progressed a little, I’ve managed to sneak in a bit of development time.

There are a few suggestions for battery check here, but not many on exactly how to do the battery check. I have methods from my old firmware and a few new ideas but I’m looking for suggestions. How do you want to do battery check? Looking for suggestions for both clicky switch and E-switch.

1. I am used to triple-click on e-switch lights. That just works for me.
2. Signaling battery level during use (drops to 50% - light blinks it out somehow) would be useful…but very confusing to unprepared users.
3. I tend to prefer 4-5 bettery levels to voltage readout.

Triple-click on E-switch was what I was thinking too.

Any suggestions on clicky? My old clicky firmware battery check can only be done from off so it doesn’t interfere with normal mode changing. How does it work in other clicky firmware/lights?

In Bistro (has capability to detect “long presses” via an OTC), you long-press from the lowest mode to get into the blinky modes including battery check.

In Biscotti, in some mode groups it’s just an option in the normal modes rotation.

In Babka (a firmware of mine), I hide it behind a triple-click.