Yes, and it’s often not up to date with the code. Thanks for the help spotting those parts.
I updated the bits you pointed out, and a few others while I was at it… it should be in the next revision.
1 Thank
After having used it a bit, I am in doubt whether the 3 seconds voltage aux led after switching the light off is a good thing. Yes, one gets the impression that this is a good info for the user. But there are a few cons as well: 1) if the light had been on, the voltage indication for 3 seconds after switching the light off does not tell me much. The battery recovers, and before any kind of realistic battery status is reached, the voltage indication has already shut off. 2) as said before, in case I have the aux leds on in high level and with disco or rainbow pattern, in OFF or in LOCKOUT mode, I can hardly say what aux light color at how many seconds or fractions of seconds after having switched the light off tells me what. A bit confusing then.
There are Pros as well. I find it is a good help if, for example, the light had not been on, it may be in LOCKOUT status, with aux leds off or blinking. 1C puts “moon” on and off again, and then it shows the voltage for 3 seconds. That’s nice.
Maybe it would be a good idea to make this 3 seconds voltage thing so that one could choose if activated or not? That, I think, would make it more useful. This option then for OFF and also for LOCKOUT?. OK, I can’t say whether the effort to create this stands for the advantages it might have. Just brainstorming.
1 Thank
I have a D4SV2 Dual Channel and a DM1.12 which both blink model 0136. Can I use this hex or one of the ones published for these?
I am using the file above for my KR4 Dual Channel and my D4V2-Cu Dual Channel, both are model 0135, and both seem to work fine with it.
I haven’t converted that build yet. 0136 is the “tintramp-fet” build, which is a little odd and needs some changes to make it use the DD FET.
0135 is the emisar-2ch build, with two regulated channels controlling different sets of LEDs.
0136 has 2 sets of LEDs and 3 power channels… it’s like the emisar-2ch build, but with a DD FET adding turbo modes to one of the two sets of LEDs. You could use the 0135 build on it, but you would lose the extra turbo brightness.
I’ll give it a runtime config option eventually… I just haven’t yet. It occurred to me that I could put it in the battcheck menu to make it easier to remember and keep it out of the cluttered and confusing “misc” menu.
3 Thanks
Finally got round to doing some testing and hacking on it… really like the changes so far, especially being able to define arbitrary channels. Wrote a few basic channel mix algos to test, made a custom build. Tried to get the D4S-specific build working but so far only partly works.
My findings so far:
-
CHANNEL_MODES_ENABLEDshould beuint16_t(maybe even 32?) - 2 channels plus all aux modes is 9 on its own, then with modes to ramp between the two etc… 8 isn’t really enough. - Voltage shouldn’t be displayed using the aux after changing aux mode/brightness (“wait, did I hit the wrong mode?”)
- 3H for turbo on channels without args is… “ouch, my eyes”. See also below.
- On a channel that doesn’t have any args (e.g. single LED set), I’d rather 3H doesn’t do anything - I changed it so instead of turbo, it will occasionally
blip()in that case to remind myself of that (also helps with “wait, which channel am I on right now?” without waiting for what may be dissimilar LEDs to ramp). - When cycling through channels to use, I still think both, auto, and ramping modes need some way to visually distinguish between them when they come up.
I haven’t hacked on most of these yet except for replacing 3H turbo with a reminder, but if I come up with something great I’ll post it. Turbo code in my ramp-mode.c:
else if ((event == EV_click3_hold)
#ifdef USE_CHANNEL_MODE_ARGS
|| (event == EV_click4_hold)
#endif
) {
// ramp tint if tint exists in this mode
if (event == EV_click3_hold){
if(channel_has_args(cfg.channel_mode)) {
return EVENT_NOT_HANDLED;
}
#if defined(USE_CHANNEL_MODE_ARGS) && !defined(USE_3H_CHANNEL_RAMP_TURBO_FALLTHROUGH)
//don't turbo on 3h
else {
if ((arg % 32 == 0)){
blip();
}
}
}
else {
#endif
if (! arg) { // first frame only, to allow thermal regulation to work
#ifdef USE_2C_STYLE_CONFIG
uint8_t tl = style_2c ? MAX_LEVEL : turbo_level;
set_level_and_therm_target(tl);
#else
set_level_and_therm_target(turbo_level);
#endif
}
return EVENT_HANDLED;
#if defined(USE_CHANNEL_MODE_ARGS) && !defined(USE_3H_CHANNEL_RAMP_TURBO_FALLTHROUGH)
}
#endif
}
Another idea, maybe a little harder to implement in a way everyone would be happy with but something I’m probably going to do, is a way to jump back to the first channel and/or go back a channel. I find that above 6 modes or so, it gets a little hard to keep track of which is which unless you memorise a sequence that might be different for every light, and gets annoying accidentally scrolling past one.
PS. I know you’re probably really busy, but whenever you get a chance, check DMs, have something you might be interested in.
Edit: Found a bug too. When changing channels for blinkies, it seems be linked to the active channel for the main LEDs, changing both, and not persisting when exiting and reentering blinky modes. Also, it skips disabled modes - I’d like to set an aux-only channel for blinkies without having it in the main rotation.
1 Thank
True, and I’ve been meaning to do that. Or make it auto-detect based on the length of the channel mode list.
Also true, and fixed now. The post-off voltage display (which really needs a better name) only activates now if the torch recently entered Off or Lockout mode. It also uses a low brightness instead of high, if the torch was previously at a very low level. It was annoying having the aux turn on high and light up the whole room right after the main LEDs were used in moon mode.
I think I fixed that in r702?
Maybe you were in tempcheck instead of battcheck? Only battcheck has the right 3C action to configure the blinky color.
Or maybe it was built without that feature enabled? It requires defining a default blink channel, or it won’t compile in the ability to change that. It would definitely explain the symptoms you described. The build needs one of these:
// blink numbers on the aux LEDs by default
#define DEFAULT_BLINK_CHANNEL CM_AUXWHT
I’m debating what value would be best for production builds though. Like, maybe it should default to the main LEDs, and have aux available only for people who configure it. Or maybe it should use aux by default, and risk confusing people when the blinks are really dim. I’m not sure.
1 Thank
Anyone seen beamshots or observations out yet on the SFN60 3V, 3000K ?
Main LEDs is probably fine as a default, just set DEFAULT_BLINK_CHANNEL to them by default so functionality to change it is enabled.
I was definitely in battcheck - was missing the default blink channel; the way cfg.blink_channel is dereferenced through BLINK_CHANNEL had me confused for a bit there 
As for the bug, looks like one but technically isn’t, then, I guess, as the switching blink channel was not compiled in and I thought it was, so the default 3C handler in channel-modes.c was just advancing the main channel instead, while blinkies were still set to the main LEDs (including aux-only ‘main’ channels I added while playing around).
Not sure if it’s desirable though, as it could definitely be confusing to the user. I patched channel-modes.c for this case so 3C in battcheck doesn’t do anything if the feature is disabled, using an ifdef since it otherwise adds ~12bytes of image size and is unnecessary if DEFAULT_BLINK_CHANNEL is defined:
if ((event == EV_3clicks)
#ifdef DEFAULT_BLINK_CHANNEL
)
#else
&& (current_state != battcheck_state))
#endif
{
uint8_t next = cfg.channel_mode;
// go to next channel mode until we find one which is enabled
// (and don't do any infinite loops if the user disabled them all)
...
}
Hank says that 3000k is 90cri, and someone with it in another light says it is slightly above DUV (slightly yellow) but otherwise has no angular tint shift (Hank confirms this, with the OP reflector). No idea what the R9 is, hopefully better than LH351D.
The slightly positive tint should be easy to fix with a minus-green filter or something similar, while still being very high output.
2 Thanks
Does anyone have parasitic draw measurements for lights that have RGB AUX and RGB button?
I ordered a boost driver D4Sv2 with both and am wondering if it was a bad idea…
Very exciting discussion! I live for these kinds of quality of life and feature updates for the softwares that I love!
The way I see it, when you’ve set the blend you like, 2C should keep that blend (so 100% + whatever the lowest channel should be at), but there should also be full turbo (200%).
My suggestion: momentary turbo goes 200%, but regular turbo (2C) goes 100 + x% (preserving the tint ramp blend). This would work well in anduril 1 turbo style.
For anduril 2 turbo style, I think what makes most sense to me is to keep 100% + x% everywhere. Except maybe momentary from turbo… So to access 200% you need to ramp up to ceil, then 2C, then 3H (if enabled).
Actually it would be nice to have momentary turbo configurable. A configurable shortcut. On a flood + throw, it would make sence to turn off the flooders (to reduce foreground illumination) and go full turbo throw.
1 Thank
I try last firmware upgrade for Wurkkos TS10 anduril.2023-05-03.wurkkos-ts10.hex
OFF -->6C… I set Tactical mode in slot one and the flashlight seems to forgot the Bike flasher in Strobe Mode/Mood Mode
(OFF–>3H) and I find Tactical strobe when I go to OFF–>3H…lost memory?
Agreed. I’ve got various mods I wrote for the old dual channel only version to port to the new ramping code, but this is my preference too - I will probably be putting 200% turbo on 4C and previous channel on something like 6C.
I had this on the older version (still running on most of my lights), I’ll let you know when I get it working on the new builds. Previously it was individual per-channel at 100% as well as using the existing mix at 100%, but I’m going to have to rethink how it works for 3+ channels.
Looks like tactical mode updates the light’s configured mode: ~toykeeper/flashlight-firmware/multi-channel : contents of ToyKeeper/spaghetti-monster/anduril/tactical-mode.c at revision 816
It would be possible to do something like this (Edit: not working, will take a quick look)
uint8_t tactical_state(Event event, uint16_t arg) {
// momentary(ish) tactical mode
uint8_t mem_lvl = memorized_level; // save this to restore it later
uint8_t ret = EVENT_NOT_HANDLED;
uint8_t orig_strobe_type = cfg.strobe_type;
// button is being held
if ((event & (B_CLICK | B_PRESS)) == (B_CLICK | B_PRESS)) {
// 1H: 1st level
// 2H: 2nd level
// 3H: 3rd level
// 4+: nothing
momentary_active = 0;
ret = EVENT_HANDLED;
uint8_t click = event & 0x0f; // click number
if (click <= 3) {
momentary_active = 1;
uint8_t lvl;
lvl = cfg.tactical_levels[click-1];
if ((1 <= lvl) && (lvl <= RAMP_SIZE)) { // steady output
memorized_level = lvl;
momentary_mode = 0;
} else { // momentary strobe mode
momentary_mode = 1;
if (lvl > RAMP_SIZE) {
cfg.strobe_type = (lvl - RAMP_SIZE - 1) % strobe_mode_END;
}
}
}
}
// button was released
else if ((event & (B_CLICK | B_PRESS)) == (B_CLICK)) {
momentary_active = 0;
set_level(0);
cfg.strobe_type = orig_strobe_type;
}
...
Edit: While testing, my UPDI adapter decided to release the magic smoke 
seems like it shorted somehow, so I’m blocked on that for a while.
Oh noooooo… bad news!
Yes, it’s a known issue that I haven’t thought of a good solution for yet. Tactical Mode, when configured to use a specific strobe, overrides the memorized strobe mode in the “Off → 3H” group. It’ll take some finagling to come up with a clean solution which doesn’t use any significant additional space.
Since this is Hank’s thread, we should probably avoid discussion of other brands here.
Ops…i am sorry! There is a good place in BLF for your firmware?
Are your magnets oriented in a uniform way? Is your tail side always N or S?
I received my D4K with magnet and it is oriented differently than my other Hank lights. All my previous Hank lights had N pole facing the tail, but my D4k magnet is facing S pole.
Would it be possible to change the orientation of the magnet on my own? How do I disassemble the tail without damaging the magnet from heat?
I have some Hank lights where the magnets are oriented differently. They all stick to whatever I need them to stick to, so I never worried about it.
The tailcap PCB is glued in with CA glue (super glue), you can use some acetone to dissolve it.
Once that is off, it should be pretty straightforward to flip the magnet and reassemble.
Is there a reason that just storing cfg.strobe_type on entering tactical mode and restoring it on exiting the mode didn’t work? I only got to test two builds so I couldn’t fully test it but I tried a couple of approaches with no luck.
Also, found an interesting bug/edge case for lights with RGB aux. If you have aux-based channels (e.g. for blinkies, or just for a light with powerful RGB like the IF23 (an IF23 Pro maybe? 
), if you have USE_AUX_RGB_LEDS_WHILE_ON (e.g. D1), the aux LEDs stay on when setting a level in an RGB channel, so you get a combination of the two instead of the desired channel.
I’m not sure if you were planning anything else for 4C, but I added previous channel to 4C because it’s definitely annoying to have to loop back round if you go past one.
(There should probably be a single thread for anduril development so we don’t clutter up threads like this…)
1 Thank