If people want lower than 0.2 lumen just remember that this isn’t going to be just released for enthusiasts. We certainly don’t want more complaints about flat cells because users thought it was off in daylight. This happened on previous revisions.
Perhaps advanced mode could have access to it, but that would require more coding
Constant current is often controlled internally by PWM. The MCU generates pulses, the pulses go through a lowpass filter, and it produces a steady analog control voltage. Then the control voltage determines the amount of current the power regulator allows through.
Decreasing output below 0.2 lm might be possible, but it probably wouldn’t increase the runtime by a meaningful amount. It could even have the opposite effect. The LED isn’t the part which is using the most power at such a low level… the power is used instead by the boost converter and the control chip.
For example, the BLF Q8 originally shipped with the ability to run at ~0.01 lm, just barely enough to produce a dim glow in the dark. In this mode, with four good cells, the runtime was about 90 days. It was a special adjustable moon feature in NarsilM… which was cool, but required running the MCU at full speed.
After reflashing the firmware to Anduril, the lowest moon level is about 0.2 lm. However, despite being brighter, it also increased the runtime to about 300 days — because it underclocks the MCU to conserve power. This reduced the precision available for output control, but greatly increased the runtime.
It was a case where people could have less than 0.2 lm OR they could have super long runtime… but not both.
Switching converters do have bad efficiency at low current but even a 30% efficiency at 100uA (TPS61088 used in Zebralights ) or 5% at 10uA (TPS61288) means that the bulk of the power consumption is still the MCU (although it’d be nice to know what is the regulator used in the SP10S). Gchart measured the power consumption with PWM at different system clocks here : Adventures in TinyAVR 1-Series - #29 by gchart
5.5mA at 10MHz which is the sytem clock used, it could be decreased to 5MHz or 2.5MHz (<2mA) using the dynamic underclocking function but then we should check that the output ripple is still acceptable, if not then the RC filter could be modified to better smooth the PWM at the cost of rise/fall time (mostly an issue for party strobe).
There could be further gain using TCD and dropping the clock to 32kHz in moonlight. Or, even better to use the DAC instead of PWM which would then allow Zebralight class moonlight efficiency.
I think the candle lantern simulation can be done with a white led by having a yellow diffuser. I checked and there is translucent yellow or orange 3d printing filament available, though it would be even better if a molded diffuser is made to fit the light.
Yeah, the LED was only a tiny part of the total moon power usage on a Q8, and it didn’t even have to deal with converting the voltage. On the SP10, we’ve got that plus whatever extra overhead the power converter requires.
The newer MCU offers some additional features for reducing its power usage, but I don’t know enough about the implementation details to know which methods are feasible here. Like, using a DAC may or may not be possible. And running the system clock in the kHz range instead of MHz range has some, uh, side effects. In particular, it has a tendency to interfere with the ability to reflash the firmware. I found out the hard way that it’s really easy to accidentally put the chip in an unrecoverable state when messing with slow clock speeds.
Another method for getting an extremely long-lasting moon level is to treat it as an aux LED. Set up a passive current path, and put the MCU to sleep. This generally requires using an extra pin, and I’m not sure how it would work on a boost circuit, but it otherwise has worked really well in the past. Instead of 300 days of runtime at 0.2 lm, the Q8’s button LED gets like 0.1 lm with a runtime of 10+ years.
Mike C uses the DAC in his driver and as he mentionned in my thread is ready to share his code if needed.
Loneoceans I think mentionned that he have used the DAC with the 1616 but he hasn’t been online for a few months.
Yeah that wouldn’t work with a boost converter, and while it is simple with FET and linear topology by putting the pin as sink, I think it is more complicated with buck topology and might require extra components.
That equates to around 16 days runtime for both, not terrible for a AA-sized light. Most of that probably is from the CPU being awake. Sleep measured around 37 uA on both chemistries. To obtain crazy good low-light efficiencies, the driver should be designed for that from the ground-up. The SP10 (S/Pro) driver wasn’t really built with that in mind.
The low channel is such that it puts out 0.2 lm (NiMH) / 0.5 lm (lithium) on PWM 255 of 255. It’s possible that I could trick the low-channel to actually just set the pin high or low instead of actually using PWM. Then I could set up the dynamic underclocking to switch to the ULP (ultra-low power) 32 kHz clock when we’re using the lowest level.
I have experimented with the ULP without having any problems re-flashing firmware. But I’d consider this to be experimental, I can’t say there won’t be problems. When my prototype arrives, I’ll experiment with this. My guess is it won’t make it into the stock firmware, but we’ll see… maybe it would work better than expected.
Yes, but his driver was designed for it. The firmware can’t make a DAC work if the hardware isn’t designed to allow that.
In any case, I don’t know enough about this driver yet to know if the firmware could reduce moon power beyond its current level. It might be possible, or it might not. I’ve been more focused on other things, like adding UI features people have been asking for.
Some of the things in progress…
Smoother ramp on low levels (on some lights)
Faster moon activation on lights which don’t turn on quickly
Configurable smooth ramp speed
Let user choose whether hold-from-off should ramp up or just stay at moon
Let user choose what double-click does while on (turbo or ceiling)
Let user choose whether turbo is allowed in Simple UI
Maybe add an option for an automatic sunset timer in ramp modes (because sometimes muggles turn the light on, use it for a minute, then set it down and walk away)
Maybe make the ramp auto-reverse window shorter, because 1s seems a bit too long
A lot of this focuses on giving the user more control over basic operations, especially in simple mode. That way, they could configure simple mode as a safe, limited mode for kids… or they could make it a full-power mode for their own use.
The idea of being able to connect the led like a d4v2 aux led, i.e. through the avr pullup resistor, would be cool if it is doable. It would allow lighting the led with the processor completely asleep, if I understand correctly. However, I think you would not be able to adjust the firefly brightness in software. It could be 0.001 lumen or whatever you want, but you would set it by changing a resistor on the board, not through a UI.