I forget; do you have firmware flashing tools? If not, it might be a good idea to get some. I think you would probably enjoy being able to tweak behavior exactly how you like it. At minimum, it would give you access to change compile-time options, but you could probably make deeper changes too.
Itās not something I recommend for everyone, but I think youāre probably serious enough about lights to get some benefit from it.
They are on the way.
I went for a two hour hike last night with a friend and five flashlights running AndĆŗril. Two Q8s, Emisar D1, Emisar D4, and EagleEye X6R.
My friend was very impressed with the Q8 and got the hang of ramping very quickly. It was fun to keep handing him lights to try without needing to explain a different UI with each one.
I set the ramp ceilings to turbo-1 for all but the D4, which I set to turbo-55. He ramped the D4 to the ceiling and said, āWow!ā I told him to double-click and he about fell over. :laughing:
Is there a way to set AndĆŗrilās ramp ceiling to turbo, or is turbo-1 the max value? Would this be a compile-only option? What if the ramp value was set to āturbo-(N-1)ā instead of āturbo-Nā when using ramp config? Must ramp ceiling and turbo remain non-equal?
BTW, dual-switch support seems to work great. I really like the āhold e-switch and click tailswitchā to override memory.
I find this AndĆŗril more and more interesting. I need to build a triple or quad X6R and try it in that. Or in my Q8 if it ever reach me from china. Ordered it in the first 100 and Iām just waiting and waiting patient.
It already does āturbo - (N-1)āā¦ or, more specifically, ā151 - Nā. I should probably update the UI diagram to make that more clear.
To check whether the ceiling is set to turbo or if itās lower, double-click from off, then double-click again. If it goes up, they werenāt equal. 
Got it! I was worried about missing out on that one last ramp level.
BTW, your UI diagrams are works of art in their own right.
I need to stop adding thingsā¦ I have no idea how to fit them into the diagram!
Specifically, muggle mode. Itāll probably need a whole new section, but thereās no space left on the page.
Iām thinking 6 clicks from off to enter muggle mode, or 6 clicks from ramp to enter muggle config mode. Settings include floor and ceiling levels only. Will probably default to floor=15/150 (~7 lm) and ceiling=100/150 (25% power). Ish. Not sure if Iāll try to fit a 4-bar battcheck mode into it or if itāll be limited to just ramping.
This sounds great! No turbo for muggles, right?
I vote to omit battery check, or make it a compile-time option. I can already hear my button-mashing friendsā¦ āWHYāS IT BLINKING?!ā :person_facepalming:
Speaking of muggles, it seems the first thing they do when I hand them a new light is unscrew the tailcap to look at the battery. Iāll have to let them get that over with before I enable muggle mode.
I know this, I have the same problem with Tom and the NarsilM cheat sheet.
TK, Iād like to shorten (nearly eliminate) the delay before ramping when holding the switch from off. I want ramping to start almost immediately.
I poked around in several of the .c and .h files but couldnāt determine where I should make changes.
Could you point me to the code I would need to modify to accomplish this? Thanks!
Ramping starts after 48 frames by default. The first 24 frames allow for a regular click to happen (instead of holding to ramp). The next 24 frames are the window for long-press-for-moon. After that, ramping starts.
Look for EV_click1_hold in off_state, and remove the part about āif (arg >= HOLD_TIMEOUT)ā. This should make ramping start about 24 frames sooner. However, it will also eliminate the ability to long-press from off to go to moon.
You could also try reducing the value of HOLD_TIMEOUT or the value of RELEASE_TIMEOUT to speed up the entire interface, but itāll mean less time to do each click.
Or you could even make it start ramping before it hits HOLD_TIMEOUT, but that will also eliminate the ability to do any clicks of any type from off, unless youāre clever and do some much bigger changes.
If I recall correctly, the way Narsil does it is somewhat different:
At least, if Iām reading the code correctly.
In Anduril the sequence is:
Eliminating the pause at step 2 is easy. Eliminating or reducing the pause at step 1 is not so easy.
Iāll try this. Thanks!
I use low modes frequently, but I might be willing to lose a shortcut to moon to get a slightly shorter delay in ramping up from off.
You could also just give it a smaller value, like 6 to allow a 6-frame window to stop at moon before ramping.
And to make the timing easier, you could make it not turn the light on until that window starts. Slower feedback from off, but it gives a timing hint for the shortcut. Tradeoffsā¦
I tried a few different values for HOLD_TIMEOUT in fsm_events.h on two Q8s. Here are my findings:
12 it is! Ramping feels much snappier from off.
Thanks again for the help, TK!
It runs at 62 frames per second, or 0.016 ms per frame. So a value of 12 is just barely under 1/5th of a second.
People have had difficulty with a window of 18 frames on the Q8, and Iāve found that 31 frames feels too long, so I used a default of 24.
Zebralights, IIRC, use a window of 0.5s or 31 frames:
Anyway, I just wrapped the definitions of HOLD_TIMEOUT and RELEASE_TIMEOUT to make them definable from the UI code instead of having to dive into headers. So, after this update is pushed, just stick an extra line in the main UI file and itāll override the toolkitās defaults.
The HOLD one is how many frames it takes to go from a āpressā to a āholdā, or how long a single click can be. The RELEASE one is how many frames it waits after a click to see if another click will happen. To cause a full click event to be sent to the UI code, what happens isā¦
The events arenāt quite immediate thoughā¦ they go into a queue and get sent/processed later when the MCU is in an idle loop. In normal circumstances, this only delays things by a few microsecondsā¦ enough for the current interrupt (WDT, PCINT, ADC) to finish. Iāve generally been very careful to avoid anything time-consuming during interrupts, because those need to be serviced quickly and then go back to the regular code flow as soon as possible. The queue offloads the time-consuming parts to a safer part of the code.
Iām kind of just rambling now though, twiddling my thumbs while waiting for DHL to show up with new lights.
Thank you for the detailed explanation.
With HOLD_TIMEOUT set to 12, I was having an issue where a hold while on would do nothing. Iāve changed the value to 15.
And please make the battery insertion double blink at moonight.
Yeahā¦it bothers me too. As well as voltage / temperature indication.
Hang on there a minute. On a bright sunny day blinking out temperature or voltage might be rather hard to see if done at moonlight levels. At the risk of adding ANOTHER configuration, it might be nice to be able to select the intensity of these blinks.