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

222 posts / 0 new
Last post
MascaratumB
MascaratumB's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 10/29/2016 - 12:12
Posts: 4068
Location: Portugal

Mike C wrote:
The long tap you mention is simply turning the light off. Every time you start up in moon you are powering up the light after it was off. It won’t matter if you do your long tap or have it off for hours, that’s power up behavior. It’s exactly what pc_light described.
pc_light wrote:
The way it works is during the Power up, the light always starts in Moonlight mode initially for 500ms. During this time, if a Tap is detected (in other words Double-tap within 500ms dueing initial Power up) the light stays in Moonlight. Otherwise after this initial 500ms it proceeds to Last-mode-memory (or ramping, depending on whether Memory is toggles activated.)

So I still say that Crescendo has no long tap. If you tap and hold longer than a quick tap the light turns off.

Ok I got it now! Wink
By this time you have probably perceived that I don’t know much about this so that “long press” for me was that, and not a “turning OFFSilly Now I get it!
I saw pc_light explanation but I was not putting it into perspective Facepalm

Still, for me is a nice thing, as we can back to the ML mode independently of the mode or level we are in Wink
Sorry for the misuse of terms Innocent

[REVIEWS] AMUTORCH: S3 / S3 vs 219c / AM30 / AX1 / VG10 /// SOFIRN: SF14 + SP10A / SP32A / SP10B /// NITEFOX: UT20 / ES10K / K3 /// ODEPRO: KL52 / B108 /// ACEBEAM: H20 / TK16 /// BLITZWOLF: BW-ET1 /// DQG: AA Slim Ti /// HC-LIGHTS: SS AAA /// XTAR: PB2 Charger /// OLIGHT: M2R Warrior /// WUBEN: TO10R / E05 / T70 / E10 /// ON THE ROAD: M1 / i3 / M3 Pro /// ROVYVON: A2 + A5R / E300S / A8 /// KLARUS: XT1C /// LUMINTOP: Tool AA V2.0 + Tool 25 /// LIVARNOLUX: 314791 /// SKILHUNT: M150

Tricks: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 /// TIR Lenses: 1 / 2 /// Others: Biscotti 3 + 1*7135 / Triple TIR w/ XP-G2 ///// My Collection ///// My Review's Blog (PT)

GIVEAWAY: 1

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

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.

MascaratumB
MascaratumB's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 10/29/2016 - 12:12
Posts: 4068
Location: Portugal
Mike C wrote:
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 Cool Beer Beer Beer

[REVIEWS] AMUTORCH: S3 / S3 vs 219c / AM30 / AX1 / VG10 /// SOFIRN: SF14 + SP10A / SP32A / SP10B /// NITEFOX: UT20 / ES10K / K3 /// ODEPRO: KL52 / B108 /// ACEBEAM: H20 / TK16 /// BLITZWOLF: BW-ET1 /// DQG: AA Slim Ti /// HC-LIGHTS: SS AAA /// XTAR: PB2 Charger /// OLIGHT: M2R Warrior /// WUBEN: TO10R / E05 / T70 / E10 /// ON THE ROAD: M1 / i3 / M3 Pro /// ROVYVON: A2 + A5R / E300S / A8 /// KLARUS: XT1C /// LUMINTOP: Tool AA V2.0 + Tool 25 /// LIVARNOLUX: 314791 /// SKILHUNT: M150

Tricks: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 /// TIR Lenses: 1 / 2 /// Others: Biscotti 3 + 1*7135 / Triple TIR w/ XP-G2 ///// My Collection ///// My Review's Blog (PT)

GIVEAWAY: 1

DavidEF
DavidEF's picture
Offline
Last seen: 11 hours 10 min ago
Joined: 06/05/2014 - 06:00
Posts: 7635
Location: Salisbury, North Carolina, USA

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.

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

DavidEF wrote:
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.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 37 min 19 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9957
Location: (469219) 2016 HO3

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.

Mike C wrote:
FAT-3, SLIM-4

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.

Everyone wrote:

From off:
  • 1 click: something
  • 2 clicks: something
  • Hold: something

While on:

  • 1 click: something
  • 2 clicks: something
  • Hold: something

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.

Mike C wrote:
From off I turn the light on and keep E-switch pressed and it will start blinking. Each blink is a step in the config menu. For example, release on first blink and you are in the “select UI” menu, release on second and you’re in “mode memory options” etc etc.

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.

several people wrote:
visually even spacing of modes

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.

several people wrote:
3 modes … 4 modes … 5 modes … 6 modes …

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.

Mike C wrote:
Menu settings and changing options is more challenging for clicky switch lights

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.

Agro wrote:
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 …

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?

Mike C wrote:
partial lockout

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.

Mike C wrote:
10 bit fast PWM, the lowest usable value is 5

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.

Mike C wrote:
Tom E wrote:
my priority is always 1 click ON, 1 click OFF with no delays

I have to ask about this. When exactly does the light turn on? As soon as you press the button? Or as soon as you release it? Currently I have short cuts from off and I don’t want the light to cycle through modes when entering the short cuts from off, so I have a very slight delay for multiple press detection. Narsil and Anduril don’t have this delay? Does that mean they don’t have multiple press short cuts from off, or they cycle through the modes when entering these shortcuts?

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.

Mike C wrote:
Sorry, but now I’m confused… you wrote “Leave on just a little bit longer before release”. This means waiting a little bit. Now you write there is no waiting Question

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.

Mike C wrote:
Although I have “traditional” mode UIs in my firmware I personally don’t use them anymore, at least not with my clicky lights. I use an UI with two modes, normal and turbo. Short tap alternates between the two, long tap in normal mode enables ramping. When ramping is enabled it’s short tap to ramp up, long tap to ramp down. Tap again to stop ramping.

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.

Agro
Agro's picture
Online
Last seen: 59 sec ago
Joined: 05/14/2017 - 11:16
Posts: 4550
Location: Ślōnsk

ToyKeeper wrote:
Agro wrote:
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 …

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?


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. Smile

Tom E
Tom E's picture
Offline
Last seen: 5 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 12251
Location: LI NY

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 37 min 19 sec ago
Joined: 01/12/2013 - 14:40
Posts: 9957
Location: (469219) 2016 HO3
Tom E wrote:
calling a press&release a delayed on implies this operation is delayed — it’s not delayed, it’s very quick

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.

OnOff
NarsilMRelease-onRelease-off
AndurilPress-on (moon), Release-on (mem)Delayed-off
Mike C UIDelayed-onDelayed-off

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

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

Agro wrote:
With e-switch lights I use physical lockout a lot.

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) ?
Agro
Agro's picture
Online
Last seen: 59 sec ago
Joined: 05/14/2017 - 11:16
Posts: 4550
Location: Ślōnsk

Mike C wrote:
Agro wrote:
With e-switch lights I use physical lockout a lot.

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.

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

ToyKeeper wrote:
These look really interesting. I don’t have any tiny1634 drivers yet, but I hope to add support for them sometime.

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.

ToyKeeper wrote:
Something I’ve found useful to make configuration easier is context-sensitive config menus. Basically, attach a short config menu to each configurable mode.

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.

ToyKeeper wrote:
In case anyone wants a quick way to calculate evenly-spaced mode levels, I made a ramp calculator script… No need to configure each level individually, and no need to include hardcoded mode groups in the firmware.

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.

ToyKeeper wrote:
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.

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.

ToyKeeper wrote:
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.

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…

ToyKeeper wrote:
Mike C wrote:
10 bit fast PWM, the lowest usable value is 5

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?

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.

ToyKeeper wrote:
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”?

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.

ToyKeeper wrote:
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.

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.

ToyKeeper wrote:
Mike C wrote:
I use an UI with two modes, normal and turbo. Short tap alternates between the two, long tap in normal mode enables ramping. When ramping is enabled it’s short tap to ramp up, long tap to ramp down. Tap again to stop ramping.
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.

Yes, it’s OTSM makes this possible. With OTC it’s very difficult to get consistent results while detecting multiple off press durations.
Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

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

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.
MascaratumB
MascaratumB's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 10/29/2016 - 12:12
Posts: 4068
Location: Portugal
Mike C wrote:
ToyKeeper wrote:
I’m also not sure what to call the UI Mike C created. Does it have a name?
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 Cool
[it gathers several UIs at the same table driver and only Mike rules them Big Smile ]

[REVIEWS] AMUTORCH: S3 / S3 vs 219c / AM30 / AX1 / VG10 /// SOFIRN: SF14 + SP10A / SP32A / SP10B /// NITEFOX: UT20 / ES10K / K3 /// ODEPRO: KL52 / B108 /// ACEBEAM: H20 / TK16 /// BLITZWOLF: BW-ET1 /// DQG: AA Slim Ti /// HC-LIGHTS: SS AAA /// XTAR: PB2 Charger /// OLIGHT: M2R Warrior /// WUBEN: TO10R / E05 / T70 / E10 /// ON THE ROAD: M1 / i3 / M3 Pro /// ROVYVON: A2 + A5R / E300S / A8 /// KLARUS: XT1C /// LUMINTOP: Tool AA V2.0 + Tool 25 /// LIVARNOLUX: 314791 /// SKILHUNT: M150

Tricks: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 /// TIR Lenses: 1 / 2 /// Others: Biscotti 3 + 1*7135 / Triple TIR w/ XP-G2 ///// My Collection ///// My Review's Blog (PT)

GIVEAWAY: 1

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

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.

MascaratumB
MascaratumB's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 10/29/2016 - 12:12
Posts: 4068
Location: Portugal
Mike C wrote:
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

[REVIEWS] AMUTORCH: S3 / S3 vs 219c / AM30 / AX1 / VG10 /// SOFIRN: SF14 + SP10A / SP32A / SP10B /// NITEFOX: UT20 / ES10K / K3 /// ODEPRO: KL52 / B108 /// ACEBEAM: H20 / TK16 /// BLITZWOLF: BW-ET1 /// DQG: AA Slim Ti /// HC-LIGHTS: SS AAA /// XTAR: PB2 Charger /// OLIGHT: M2R Warrior /// WUBEN: TO10R / E05 / T70 / E10 /// ON THE ROAD: M1 / i3 / M3 Pro /// ROVYVON: A2 + A5R / E300S / A8 /// KLARUS: XT1C /// LUMINTOP: Tool AA V2.0 + Tool 25 /// LIVARNOLUX: 314791 /// SKILHUNT: M150

Tricks: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 /// TIR Lenses: 1 / 2 /// Others: Biscotti 3 + 1*7135 / Triple TIR w/ XP-G2 ///// My Collection ///// My Review's Blog (PT)

GIVEAWAY: 1

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

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.

MascaratumB
MascaratumB's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 10/29/2016 - 12:12
Posts: 4068
Location: Portugal

Mike C wrote:
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 Thumbs Up

[REVIEWS] AMUTORCH: S3 / S3 vs 219c / AM30 / AX1 / VG10 /// SOFIRN: SF14 + SP10A / SP32A / SP10B /// NITEFOX: UT20 / ES10K / K3 /// ODEPRO: KL52 / B108 /// ACEBEAM: H20 / TK16 /// BLITZWOLF: BW-ET1 /// DQG: AA Slim Ti /// HC-LIGHTS: SS AAA /// XTAR: PB2 Charger /// OLIGHT: M2R Warrior /// WUBEN: TO10R / E05 / T70 / E10 /// ON THE ROAD: M1 / i3 / M3 Pro /// ROVYVON: A2 + A5R / E300S / A8 /// KLARUS: XT1C /// LUMINTOP: Tool AA V2.0 + Tool 25 /// LIVARNOLUX: 314791 /// SKILHUNT: M150

Tricks: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 /// TIR Lenses: 1 / 2 /// Others: Biscotti 3 + 1*7135 / Triple TIR w/ XP-G2 ///// My Collection ///// My Review's Blog (PT)

GIVEAWAY: 1

DavidEF
DavidEF's picture
Offline
Last seen: 11 hours 10 min ago
Joined: 06/05/2014 - 06:00
Posts: 7635
Location: Salisbury, North Carolina, USA

MascaratumB wrote:
Mike C wrote:
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 Thumbs Up


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

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

DavidEF wrote:
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 Blushing

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.

DavidEF
DavidEF's picture
Offline
Last seen: 11 hours 10 min ago
Joined: 06/05/2014 - 06:00
Posts: 7635
Location: Salisbury, North Carolina, USA

Mike C wrote:
DavidEF wrote:
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 Blushing

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. Facepalm

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

DavidEF wrote:
I hope you know I said that in the most lighthearted and not-pushy way possible.

Yep, I got that. I didn’t interpret your post as being even remotely pushy.
Tom E
Tom E's picture
Offline
Last seen: 5 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 12251
Location: LI NY

ToyKeeper wrote:
Tom E wrote:
calling a press&release a delayed on implies this operation is delayed -- it's not delayed, it's very quick
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?

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

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

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:

pc_light wrote:

  • Also the recent adaptation of a wave-like cycling of fixed step levels would be nice, L-M-H-M-L… (as an alternative to the traditional method of cycling of L-M-H-L…)

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?
Tom E
Tom E's picture
Offline
Last seen: 5 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 12251
Location: LI NY

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

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

Tom E wrote:

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.
Tom E
Tom E's picture
Offline
Last seen: 5 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 12251
Location: LI NY

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

pc_light
pc_light's picture
Offline
Last seen: 2 days 10 hours ago
Joined: 03/24/2017 - 16:19
Posts: 314
Location: United States

Mike C wrote:

pc_light wrote:

  • Also the recent adaptation of a wave-like cycling of fixed step levels would be nice, L-M-H-M-L… (as an alternative to the traditional method of cycling of L-M-H-L…)

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?
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.

Seeking the light.

Mike C
Mike C's picture
Online
Last seen: 11 min 42 sec ago
Joined: 01/22/2014 - 08:03
Posts: 2342
Location: Sweden

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.

Agro
Agro's picture
Online
Last seen: 59 sec ago
Joined: 05/14/2017 - 11:16
Posts: 4550
Location: Ślōnsk

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.

Pages