Yep, that is a good point. You would be expecting turbo, but it wouldn’t be pleasant to ‘fake strobe’ to get the mode back to normal.
You are pretty much understanding. You hold for a spark. It starts glowing, you release. While still glowing you start a hold again, and the ramp immediately starts. Reverse ramp would be another release and hold within a timeout. Delay too long and it results in a new spark as you point out.
If the light is on, the cue is to ‘buzz’ the main emitter which is just a high mhz strobe at whatever brightness you are at. Not blinding, since the light is already on at a comfortable level. If the light is off, the cue is a 1 lumen buzz of the main emitter. If you want moon mode, you look at the main emitter, hold for spark, and release once you see the 1lm glow buzz. Now just point away and click and moon turns on. If you want turbo from darkness, don’t watch for the buzz, just point the light in a safe direction and keep holding until it flares up.
This is a good point and I would need to clarify the diagram with the intention of the “spark keep holding” is for momentary turbo, with a return to off/last level when you release the hold.
This means turbo is accessible in your scenario from a simple keep holding. Turbo would also be accessible from the top of the ramp if you wanted it to stick.
I’m holding my meteor right now in UI1. A 6x click attempt to lockout from off, as fast as possible, results in a power on to low with click 1, raise to medium with click 2, turn off with click 3, and fortunately the remaining 3 clicks do nothing, and then the double flash confirmation.
In a tactical situation, the unintended powerup to low then medium would not be an acceptable intended consequence; we are trying to protect the light from inadvertent activation, what if safety is at stake? What if your position is revealed to the enemy?
Lets say you are SAR in a vehicle with other SAR responders, At best they might wonder why you are making your flashlight shine at them. At worst you might stun/blind their night vision when they critically need to see a patient.
Just to turn on lockout!
Obviously these are fictional scenarios, but not unrealistic. Hopefully this helps point out that this aspect is not about taste, but that a very predictable way to engage a lockout with no side effects of other UI functions can help elevate the professional application of a flashlight.
so what speaks against flashing the meteor with latest FSM firmware?
Lockout on NarsilM or FSM was always good as I can remember, the turbo flash of Narsil v1.1 was not nice getting there
It’s the PCB / driver architecture which is based on this schematic:
The gist of that schematic is:
Boost-Driver with the FET controlled by PB1
Current-Feedback with differential measurement over 0.0026 Ohm (4x 0,025 in parallel) on PB3 (low side) + PB4 (high side)
Button on PB5, LEDs on PB0, PB2 and PB5
Since PB5 is used, it can only be programmed once with our typical ISP and needs HVSP after that.
The biggest hope seems to be a new high-current boost driver which has an arrangement like the BLF GT where the uC just has to provide one or two setpoints.
I would say that having complex state is not problematic; problems arise when the complex state requires complex interactions. For example, changing biscotti/bistro options is a complex state, but interaction is easy (just turn off at right time). If you had special click pattern inputs to move forward and backward in the menus and button click patterns to set options, it would be ridiculously difficult.
I love the M43 e-switch LED visual cues. Pretty much inspired the idea of using visual cues as a way to “talk” to the UI and to precommunicate your desired output level/pattern all before igniting the main emitter.
Yes, that is the Meteor firmware. My point is that most BLF firmware are not like that, I think what you are asking for in terms of multi-clicks is already done. I could be wrong though, I’m only assuming really.
My point was that if I miss to release the hold after the 1MHz buzz in time I will suddenly get blinded by the lamp in turbo. With e.g. Narsil I would end up with the lamp beginning to ramp up from moon mode which isn’t that bad.
I see. How long would it take to get there? Also: When I initially ramp the light up to a comfortable brightness, how long will the delay be after which the next hold results in a new spark instead of ramping up/down? Say the delay is 1 second: That also implies that to change brightness after 0.9 seconds (before the delay ended) would require a different user input than after 1.1 seconds (after the delay ended). I have to say, I am not a big fan of such time-based decision making. My Klarus light has an outdoor mode where when you press and hold the secondary switch for under a second it is momentary on but if you hold it for longer than that it stays on. And I really hate it with a passion as I never know what will happen when I release it.
In UI design you also have the concept of not breaking with conventions when designing UIs (search for UI design conventions but I think you know what I mean). Double clicking a side button from off in many flashlight UIs often results in constant turbo mode, sometimes strobe, holding from off in starting in the lowest mode. Again, I don’t think it has to be this way but it could potentially confuse people when they double click and end up with a light that turns on and then off again. Maybe I am wrong and there aren’t even enough UIs like that out there to call those behaviours conventions but I think it’s still a point worth mentioning.
See e.g. this manual from an Olight model:
Do you encounter this type of situation often? And if so, do you use flashlights which were designed for other situations?
It’s one of the most common UI designs. A while back, I did an informal survey of the world’s major flashlight forums to get information about what people consider to be the ideal UI for a flashlight with a single e-switch. What I found was that people everywhere wanted pretty much the same things…
From off: Immediate access to moon, mem, and max.
While on: Quick ways to turn the light off, change brightness, and shortcut to/from turbo.
More specifically, people in many places described almost exactly the same interface:
From off:
Click for mem.
Hold for moon.
Double click for max.
While on:
Click for off.
Hold to change brightness.
Double-click for turbo.
This convention is even found in other industries, like on fancy light switches to control room lighting… though on those there isn’t a turbo function.
For other functions, like blinkies and lockout, the details vary a lot more. But the basics listed above seem pretty universal as far as I can tell.
Mike C is not wrong. To make a UI which waits until all clicks are completed before it lights up, the only thing necessary would be to comment out a few bits of code in Anduril. It has early-feedback clauses which could easily be removed to make it not respond until all clicks are complete. It also has confirmation blinks which could be removed to let the user enter lockout without blinking.
Or for tactical purposes specifically, you could use it on a light which has a rear clicky switch in addition to the side e-switch. There’s a compile-time option for this which makes it turn on at the memorized level any time the rear switch is on (or at moon if the e-switch is down when the rear switch is pressed). This effectively makes the rear switch work as a dedicated button for latching momentary purposes… which, if I understand correctly, is generally what tactical folks want.
To access other functions in that setup, turn the rear switch on, and then the e-switch can be used for other things. Like, to get to battcheck, turn the light off with the e-switch and then click it 3 times. It can effectively still function as an EDC light whenever the rear switch is on, but the tactical interface is always available on the rear switch.
+1 with TK on the surveyed UI preferences. That's pretty exactly what we did in Narsil ramping based on many, many inputs coming on the Q8 thread. I don't see any reason to stray from that, though there are some variances in implementing it, plus variances with the many additional accessible features.
I found personally under stress, the dbl click did not come to me naturally - I'd prefer a 2nd button perhaps, dedicated as momentary full power (on when held). Ideally with a 2nd button, you could make it programmable to how you want it to behave, all depends on one's usage (momentary, strobe, candle, etc.). Ideally you don't want to get into multiple flashlights for different functions. Still look'n for a good larger EDC e-switch (Narsil/Anduril) zoomie (flooder and throw), but it will never compete on raw flood output of the 3x to 9x LED lights out there now.
If “under stress” refers to an active / ongoing attack, your response should probably not be the turbo mode but either off+running away (flight) or a trigger pull / hit / punch (fight)…
Turbo mode is somewhere at the bottom of useful things to do when you are getting attacked.
But to go back to a better discussion: A possible, but still distant idea for your powerful zoomie could be something like:
GBX20 driver (with mods for the eSwitch)
Anduril with patches for the ATTiny84 and digipot used
No, stress was this situation: I had a Q8 in my hand, we heard a crash at the end of the block, then a SUV went speeding up the block past us and I wanted to catch the license plate #. So stupid me, my reaction was not dbl click, but all I could think of was ramping up and by the time it ramped up, it was too late - the SUV was too far away up the block. This guy was hauling...
More info on the incident: turned out there were 3-4 young kids (ok, maybe 17-18 yrs old) in a car, they played the game of knocking over fence sections (been a popular thing in my town), the home owner jumped in his SUV and chases them, the kids of course were look'n to get away and mistakenly drove down our dead end block, crashed into a parked car in a driveway at the end, the home owner in the SUV did not want to stick around I guess, but all this came out later after the police arrived, etc.
Anyways, yes - the problem is the host. All our past better/great zoomies like the 1504 (big carry) or B158 or Z1 are tail power switches.
Don't get me wrong, I'm a dbl click turbo proponent, but for some reason it just could not happen under some stress, weird as that is because I can't quite explain it. Maybe I just don't use a dbl click enough so it's not a muscle memory sort of thing.
Guess if we had cows in our town, these kids would have been out cow tipping, but fences are everywhere...
My idea of a perfect UI is one that covers only the features I use and want (and omits everything else) in a way that makes sense and comes natural to me as an individual. This is the reason why I asked earlier about whether there are projects out there, where a (non-enthusiast) user can easily click/drag/whatever together their UI and use it with their flashlight.
Our current UIs try to do everything and make the most popular features as easily accessible as possible. There is nothing wrong with that and it works reasonably well for a majority of people and good enough for most others.
I simply think that giving people the choice to really only put the things they need into their UI would be an even better approach. There are people out there who only want their lights to be able to do 1 or 2 modes and nothing else. Or don’t have any blinkies. Or be used as a bike-only light with only 2 output modes + 1 bike blinkie. I for example hate mode memory with a passion especially on lights with side AND tail switches for the tail switch (mode memory + last used mode results in TACTICAL MOONLIGHT 50% of the time when I want to check out what’s going on in the distance). Some people might not want to use the side switch of a dual switch lamp, some might not want to use the tail switch. Some organisations might want to equip their staff with flashlights which are streamlined for their daily use cases and configure every light the same way so they can be exchanged within the organisation (every light withing the organisation operates the same way).
Some of those things are already available in some modern flashlight UIs via settings, but being able to freely rearrange and reprogram is, to my knowledge, not possible.
Yes, you can write your own UI and flash it onto lights that support it, but let’s be honest: This is nothing a normal user would ever consider. It’s an enthusiast-only thing. I think the functionality described would be a natural extension of what we currently have: Shipping flashlights with a very good and useable default UI that people can completely reprogram and redesign as they like (and reset to it if they mess up). I think an intermediate step is what TK already said: Making firmware flashing as easy as possible. This way people can at least easily choose between already existing UIs. We can then maybe code something that generates firmware from simple user inputs which the user can then deploy on his flashlight himself. That’s kind of my vision for/what I would like to see in the future.
Hi TK, I’m sorry if this is a dumb question, but is there a changelog for the D4S (or all Emisar…) builds of Anduril on your site? I’m not much of a programmer and I have trouble following along in this thread, but I’ve been flashing Anduril to my Emisar collection for the past several updates, just wondering what’s new. Thanks!
