If I recall correctly, the KR1 uses the KR4-nofet firmware.
I converted the KR4 and KR4-nofet builds today.
0211 noctigon-kr4 attiny1634
0212 noctigon-kr4-nofet attiny1634
Here’s the one I’m using on my KR1 W1: (0212, nofet)
http://toykeeper.net/torches/fsm/anduril2/anduril.2023-04-29.noctigon-kr4-nofet.hex
Maybe, but tac 7H already has a menu attached, to configure tactical slots 1/2/3. So it would need to be moved… probably to 10H to keep it consistent.
The internal implementation probably needs some changes too, to change how the data is stored. The details don’t matter much, but the way it works right now isn’t scalable. I built it with the expectation that “off” and “lockout” would be the only two modes with aux LEDs.
Thank you Toykeeper!
I have the KR1 SBT90.2 and the firmware check blinks 0211. So I am gonna grab that KR4 version one from your site. Cheers!
The 10H makes sense, but sounds like a big project…
Wouldn’t it make sense to include the model numbers into the hex file names? For example, I renamed the 0135 file to anduril.2023-04-25.emisar-2ch-0135.hex. I find this helps a lot to easily recognize which file is for which light.
I fixed this a while ago by always loading the manual memory config when entering lockout. In my opinion lockout isn’t just a regular mode, but a hard cut in the UI with a defined, consistent behavior. It shouldn’t change its behavior after some time of inactivity.
I’d have to write more code if you mean in sequence like rainbow mode, or if you meant all three at once that’s doable.
I think that having some kind of miscellaneous config is probably unavoidable, especially as the lights the code runs on get more diverse. Ultimately, if the order is deterministic it isn’t too bad (e.g. “channel switching mode (multichannel only), jumpstart level (if feature enabled), number blink type (if feature enabled)”, etc…)
I think they were referring to the aux - I use aux (on cyan on most of my lights because that’s my favourite) to blink numbers instead of main emitters.
Did you check my patch? I’m sure you’ll probably come up with something better though 
, but I did it this way because I tend to favour “making stuff as configurable as possible” as a design philosophy.
anduril2/spaghetti-monster/fsm-misc.c at main · SiteRelEnby/anduril2 · GitHub - blink_digit_type is just an additional 9H menu option.
Ideally I’d like to make the colour selectable at runtime too though but still very undecided on how; a second new 9H menu item maybe, I guess…
Did you find a way to compensate for voltage drop? I wrote a feature to warn on low battery and had to detect when it was recently used on high (currently kind of a hacky way as it’s just using memorized_level which isn’t always accurate for when there might be voltage drop due to cases like a long turbo run, then 2C back to low, then off, or special modes like strobes), because with a lot of my lights, I find if I use them on turbo, it will trigger the low battery warning for a few seconds before bouncing back up again… Or now the ADC reads more often, is that enough?
I was referring to aux too. I have channel modes which use aux LEDs instead of the main LEDs. So you could have 3C switch between white, red, green, and blue, for example… and use those in every regular mode. But the colors are very dim compared to the main LEDs, and they have no ramp. So I have those channel modes turned off (not included in the 3C rotation) by default. They’re mainly included only for special cases.
As a test of this, the 2-color police strobe uses red and blue aux LEDs on single-channel lights. But it uses the main LEDs on lights with 2 or more primary LED channels. The strobe mode itself has no clue it’s using aux LEDs; it just uses set_level() like everything else.
The menus and factory reset already have a compile option to use a specific channel mode, and the digit blink function probably will too. So instead of just blink brightness, it can specify blink channel too… and the aux LEDs can be used as a “channel”.
A UI menu could also allow the user to choose a channel for this, but I’m not sure that’s worthwhile since I don’t want to end up with a super-long Misc Config menu.
Nope, haven’t even tried. But when it updates once per second, the sag recovery is generally pretty visible. When doing turbo-to-off, it’ll often start out red, then 1s later it turns cyan or blue.
Makes sense, I’m new enough to MCUs that I still don’t feel super comfortable hacking on the lower level FSM stuff yet so just decided I’d live with it for now, but guess I’ve got some rebasing to do then, I really don’t mind if it is just for a second or two.
I have installed your 0135 hex on my KR4, and I am playing / learning with it. Great development. I find it a super idea to show the voltage for 3sec after off. However, if, for example, the aux leds are in “high” mode and following the “disco” or “rainbow” pattern, I find it a bit confusing to understand which now is the voltage indication, and when does it switch to the “normal” aux mode (disco or rainbow in my case). This is not an issue when aux leds are set to “low”, “blinking”, or “off”, of course.
It might help to understand when the voltage mode ends, if you add a short time - say 2 sec - with the aux leds off, after voltage indication, before it switches from voltage indication to “normal” aux mode. Just an idea.
I agree, probably totally dark
When we need to battery voltage i think 3C from off is a good option. But see battery voltage every time i switch off the light is a little bit confusing. I see 4 different colours every time.
If you need a rewrite the entire LED/Button LED/ RGB aux LED i think is a good idea after …” The multi channel thing” is a priority at the moment for you I think.
We can do a survey for the aux color.
For example… red (remember me an alert!)for lockout, green for battery voltage, blue for tactical but only when we choose function… I have to think carefully about this
I know different flashlight at level 20 are different but for example i use EC06 at level 20 all night long and is a good number for reading battery voltage.
I try some flashlight at lvl 20 and is a good basic number for non blind moment 
No no, not rainbow mode i mean RGB at the same time(all 3 leds on)… i want you write less code and minus stress
I’m thinking how to use better the aux led
@ToyKeeper thank you, but is this in the manual?
I can’t find it.
• Rev 656. 2023-03-28
strobe modes: added 4C to cycle backward through strobes
• 654. 2023-02-10
fast-blink the aux LED in standby when battery is low
3.3V and up: normal aux LED modes
2.9V to 3.3V: fast blink
under 2.9V: off
(only on lights with no RGB aux)
Strobe 4C was in the reference table, but not in the text above.
Single color aux voltage warning wasn’t documented.
Both are fixed now.
Thank you Toykeeper!
Documentation is the pesky task after you figured out a solution. → it’s often PITA. (e.g. I have no idea I programmed THAT a few months ago) 
If I understand correctly as soon you enable multi channel, toggling smooth / stepped ramp moves to ON → 6C?
Then in Channel Modes
- 3C: Next channel mode
- 3H: Adjust current channel mode (ramp tint, for example)
- 9H: Channel mode config menu
should be?
- 3C: Next channel mode
- 3H: Adjust current channel mode (ramp tint, for example)
- 6C: Toggle smooth / stepped ramp
- 9H: Channel mode config menu
The first
- 3C: Switch to the other ramp style. (smooth / stepped)
in text should have a little hint that 3C can change, maybe like
- 3C: next channel (if multichannels are enabled) And smooth/ stepped moves to
- ON -> 6c to toggle smooth/stepped (if multichannels are enabled)
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.
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.
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.
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_ENABLED should be uint16_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.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).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.