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
At low output levels like this the current to the led become less and less relevant and the majority of the power consumption is from the MCU.
Zebralight probably run their MCU at a very low clock to use as little power as possible.
Really ? Never heard of people complaining about Armytek, ZL, Manker moonlight being too low and it’s much lower than 0.2 lm on several of their model.
The driver works with pwm?I like much constant current
You do have a point.
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.
I would take that trade.
I vote for Firefly levels…
Firefly capability is higher priority for me,
than months of Moonlight runtime
I change batteries much more often than a Firefly runtime limitation of three months
sounds good to me
as long as I can have 0.01 lumen Firefly, not just 0.2 lumen Moonlight
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.
FWIW, I’ve measured on the lowest mode:
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.
I would really like an AA Anduril light that could do Firefly of 0.02 lumens, on AA Eneloop…
I find 0.2 Moonlight too bright when camping in full darkness
You should be able to do that… after flashing custom firmware (lower the ramp PWM value). I don’t deny your use of that, but I believe you to be in the minority.
I think if you run a poll, we could learn more together
1. I would be happy to have the option to use Firefly 0.02 lumens, with a 90 day runtime.
2. I would prefer a 300 day runtime, even though I can only get Moonlight down to 0.2 lumens…
I dont need a poll, to know what I like 
access to firefly is the reason the FWAA does not get used for dark adapted camping, and I use a Jetbeam RRT-01 instead.
The SP10 Pro Will be better, with a lower low… (see what I did there?)
runtime worries are not a priority for me, I use rechargeable batteries
Im never lost in a cave for more than 90 days, with a single flashlight… 
Just to be clear, when ToyKeeper gave those lumen and runtime values, she was talking about the BLF Q8. That’s a 4x 18650 light… about 14x the battery capacity of the SP10.
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…
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.
ok, thanks
I would take 3 days of 0.01 lumens, over 30 days of 0.2 lumens
any number of days… just give us a real Firefly :+1:
I can just change batteries
I dont actually live in a cave
To be clear:
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.
thats OK, I dont need 0.001, Im only asking for 0.01