Well, that makes a lot more sense.
I’m still not sure what is better.
Hold for turbo / momentary turbo or hold to ramp…
But your argument for hold-to-turbo is very practical.
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... 
I have to admit that story made me smile a little. 
Who came up with a double click to turbo in a Q8 anyways :person_facepalming:
+1 With TK and TomE
Edit- Not 100% I guess, I think the clicks should be the same from off or on.
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.
Cheers
My project My Quest for the perfect EDC user interface. (E-switch)
Feedback on special modes Special Modes/Functions. Which ones and why??
Feedback on LOW modes. How low ? How often? How come?
Feedback on Usage patterns Do you charge more, or change lights for flashlight season?
Feedback on driver setups What is smarter choice. Number of 7135s
The way I imagine my ramping functions, it could be possible to add or remove functions/blinkies or just never activate them.
This project is a long ways out.
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!
Sorry, there isn’t a change log for specific builds, or for the builds in general. However, there is a commit log in the code repository, mostly the fsm branch. The dates there and the dates on the builds should mostly match up, to give an idea what is different in each build.
That’s perfect, thanks!
I was laying out a 3ch driver today following the TA circuit diagram and I realized there’s no provisions for an AUX LED on his 3 channel boards. Do any current builds of anduril handle 3 channels (1+8x7135+FET) plus AUX LED? If so which driver is it or which pins are which?
My lexel TA driver with NarsilM has aux switch led, so I know there is a 3 channel board with aux support. I am not sure about Anduril thooo sorry.
Ok so I believe I’ve answered my own question browsing code but please correct me if I’m wrong…
I can use the ROT66pin layout;
1x7135 on pin5
8x7135 on pin 6
FET on pin 3
Switch to pin 2
AUX LED on pin 7
Internal voltage reference only
That right so far?
This is what I've done for NarsilM - use AUX LED on pin 7 since many times it has the voltage divider pad. Sometimes I've had to wire up a pin #3 to an MCU pin. I'll use 30 AWG wire and solder the wire so the wire lead lays over the MCU - found I can still clip it for programming this way - it's worked every time for me. I'm sure I got pics some where...
Ahh, here for an ZY-T11 clone:
85 with bent pins, air wired LED resistor, LED mounted on the grnd ring to align to a light pipe.
lately I've been using TA triples but as FET+1's. The latest NarsilM v1.3 has this capability. I don't have many eagle claw 7135's left, and no decent source to get them from. Last time I used a Lexel recommended source, they came in as the wrong type after getting assurance from the seller they were eagle claw. Got a full refund but still leaves me with no source.
I just watched a video of a guy cracking nuts with a SS Zy-t11.
Was that you Tom.
Yes, Anduril supports a 3-channel board with aux/button LED. It just needs a hwdef file to specify the pin layout and a cfg file to specify the UI options. Normally the aux LED goes on pin 7 in this setup, and it uses VCC to measure voltage instead of a divider.
Also, Tom, that is some really impressive soldering skill. I don’t know how you can get such small parts to be so precise.
Thanx! That was done when I was young, well under 60...
Hello,
first sorry, I didn´t read complete Thread 
.
I read at TLF, that Andúril should work on Emisar D4s.
What´s about the AUX LED configuration.
Original Firmware on Emisar D4s is Ramping IOS V3.
7 clicks to change option for AUX LEDs.
Is it in Andúril also possible to change the AUX LED brightness?
thanks.
Yes it works, I have it on two D4S’es
The same 7x click on Anduril. On the D4S the modes are: OFF - LOW - HIGH - PULSE
Hi,
thanks a lot.
Thats sounds good.
So a colleague can flash my seven D4s´ for me ;).
Is there a complete chart, showing all functions and programmable options for Andúril, available?
I´ve only found this:
Thanks.
That IS the complete function chart
Only thing missing from there is the AUX-7x click stuff. for AUX enabled lights.
There is a compete text version here if there’s something you are unsure of 