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

LED Flashlights – General Info 1 x AA / 1 x 14500 Flashlights
1101

Im not sure that is a valid question, because Anduril has no single specific High Mode, it depends on where the ceiling is set… and whether you are in Simple or Advanced mode.

My Lumintop FWAA w Anduril 2 comes with 150/150 ceiling in Simple mode… iow, High Mode is also Turbo.

My Lumintop FWAA w Anduril 2 comes with 120/150 ceiling in Advanced mode… iow, High Mode is less than Turbo.

…

My Copper FWAA, starting from 150/150 maximum output of about 1100 lumens

has a thermally sustainable output of
237 lumens freestanding, w 45C thermal limit
407 lumens freestanding, w 60C thermal limit

if my Copper FWAA is held in my fist, to cool the head,
it can sustain 400 lumens hand held, w 40C thermal limit

bear in mind Copper is 70% more thermally conductive than Aluminium, so it is possible that the SP10 Pro will have 70% lower thermally sustainable outputs…

that would be (estimated):
166 lumens freestanding, w 45C thermal limit (matches the chart in post #1)
285 lumens freestanding, w 60C thermal limit

1102

Same here! 1xAA is my first love in flashlights, and 14500 support is an added bonus. Huge thanks to all the collaborators in this project.

1103

Is the latest version of Anduril 2 compatible with gcharts sp10s driver mods? Does it still work with 416, 816 or is it 1616 only now? I haven’t had time to do mods.

1104

1st Q: yes it is, but it's in gchart's branch - not sure if TK sync'ed to his latest, maybe, need to check revs.

2nd Q: well, 416 won't work because Anduril 2 won't fit into 4K, 816 is debatable - might fit into 8K if you remove a couple things. 1617, 3216, 3217 should work as well

1105

Yup, TK has pulled in most of my changes, so her branch (the primary) does include AVR 1-Series support. But I have a few small updates since then that she hasn’t merged back in. I’ve been keeping my branch up to date with her changes though.

Also as Tom said, while the 416 could be supported, there isn’t enough room. The 816 does work and I’ve used it for Anduril without stripping any features away but it is tight. And since the 1616 is pretty much the same price (within a few cents), there’s no sense in not using the t1616 instead. And yeah, the x17 chips should work as well.

A bit unrelated, but the t412 is somewhat of an interesting chip. It’s an SOIC-8 footprint with essentially the same pinout as a PIC12. There are several flashlights out there with a PIC12 (or equivalent) that can be swapped out for a t412. But since it’s only 4KB, that means no Anduril. D4 UI V2 works great though in those applications. I’ve done this to some Convoys, Sofirns, etc with great success. I just wish they made an t812!

1106

It looks like a lot has happened while I’ve been away! I’m glad to see everything moving forward though, and I look forward to getting an SP10 Pro or two when it’s available. :partying_face:

I’m a little confused about the clip though… and looking at some of the comments, it seems I’m not the only one. So I hope something can be done about that.

The planned clip is one of the worst types I’ve seen…

The problem with 2-way clips is, basically, instead of doing one thing well, it does two things poorly.

I usually find the most practical way to carry a light is in a “button up” orientation, so the part the user grabs to unclip the light is right next to the part they use to turn the light on. That way, there is no need to flip it around after unclipping it.

Another desirable trait is being deep-carry, so the light doesn’t stick out above the end of the clip.

So I really like clips like this:

Even better if the clip is captive, meaning it can’t be pulled off. The KR4 has a captive clip designed for button-up carry:

In addition, these two good clips also have the benefit of being smooth on the outside, with nothing protruding above the long section. That keeps them from catching on things, and makes them comfortable to wear when clipped against skin… like when clipped at the waist.

The front-end Olight style shown above also has the additional benefit of letting people clip it onto the brim of a baseball cap. I assume that style of usage is why the SP10 clip was changed… but to add baseball-cap mode, it was changed in a way which is a downgrade for virtually every other scenario.

But at least it’s not as silly as Olight’s new style. They had one of the best designs on the market, but a couple years ago they switched to one of the worst designs I’ve ever used. I can’t even imagine what the designer was thinking… did they want their flashlight to double as a money clip? Or perhaps they weren’t really thinking at all, and just reused a part from another light.

So, ideally, it’d be awesome if the SP10 could use a front-end one-way clip similar to the first Olight clip I showed here. That would be an upgrade for virtually all use cases.

If it’s not feasible to move the clip to the head though, the second-best option would be to give it a 1-way deep carry tail clip like JaredM posted. This seems like the most realistic way to improve it without having to redesign the host:

The 2-way clip could still be an option for people who want to use it primarily in baseball-cap mode, but for other types of carry, even the original 1-way clip would probably be a better choice.

Here’s how I’d rank the clip styles:

  1. :heart_eyes: Front end 1-way deep carry straight clip. (pic)
  2. :slight_smile: Back end 1-way deep carry straight clip. (pic)
  3. :frowning: Original SP10S clip (back end 1-way shallow, angled). (pic)
  4. :cry: The clip currently planned for production (back end 2-way shallow). (pic)

So I hope it’s not too late to upgrade that part.

1107

I’m not sure if it helps here, but some of the most recent code supports doing a PWM phase reset whenever the LEDs change from level 0 (off) to any other level, to ensure that the timing is faster and more consistent. This may help with party strobe, but it must be enabled as a compile option before it’ll do anything.

Yes, but I didn’t enable that until yesterday. Not sure if it’s enabled in the SP10 branch.

It looks the the poll was mostly “no, don’t auto-lock in simple mode”, but I’m not sure it was clear that it won’t by default. It’s just asking whether the light should allow that as a configuration option for people who know how to go to the advanced UI, configure it, and go back to simple mode afterward. It’s not something a new user could do by accident.

1108

1000000 % THIS.

1109

TK, the first two clips you pictured are approaching perfection.

Flashlight world. Take Note

1110

Huge thanks to you in return for providing this great place, SB. Without BLF, its helpful members and this great community as well as an enthusiastic manufacturer like Sofirn this project would not work.

1111

Great to hear from you again, ToyKeeper. My best wishes to you for a speedy recovery. Many thanks for your input. I have already sent Barry some recommendations for a better clip a couple of days ago. However, I took the chance to forward your thoughts to him to underline how important a good deep carry clip is for a true EDC flashlight. Fingers crossed that Sofirn will surprise us with something really cool.

I agree with you. The blame is most likely on me for confusing people with my poll. Unfortunately, the poll title had to be very short and I forgot to write some more explanations below the poll title. The only risk I see with auto lock in Simple UI is this scenario:

An experienced user sets up auto lock in Advanced UI and then lends SP10 Pro (set to Simple UI) to someone else who is not experienced (e.g. grandma, grandpa). The probability of such a scenario is negligibly small, though.

1112

Wow I saw this thread before but didn’t look closely enough to understand then. I’m psyched about it now.

  • Yes, I definitely want to buy at least one. I’ll trust the rest of you about ano colors and LED choice, and I hope it’s at least possible to mod in a different LED.
  • Is this similar to the SP10A in that there is no USB charge port? That’s ok I just want to clarify.
  • I’d like to urge use of ATTiny3216 instead of 1616 even though it adds a little cost, this being an enthusiast light. This is especially in the case that there is a USB port since right now Anduril doesn’t talk to USB, but in principle it could, and that will use code space.
  • The Anduril config I’ve messed with most is D4v2, which has lots of bells and whistles enabled and is about 9k of code on a 1634. TK has told me that it’s important to keep supporting the ATTiny85 which has 8k, which fits (but is almost completely full) at the moment, without the fancy D4v2 stuff.
  • It might be possible to free up around 0.5K of code space through some refactoring, at the cost of causing some pain to builds based on the existing codebase (the refactoring would have to propagate through UI code). 0.5k is not enough for really new major features of course, but it would let up a bit of pressure.
  • The D4v2 pogo pin thing is a workaround for limitations of the older ATTiny series. The Avr-1 won’t need anything like it and we should be happy about that. This light should only need 3 pins to reflash, and reflash procedure should be simpler. It would be great if an actual connector could be added for this purpose (i.e. JST-SH as used in Qwiic/Stemma stuff) but I can understand if board space is in too short supply.
  • The ideal setup IMO would be to have USB charging and also be able to plug the light into a computer with a normal USB cable, to play with the settings or to reflash. That gets rid of all the pogo pins and weird interface devices, but will need more code. The Avr-1 hardware helps with this though, and the 3216 would give more breathing space for the software.
  • The idea of an amber led to make a flickering candle is very neat and I hadn’t thought of it in connection with Anduril. I guess this light won’t have aux leds and using an amber main led just for that purpose would be weird, but maybe there could be an amber colored diffuser cap for the light, that you’d snap on when you use flickering mode. I see there is even translucent amber 3d printing filament that could be good for DIY’ing this.
  • I’m used to older technology flashlights and am well past my lumen junkie phase so I don’t feel any need for 300 lumens from this light. 100 is plenty. I say that because my main light right now is an 18650 with 100/300/1000 and I really only ever use the 100 lumen setting and it’s often too bright. Of course I know lots of you out there want max lumens and I’m speaking just for myself, but just saying there’s a mix. Unless there is a USB charger I probably won’t use 14500’s in the light. I’d stay with Eneloop with L91’s as backup or alkaleaks in emergencies.
  • It might even be nice to have an alkaleak mode which disables all the high power drain settings.
  • It will also be great to have CR123A/16340 and 1AAA versions of this light!
1113

This light does not have a USB port or a charging circuit, and it would not be easy to add.

It is very unlikely to benefit from using a bigger MCU chip, since it’s only running at ~57% capacity with plenty of room left to use…. and the bigger MCU would mean running at ~28% capacity with even more unused space.

An AA-sized light with built-in charging would be cool, but for a dual-chemistry design like this, especially in such a small host, it’s difficult to do. It would be a completely different project. This SP10 Pro project is mostly about taking an existing design and upgrading a couple relatively simple things inside.

1114

Looking forward to an Anduril AA with multi cell chemistry support!
Will definitely pick up a couple. L91s are important for me when on the mountaintops.

1115

Personally I never use built-in USB charging. I have Wurkkos FC11, Skilhunt M150 and H04 and I always charge their batteries in a Nitecore charger.

I find it’s more practical to swap to a spare backup battery and continue using the flashlight rather than having your light out of action because it is in charging mode.

It’s a nice feature to have for emergency charging on 18650’s or 21700’s but for AA sized flashlights I think it’s not necessary.

1116

> This light does not have a USB port or a charging circuit, and it would not be easy to add.

I see, well maybe a future model then. I think it is worth aspiring towards.

The Avr-1 is like the Atmega series in that the flash memory can be partitioned into a boot loader, app, and data. Having a boot loader could allow application upgrade through I2C or similar (I think you were the one who explained this to me) but that would add some code. I think the traditional Arduino boot loader is 2KB so maybe that’s a reasonable amount, though I’d expect smaller is possible.

The 1616 has plenty of space for the existing app plus some enhancements, but if the 3216 doesn’t add significant cost or complexity, I think we can find things to use it for. The price difference on microchip.com seems to be about 20 cents. We could even use the extra flash area for stuff like logging, if we didn’t want to put code in it.

> I find it’s more practical to swap to a spare backup battery and continue using the flashlight rather than having your light out of action because it is in charging mode.

I don’t find this myself, at least with my Fenix BC21. It flashes a red light when the battery starts getting low, but I can keep using it for a while. So when I see the red flash I just remember to plug the light in later that night, before going to bed. It’s similar with a mobile phone. I hate phones with non-swappable batteries, but even with a swappable battery I usually just charge the battery in the phone before going to bed. Taking batteries out of the light is just another clumsy operation that I’d rather avoid. Even professional users like LEO’s in the incan era traditionally charged their lights in charging cradles, rather than swapping battery packs around.

1117

The t1616 leaves us plenty of space for future development. The t3216, as much as it may sound like a good option, is only offered in SOIC20 (large!) footprint, not the 20 pin QFN footprint of the t1616. We could move to the t3217 if we needed to for some reason but that’s a larger QFN chip (4x4 instead of 3x3 mm). The code would port easily (just more pins) but PCBs would need changed. Maybe someday we’ll need it.

1118

I think this flashlight was designed to have the features of the bigger lights like the D4V2 but with the practicality of readily available AA sized batteries. If it was 18650 or 21700 USB charging then I can see how that would be really useful, but I think USB charging seems kind of redundant on a AA light.

1119

Oh! Ok, that is a good reason to stay with the 1616. If it was just the 20 cents (even translating to $1 in the finished light) I’d very much think it was worth it.

That is interesting about the 3217 but I agree we don’t need it, and it seems too big for an AA light. I’d find it of interest in a D4v2-style light which already uses(?) the 4x4mm t1634, and for which we can always use more i/o pins since it has so many aux leds and so on.

Do you think there is space for a JST-SH connector? It would be spiffy to have the light be a Qwiic device. It is about 4x6 mm: JST SH 4-pin Right Angle Connector (10-pack) [Qwiic Compatible] : ID 4208 : $3.95 : Adafruit Industries, Unique & fun DIY electronics and kits (drawing pdf linked where it says “diagram”). Then you could plug it into a usb-dongle style microcomputer board (Adafruit Trinkey QT2040 - RP2040 USB Key with Stemma QT : ID 5056 : $7.95 : Adafruit Industries, Unique & fun DIY electronics and kits), Raspberry Pi Pico, or whatever. If not, maybe a pogo pin contraption could use this 4-pin interface (power, gnd, tx and rx i2c).

1120

There is not space for a JST-SH connector. I’m not sure if you’ve looked at the driver area of an AA-based light before, but there’s really not much room at all there. That said, the driver was designed with programming pads. You use an adapter like this one to connect to the programming pads (note: that is the original design of the programming key, I have since then rearranged the pins so that ground is in the middle… it’s a bit safer that way in case you flip the key the wrong way). UPDI programming (native for the the newer AVR chips) only uses 3 pins: power, ground, and UPDI. Technically, if the driver is already powered (connnected to a battery) you only need to hook up the UPDI pin. No sense in trying to mess with i2c programming or anything of the sort.