Probably, yes. On low, it can stay on all the time, constantly indicating the battery charge level or just showing your favorite color. Charge it every year or so, and it should be fine.
On high, the runtimes are much shorter but it can be seen during the day… not just at night. It’s not really for illuminating things though; even if the color LEDs were bright enough, the beam pattern is pretty uneven.
However, I find that blue and green on low are bright enough to navigate in a dark room when I wake up in the middle of the night… and on high, any of the colors should be bright enough to avoid tripping over things. But instead of using the RGB high mode to light your path, you may as well just use moon mode on the main LEDs, since it makes more light with less power.
The RGB LEDs are mostly for just a few purposes:
Look pretty
Show the approximate battery level
Indicate whether the light is locked
Find the light easier in the dark
Firefly mode (on low, in very dark places only… less bright than moon)
… and if I ever finish it, I’ve been meaning to make a tutorial which covers things in order of simplest to most complicated — instead of the current style which is organized in the same structure as the diagram.
Thanks for the reply, been looking at these all day haha
Think I am going to have to have one, the colored aux leds are really cool and put it over the top.
I have wanted a tri or quad light for a while, and having one that can have a permanent color glow sort of like tritium, well thats just looks cool!
Will I have to disable it in the code mysel or is there a .hex file available already?
Maybe the normal d4v2 fw will work as it does not have switch leds?
They use the same firmware, you would need to compile it without the line in the cfg file:
// it also has an independent LED in the button #define USE_BUTTON_LED
It looks like the brightness can be set the same way as the rgb aux, but I dont know if it is independent from the front facing AUX. Id need input from TK on that one as im not 100% sure how semicolons get interpreted in this code:
The D4v2 firmware has button LED support built in, so Hank can use the same driver on both models.
To disable it, comment out the line in the config file for USE_BUTTON_LED.
Yes, the development for Anduril and other FSM-related projects happens in the FSM branch… or in sub-branches forked off the main FSM branch.
Trunk is used as a repository for stable code created by many people doing many projects, and development for those projects typically happens in other branches or even in other repositories… and then gets merged into trunk periodically.
What would that look like? What would it do, and how would the user configure it, ideally?
Can you increase the brightness of the low mode of switch leds somewhere in the code?
I don’t want to change resistors, because then high is too bright.
The brightness of low mode is determined by the internal pull-up resistors inside the attiny chip.
The brightness of high mode is determined by the resistors on the aux LED board (either the RGB ones, or the switch LEDs).
Both are completely passive, meaning the circuit is turned on and the control chip goes to sleep. Power flows entirely according to the analog properties of the circuit, much like water leaking through a small or large hole.
To get any brightness level between the two, the control chip must stay awake to turn the internal resistor on and off very quickly. However, the control chip uses more power than the LED does, so the standby time would be even shorter. It’d be something like…
Longest to shortest runtime:
Low mode: 3 years
Blinking mode: 1.3 years
Moon mode: 10 weeks (main LEDs, not aux LEDs)
High mode: 7 weeks
Medium mode: 5 weeks
The numbers are very approximate, but basically, a level between low and high would typically use more power than just leaving it on high mode… and it also would require some relatively deep changes to the code because it would completely change the definition of what it means for the light to be “off”.
The easiest method would be to add a dedicated “on” mode for adjustable aux LEDs or a “breathing” mode which counts as “on” instead of “off”. It could be like candle mode, but using different LEDs. Using it to save power in standby is not really feasible though, since it would use more power instead of less.
Or perhaps lockout could have a “breathing” mode, but it would reduce standby time by an order of magnitude compared to the default blinking mode.
Or someone could use higher-value resistors on the aux LED board, to reduce the brightness of high mode. This is the most power-efficient solution available.
