I've gotten so used to A-2 now, I gotta stop and figure out things on regular Anduril. I didn't check yet, but did you use the latest Anduril2 base?
Only one beer so far :BEER:
Well, I just branched TKās code this afternoon so hopefully itās the latest.
Truthfully, none of my changes are to Anduril(/2) itself, just to the spaghetti-monster code.
Is there a compile flag for this? Iām really missing the 2C for Turbo. 
I fully understand this for the Simple UI, but not so much for the Advanced UI.
Yes you can enable this with:
#define USE_2C_MAX_TURBO
It's called out in ramp-mode.c for event==EV_2clicks.
Actually I added it, TK liked it, and dropped it in her code base. All good!
She also went with my changes with 3C --> voltage, then temp, then other blinkies. She also implemented the voltage calibration I came up with, but of course hers is better, actually more complete - I didn't add provision for calibrating the voltage divider voltage reading.
Great, thanks guys!!
Thanks for your contributions Tom E and gchart!
Alright I was able to implement it... I called it 'beacontower_mode', and I put it into the same mode group as the regular alpine beacon and SOS. Seems to work pretty well but can definitely be fine tuned. The mode conjured up images of distant towers with these red beacons across a desolate landscape; somehow an intriguing idea..
Quick Preview:
Would definitely look better if it were red / amber/ very warm white.
Beacontower mode has similar control as the regular beacon mode where you can change the period of the flashes with the default being the standard 30 FPS. Brightness used is the memorized level. One side effect of how the brightness ramp is controlled, is that the more the brightness, the longer the ramp up and ramp down time takes, to emulate the filament heating up and cooling down.
I actually had to change a lot more code than I thought, since each of the different modes c file had to be changed for each of the (event == EV_2clicks) handler.
- Added beacontower-mode.c/.h
- battcheck-mode.c
- beacon-mode.c
- sos-mode.c
- tempcheck-mode.c
I also added a flag USE_BEACONTOWER_MODE, a call to the beacontower_state_iter(), and preprocessor macros in main.c. I see why you like it; it's quite pleasant to look at actually especially with a diffuser dome.
/*
Beacon-Tower mode:
Similar to Beacon, but emulates the gradual turn on and off of traditional
large incandescent bulbs of obstruction/beacon towers. The brightness and
the flashes per seconds (FPS) are configurable, with the default being the
standard 30 FPS, with roughly 50% duty cycle (slightly more for On).
- Brightness is the user's last-ramped level, so set this in
ramping mode before starting beacon mode.
- FPS is configured by holding the button. The light will blink
once per second while holding the button. Release it after the
desired amount of time has passed, to set a new beacon flashing
interval.
For example, to set a 5-second interval , hold the button for 5 seconds.
Suppose the period of the light is set as t seconds:
- Turn on ramp = nominally ~t/8s at ramp level ~60.
- On at full brightness = 7/16*t s
- Turn off ramp = nominally ~t/4s at ramp level ~60
- Off = 3/16 *ts
Increasing the brightness also increases the time taken to ramp up
and down, just like an incandescent would.
Access from blinky / utility modes; the sequence is:
- Battery check.
- Temperature check (if light has a temperature sensor).
- Beacon mode.
- SOS mode (if enabled).
- Beacon Tower mode (if enabled).
*/
This was fun; tempted to add more fun modes but this can get out of hand real quick.. also now that I have written the code, maybe I should rename it to obstruction beacon instead of beacon tower.. oh well.
Thanks to sunsethiker for the suggestion and https://www.youtube.com/watch?v=IBk_2lZwiBA&t=76s as the video reference. I should really familiarize myself with TK's repository to add the changes in properly.
Good job! The most logical consequence seems to be the move the state change handler into a separate function that is called in each blinky mode. Should be a rather easy refactoring. Also the iter functions could be called in a generic way (store a pointer to the function in a variable that is called in each loop, depending on the currently active mode).
One change thatās different from Anduril 1 is that unlocking turns the light on, and there didnāt seem to be a way to change that without modifying code.
I saw some basic conversation around unlock-to-off in the thread, with the workaround being turning it on and then quickly turning it off. The below seems to be a very basic way to allow people who can currently flash their lights to change it with a config change, and not a code change.
~mkong1/flashlight-firmware/anduril2 : revision 580 allows a basic config change at compile time to revert back to unlock-to-off behavior of Anduril 1.
I think itās something that might be useful in the UI, but only if itās a common enough to warrant it, which Iād be happy to tackle as well. I personally like unlock-to-on better, and i can only imagine people being in one camp or the other, and not really wanting it to be different between their lights.
At least 4H restores it to the lowest level and not memorized level, but yes - Anduril 2 stock always restores it on. I find using the 4H method to wake it up to be better.
I hope someone answers this question. My D1 has the same flashing pads as my D4V2, and there is no other adapter listed on Hankās website, so I just āassumedā the adapter was the same. Now Iām not so sure. I would like to flash all my lights with Anduril 2
I don't own a KR1 or D4V2, but if the pins are in the same position and labeled the same, then yes - should be compatible.
Here he lists the D4V2, D4SV2, and the KR4, but there are more Hank lights compatible with it, like the K1 and K9.3.
Late D1 were shipped with the D4v2 driver and need the D1v2 firmware. Adapter is compatible.
My D1 was one of the last ones. My K1 also has the same pad config so I assumed compatibility also. I also noticed a friends D18 didnāt have pads. Wonder about the newer D18 lights.
I used Anduril for a long time and used Anduril 2 for a short time.
What I am find is that 1C in turbo brings me to the used level before instead of turn off the light would be better.
Amutorch used this and it is very usefull.
My Anduril 2 for a 1C in turbo always turns the light OFF. I am using the USE_2C_MAX_TURBO setting though, and advanced mode.
2C = Turbo
From Turbo 2C = back to before Turbo.
I find 2C to go in Turbo is ok but back would 1C be better.
I used turbo mostly only for a few seconds to look further and go then back.
So 1C to go back is for me better because I never go from turbo to off.
Is it possible to rewrite this myself? And how?
Ahh, ok. I actually prefer if it would work as you describe. Yes - it seems like most other lights with the 2C to turbo use 1C to restore to previous level, and I like it that way. For walks it makes perfect sense - briefly make it daylight, then back to normal.
Hhhmmm, gotta check if there's a compile switch setting for this already. If not, I should add one 
. let me take a look...
There isnāt ā and actually it might be good to have 1C to go back to previous level. Then it would be possible again to have the two-step current ā ceiling ā turbo.
something + 2C ā ceiling (āmoreā)
ceiling + 2C ā turbo (āmoreā again)
turbo + 2C ā turbo (again, in case of thermal throttling)
any + 1C ā previous level
Downside: You canāt turn off the flashlight from turbo anymore.
edit: Done. [WIP] Return from turbo with 1C instead of 2C Ā· SammysHP/flashlight-firmware@481f6e8 Ā· GitHub