Yes, I understand that, but what actually this setting do for lume x1? Nothing?
After some recent refactorings, it doesn’t do much anymore.
1 Thank
Oh I see, thank you! Very elegant way to search btw. But, if it doesn’t really do nothing important anymore - what about old flashlights, which are +FET (like CC 5A KR4 driver and so on)? This parameter was that mark after which the PWM FET was usually turned on (and usually there is a blink when we pass it while ramping). What option now is that regulated threshold?
It can be configured from the menu now:
See cfg.button_led_low_ramp_level and cfg.button_led_high_ramp_level.
2 Thanks
On the Noctigon K1, is it possible to disable voltage mode on the aux LEDs while the main LED is on? In other words, can the aux LEDs have the same manually set color when the main LED is on and off? I looked in the manual on github, and couldn’t find anything related to this (I’m assuming because it’s a feature unique to the K1).
Not without flashing new firmware.
It’s a compile-time config option, and can’t be changed by clicking the button. Basically, remove this part of the config:
#define USE_AUX_RGB_LEDS_WHILE_ON
This is the same for any supported light with a RGB button. While the main LEDs are on, the button can either display voltage by color… or it can be off. There isn’t currently an option, even at compile time, to make it use the RGB setting from “Off” mode while it’s in an “on” mode.
2 Thanks
I see. Looks like I’ll need to brush up my C if I want solid aux.
This is good to know for my other light with RGB aux.
Hi @ToyKeeper
I hope this is the right thread for my question / proposal.
I read your comments about the dimmable RGB AUX lights that you are working on.
Really looking forward to that 
I only use the red AUX lights, because all other colours seem to be too bright for me for nightstand situations.
So thanks already
I wanted to ask / propose something.
The lowest light level on Lights with the Lume drivers are super low.
Would it be possible to add the moonlight level to the AUX options (selecting with 7H)?
Then also lights, like the KR1, that don’t have AUX lights could have a solution to be found in the darkness.
(i could of course also just leave the light on in moonlight, but it would also be cool to have this option for when the light is locked)
Thanks a lot in advance for considering 
To use the main LEDs, the microcontroller has to be running, which consumes a considerable amount of power, depending on the driver similar to high aux.
The dimmable RGB aux included in the KR1K were not implemented by ToyKeeper and are still not included in the mainline repository. From what I’ve heard, I’m not sure if they should become the new reference implementation due to some issues with their capabilities (mainly programmable features and PWM frequency).
1 Thank
Do you know how much it consumes on the lowest settings?
On most lights… no. As SammysHP said, moon generally requires the MCU to be awake, so it would be the same as just leaving the light on normally, in moon mode. You can do that if you want, but it’ll drain the battery like 15 to 20 (edit: 50) times faster than low aux.
Power use varies, but a typical amount (edit: for a FET+1 driver) would be about 1.7 mA… of which like 1.6 mA is used by the MCU and any other active components of the driver, and only ~0.1 mA is used by the LEDs.
On some newer MCUs with DAC-based avr32dd drivers (like D3AA and Hank’s Lume X), it might be possible to run the DAC during standby mode… but the details aren’t known yet. At a guess, if it works, (edit: and with a power circuit designed for this) it might be able to do a moon level at perhaps 0.5 mA. Setting the hardware registers the right way might thus enable a significantly better “standby moon”, as compared to the regular “ramping-mode moon”. But the power use is still a bit high.
The aux LEDs typically use about 0.1 mA on lights which implemented them well. This works out to about 1 year of illuminated standby per 1000 mAh of battery capacity.
The new dimmable aux LEDs raise the minimum power to about 0.3 mA. That’s part of why I’m not very enthusiastic about them. It uses more power, and makes them strobey.
–
Edit: Nevermind, these drivers can’t do a lower moon after all. I measured moon at 3.7 mA on a D4K-lume and 5.0 mA on a D3AA, which means the boost circuit has a higher power overhead than I thought. There’s no way the current drivers could operate at the power levels I was hoping for. To accomplish this “standby moon” feature, a whole new driver circuit would be needed. As far as I can tell, no currently-support hardware is capable of it.
5 Thanks
Thanks to both of you for the explanations.
All clear
About 5-6ma at 100uA led current, it wont change much at lower led current, main power consumption is from the boost converter due to the mininum 23kHz switching frequency, then from the MCU.
On Lume buck drivers the consumption is lower, should be arround 1.5~1.8mA and is mainly the MCU because the buck converter has nearly negligible zero load power consumption.
Technically it should (probably) be possible to run the MCU in Ultra Low Power mode, and with a buck driver, the current consumption on very low moolight would be at least under 1mA, likely under 0.5mA, but this hasn’t been tried yet.
8 Thanks
Hi,
first of all I want to say that I love the firmware, but there is one feature I would really like:
Having the ability to set the button LEDs to high while still having the AUX LEDs off or at low.
I have several Hank lights with the X1 driver with the amber button LEDs and those seem to be really dim.
Is there currently any way to achieve this? I am comfortable with changing a bit of code if the hardware in those drivers even supports this.
Thank you for your help
The aux LED code is a mess and I’m hoping to rewrite it soon.
For now, the most it supports is having the single-color button LED on while the main LEDs are on, with the aux RGB off. But in standby mode, it ties button LED brightness to aux RGB brightness. It doesn’t have to, and it could be changed… but that’s how it works now.
As for changing it, one of the factors which interferes is how the interface should work. It’s already pretty crowded and awkward, and each new option makes that problem worse.
More generally though, I don’t recommend leaving any of the aux LEDs at high level while in “off” mode. They use too much power, and greatly reduce standby time.
7 Thanks
I recently received a KR1K and KR3 from Hank that I want to flash my personal config on, but I want to make sure I shouldn’t wait for the repo to be updated first.
Other than the advanced AUX, which I don’t plan to use, are there any firmware differences between the KR1K/KR3 configs and the other LumeX1-based lights? The KR1K has a model code of 283 and the KR3 has a model code of 284. Is it okay to flash my 281 config on these lights, or should I wait for the repo to be updated with the 283/284 changes?
At minimum, the aux LEDs wouldn’t work at all. There may also be other issues, but I think it’s probably just the aux LEDs.
Can confirm, the aux leds do not work with the 281 configuration applied. I assume the newer drivers use different pins for the aux leds?
other than that, the main LED appears to work normally.
I found loneoceans fork, and built my firmware from there. Working as expected now. Hoping this gets merged to your repo soon.
They use an entirely different protocol.
Other lights power the aux LEDs directly from MCU pins. It can be off, on (with internal resistor), or on (without internal resistor), for the off/low/high brightness levels.
These new ones have a whole separate controller chip managing the aux LEDs, and it uses TWI / I2C to communicate. But loneoceans pulled in some proprietary code for that, which I can’t legally merge. So I have to rewrite it.
And to make the dimmable aux have any reason to exist, I also need to add features to make use of it. Otherwise it’s pretty pointless, just a straight downgrade compared to the older design.
1 Thank
Ah, I see. Thanks for the explanation.