Yeah, I was wondering about that too. Since it’s “tactical” mode, would it be better to just keep the aux LEDs off? It seems like the torch should probably be completely dark except when the button is held down.
The post-off voltage display could probably be a UI option. However, I’m not sure where in the UI to put the menu. Maybe in the “Off → 9H” menu… but I try to avoid putting anything there if I can avoid it, because it’s the most inconsistent menu due to having different options on each torch.
One more reason to have a system of documentation per torch, I suppose. Each one has things which make it unique, and that info needs to be available somewhere simple.
The entire indicator LED / button LED / RGB aux LED system probably needs a rewrite, since it mostly grew on demand without any sort of plan or design beforehand. But not until I’ve at least caught up on the other rewrite I’m still in the middle of… the multi-channel thing.
I also need to completely restructure how the build target files are organized. Adding per-light documentation would fit into that project nicely… after I get the current thing done.
Things like that are definitely possible in the multi-channel branch I’ve been working on, but it isn’t implemented yet. It has the ability to set the color or channel of a few things per build, but the number blink function doesn’t do that yet.
There are a bunch of details and complications involved though… some technical and some social. Like, ever tried to get people to agree about what color something should be?
I would like to reduce the brightness of the numeric blinks, or at least make it more consistent. It tries to guess a number in the lower portion of the ramp, but the brightness varies a lot between different torches. It should probably be set per build, but generally hasn’t been. One more thing to calibrate for each build target, and/or try to find a sensible place to add a menu option for.
Already did. You should have seen how much worse it was before.
Most of the dual-channel lights use constant current regulators, either linear or boost… and those behave differently than pure PWM drivers.
With PWM, the pulses can be shortened to the absolute minimum which causes the LED to illuminate, and if that’s not low enough, the pulses can be spaced farther apart. The only limit to the minimum brightness is the user’s persistence of vision – slow it down too much, and it becomes obvious that it’s pulsing.
With constant current, there is usually an absolute floor that the firmware can’t go below. When the regulator circuit is enabled, even when given a control voltage of zero, a non-zero amount of current leaks through. This makes the LED light up, and the firmware can’t make it go any lower. It’s determined by hardware.
Before anyone asks, no, it can’t PWM the enable pin for the regulator. That doesn’t work unless the regulator was designed for it, like an amc7135 chip. That’s not the type of regulator being used in these linear / boost drivers.
Working on it.
There are about 70 builds to update. So far, I’ve posted preview builds for 4. The rest should go faster, once I get there… but first I’m trying to make sure the foundations are solid.
At the moment I’m trying to figure out an issue in yesterday’s d4v2 build. I’ve seen it do something weird a couple times, but I haven’t been able to make it happen on purpose. Heisenbugs are the worst.
Oh. Thanks for the information. I didn’t know that. So does that mean we are already at the lowest moonlight level and that this updated firmware cannot go lower due to the hardware limitation?
However, these recent builds may be able to go very slightly lower… because I changed the tint-ramp code to allow the lowest level to be 1 instead of 2. So it’s 1/16383 instead of 2/16383.
That’s probably not enough to make a visual difference, but it might show up on measuring devices.
The actual lowest level may be low enough that it doesn’t even light up though. It really varies a lot based on the hardware. Hank had me set the default floor to 10/150 on several models because 1/150 was unstable and sometimes wouldn’t light up at all.
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.
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.
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)
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)
, but I did it this way because I tend to favour “making stuff as configurable as possible” as a design philosophy.
