Discussion: Sofirn LT1S Pro (Anduril tint ramping + Red)

Sofirn has approached me to see if it is feasible to create an LT1S Pro that uses Anduril 2 for the UI. My initial reaction was “yes!” but then the idea crept into my head that I’ve not seen a 3-color Anduril implementation.

Tint ramping with Warm White + Cool White has been done several times. But how to mix in the Red LED control? What should the button mappings be? What functions need to be available for the red LED? I’d like to open this up to the forum to get your ideas.

2 Thanks

First question: Should it also allow switching between the two halves (front/back) like the current LT1S? The LT1S has five channels: Two for each white and a fifth channel for red. My suggestion would be to add a channel selector / mux after Anduril so that the only modification in Anduril is to add two control lines to control the mux.

Red channel: I see two possibilities. Either add a new special red mode like 2H from off (who needs momentary turbo for a lantern anyway). This mode behaves similar to ramping mode, but duplicates only basic functionality required for ramping. But still a lot of code duplication with the current architecture of Anduril.

Second option: Use the mux. Don’t switch between all sectors, front sector, rear sector, but add red. This would allow red to be used for all modes including SOS, battcheck etc. Very little modifications of the code required. Anduril will still output two channels, but they are either routed to all LEDs, one half or to the red channel. Shortcuts to switch between sectors and color can be different, like 4C from on to switch sectors and 4H to toggle color.

This is all from a technical perspective, of course. But the maintainability of Anduril makes it necessary to think about how changes in the UI can be implemented. While a fork might be easier, it makes the Anduril ecosystem even more confusing. Thus I suggest to keep the changes as minimal and compatible with the rest as possible.

I can help with development if you like. But I think we have to agree on the hardware design first and get some prototypes ready.

PS: To reduce cost it might be possible to implement the mux in the MCU itself with more or less isolated code. Not sure if the PWM output muxing capabilities of the ATtiny is sufficient. The setup is already done in the hw-config file. We could add a function to that file to change the mux config on-the-fly.

Having never owned an LT1S, I had forgotten about the front and back selections. I wonder if people actually like that? Or is it more of a gimmick?

I like your thinking! If we stick with 8-bit PWM, we could do up to six PWM channels on TCA0 and mux them mostly at the CPU level, hopefully with minimal code changes. I need to pull up the source and see what’s feasible.

With this idea of using the MCU port-mux functionally, I think it could be reasonable to do warm/cool ramping plus red, but I think front/back switching might be a lot more difficult (in regards to minimal changes to the source code).

I’d love the lt1s with anduril, but agree it’s functionality that’s not in anduril yet.
Personally I’d settle for the form factor, with lt1 functionality, but I don’t think that’s the point here.

Bonus points if you sway them to 519a though.

I think it is a very handy feature. Currently I have to block one half with this shade: https://www.printables.com/model/227948-blf-lt1-sideshade-shade

I haven’t checked the available PWM configurations yet. I’d really like to see higher resolution for the white channels. The red channel should be fine with lower resolution (and lower max output).

I don’t think it is that difficult. Tint ramping won’t be changed. It controls two PWM outputs as defined in the hw-config file. The same PWM output generation (higher level code) will be used for the red channel. So up to this point you have two PWM outputs.

Now add some kind of muxing that is controlled by an additional function, e.g. “output_mux(channel)” defined in the hw-config (for now). This function can be called to route the PWM output to either white-all, white-front, white-back or red. Code for the red channel has to combine both tint ramping channels, tbd. So far these are mostly changes in FSM.

In Anduril itself all you have to do is to add button mappings to call output_mux().



Yeah, a short LT1 would be great as well, but if we can add these features with not too much work, why not?

The LatticePower CSP LEDs aren’t so bad. I haven’t seen them in the LT1S, but in the Wurkkos TS10.

SammysHP (and anyone else interested): I have this tentatively built into the Anduril source code. I pushed it as Build 625 in my branch.

I noticed that the Noctigon K9.3 has some special code called “set_level_override”. So the framework was already there for doing special stuff with the output channels. The only change to Anduril that I needed to do was to create a new global variable output_mux, be able to load/save it in eeprom, and override the 4C while On to rotate through the mux options.

I don’t have a sample light to test this on, since it is still being designed. But I’ve seen a driver schematic, so work is being made. I’d love to get more eyes (and opinions) on this. As a side note about the front/back switching - Barry said he’s not a fan of this feature and Sofirn has decided to remove that. So we simply need to just mux between white and red.

Sorry guys, Im just an average user with zero technical knowledge, so this is just ordinary user suggestion. I applaud the idea of a lantern with WW plus CW plus Red plus Anduril. But as an average user, I would definitely add a second button: so, one button for WW and CW and their tint mixing. And second button for Red only, eventually for mixing Red with White.
Just my two cents…

The thing about a lantern used for camping is that they 100% need to be usable by an “average user with zero technical knowledge”. At some point in the use of a lantern, the brightness/mode will need to be adjusted by people other than the owner of the lantern. Unless every person buying these lanterns is camping alone.

Two buttons aren’t even really enough. Dedicated brightness up/down buttons and a red mode button would be ideal if Sofirn is planning to start marketing their lanterns for camping.



in order to ease use and save switches It may be useful to add a voice control.
I did some experiments in dual channel driver and was very happy with the results.
IMHO voice control is very convenient for a lantern since most of the time you don't hold it in your hand.
Not sure how can it be integrated into Anduril though

Before everybody is asking for voice, 100w laser interceptor against mosquitos, 5 million buttons and a massage feature - please stop.

The small attiny microchips running Anduril have like 8 or 16kb of program memory to use. You won’t get smartphone functionality into that chip.



I have suggested it after successfully building a prototype driver.
Yes it is not running on Attiny85 but on ATmega328. it is bigger but still relatively small and with low power consumption. I see no reason why it can not be done in a lantern.


Yes sure. A can opener, a bottle opener, a cork screw and of course a compass would be nice as well. Always add a rubber band and some meters of cord.

Nah, seriously, who needs a lamp that spntanously switches while people around are chatting and talk”commands” unintentionally by accident.

BTW: a good flashlight is an excellent beer-bottle opener, anyway. Gives a distinct patina.

1 Thank


Probably the same people who use Siri, Alexa and Google Assistant...

I don’t have any technical knowledge, but I was just planning to buy The LT1 mini or the LT1S, but I don’t know which one.
I am afraid that LT1-mini is not stable enough because the tube is not that wide, and the LT1S does not have Anduril, but I like the form factor better.

So a LT1S with Anduril sounds very nice and I would definitely be intereseted!

What about the good old potentiometer?
In a lantern this could be quite useful to have a few little potentiometer knobs to modify light paramters.
Even if they protrude from the base or top al little, they won’t be in the way like on an EDC light.
Let’s say one for the cold LEDs one for the warm, one for the red, each going from 0 to 100%.
The controller of the light could be made even in an all analog circuit, without a CPU.
Modern CPU can handle this even in standby, calling the ADC once in about three seconds in dozed standby, or with comparators triggering a wakeup signal.
Or another potentiometer, setting the “opening” segment of the round light without using a physical shade. This could be used to turn off the light altogether by “closing” the light, so only one ADC or comparator to check in standby if the controller is made with CPU.
Maybe an on-off button, conserving a setting for the next time, switching from off-half-full-off.
Very good would be an off-timer as well, in case the lantern is used as a reading light, etc.

BTW: Axis of a dampened potentiometer can be considerably waterproof to splash water, especially with o-ring added, so not to ruin an IP rating

I bought an LT1S and was very satisfied with it to the point that I ordered a second one.

I like the current interface as it is and I think that for an ordinary person it is already too complicated, if he had Anduril it would be even worse.

Personal opinion: the LT1S is fine as is everything seems perfect to me, in a future version I would like only two additional light levels.

An additional withe moonlight level in addition to the existing one with an even lower value (0.2 lumens)
An additional red level in addition to the existing ones even lower (1 or 1.5 lm)

Absolutely.

A lantern is — by its design — a light shared with multiple people.
Complex controls make no sense in this context.

1 Thank

I use the front and back selection on an LT1S quite often, but only to turn it away from me and bring the light level down below minimum. I’d love to see lower lows on this updated model

I know it’s a little off topic but please ask them to make the PRO Version with warmer tint! It makes the camping much cosier and attract less bugs. Nobody needs a lantern with a 5000k or more. The ideal tint ramping for a lantern should be between 1800k and 4000k.
One feature that I like from the anduril is the timer. Would be nice to set a timer and go inside the tent.

I had previously been thinking about button mapping for 3-channel mixing. Here’s what I came up with. I’m being a little bit verbose to try to be precise, but I don’t think it’s very complicated in terms of actual use:

Basic logic: The channel boundaries are controlled similar to the existing auto-tint control. Once the ramp reaches 100% of a channel, the light blinks and stops ramping the tint, and starts a timer (~1 second, I think?). The existing logic is if the button continues to be held until the timer expires, auto-tint is activated, with the channel currently at 100% as the low power tint. I propose a new action where if the user releases the button before the timer expires, and presses the button again before another time elapses, the new action is triggered. I see two ways this could be implemented:

Option 1: Continue to hold to continue ramping into the next channel once the first timer expires. Release before the first timer expires to maintain the current tint. Release and then click before the second timer expires to toggle auto-tint. This makes ramping across the full tint range more natural, in my opinion.

Option 2: Continue to hold to toggle auto-tint once the first timer expires. Release before the timer expires to maintain the current tint. Release and then hold again before the second timer expires to continue ramping into the next channel. This has more commonality with the current Anduril 2 logic (continue to hold = auto-tint).

I don’t have an opinion whether auto-tint should ramp within the current channels only, or across all three channels. I actually have a more complex idea that is not well thought out, but am not ready to share it unless there is interest in tinkering with the auto-tint feature.

Note: this isn’t necessarily limited to red - warm white - cool white mixing. The same interface in a triple-emitter flashlight could mix between warm white and cool white flood LED’s at first, then once you’ve reach all cool white, mix between cool white flood and cool white throw (Osram W1 or XP-P). Or it could be mixing RGB (caveat: R+G or G+B, but if R+B is desired to get purple, the ramp needs to be extended so that from 100% channel 3, it can roll over to mix channel 3 with channel 1). The same logic could even be extended to 4 channels for a W + RGB light, which combined with the rollover idea I mentioned for R+B ramping, could mimic both extremely warm white and extremely cool white tints.

However, I’m getting ahead of the current concept, which is 3 channels. Or actually 5 channels for the front and back feature, but the mixing ratios remain the same (or 0 if one side is off).

The current LT1s cycles this using 2C from on. There is no shortcut from on to max. This would be an option, but inconsistent with the current Anduril logic, so I think 6C from on is currently unused.