Sofirn SP10 Pro (AA/14500/Andúril 2) - now available!

Ah quite understandable about the space. I’ve been reading up on UPDI. It looks like it should only require a single contact pad on the board, since it’s a bidirectional i/o line, and the + and - lines can be gotten from the battery contacts. Then there are two kinds of reflashes:

1) hardware devs might sometimes need to unwedge the chip with a 12 volt pulse to the UPDI reset pin, so there are special dongles for that.

2) Software devs and users will normally want to just reflash the app, so if it is set up like an Arduino with a bootloader, it should be possible to reflash off a normal gpio pin from a random MCU board or raspberry pi or pi pico. That is nice because it gets rid of the need for special hardware adapters, imho. UPDI gives bidirectional communication and debugging, and even has GDB support, which will be great. The GDB remote stub will require some code space of its own, I don’t know how much, but I hope it is not large.

I wasn’t familiar with the term Dupont connector but it looks like they are 2.54mm header pins. I wonder if there is something smaller available.

Here’s a tiny pogo pin clip that could be about right for gripping a contact pad: Pogo Pin Probe Clip : ID 1969 : $2.95 : Adafruit Industries, Unique & fun DIY electronics and kits

Is useful have on ni-mh the minimum ramp level as low as possible below 0.2Lm
A 1800k option would be gorgeus to emulate candle or gas lanter.But apart the particular E21A 2K there is nothing in high CRI 3V with standard sizes.
Can be requested to be produced by another Chinese manufacturer such as GT-FC40.
And on sp10s I don’t want to see sharp edge and pineapple knurling anymore

It could go much lower than 0.2 lm, but I don’t see many people wanting it set that way. But you should be able to adjust the PWM ramp and flash new firmware as you see fit.

i would prefer lower than 0.2 lm for supper long run like zebralight

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:

  • 2.3 mA on lithium-ion
  • 5.4 mA on an Eneloop

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 :wink:

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… :person_facepalming:

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…

  • 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.