Interested, especially if there can be a 519a limited edition, don’t like the low R9 of LH351D.
Same flashing pads as SP10 pro and LT1 mini?
1 Thank
Pretty disappointed there’s no 519A, but it’s out of your control it seems. Thanks for your efforts. The 519A was the most compelling thing of the LT1S Pro for me though, so I guess I’ll be waiting until hopefully supply can be secured and a 519A version will be released. Maybe a small limited edition production run would be nice though?
1 Thank
Hey there, thanks for letting me know about your preference for the 519A version. I meant that obtaining the 519A version is not difficult, but it is a bit challenging to procure the 2700K 519A LEDs. We’re doing our best to make it happen for you. We’ll keep you posted on any new developments.
6 Thanks
Yes please use 519a leds. And allow flashing pads
2700k is the best 519A 
Hi Sofirn. Not regarding the LT1S Pro but some of us noticed new lights on your aliexpress store (but not shown on the Sofirn website). It looks like the pages for both models have been taken down, but are you able to tell us anything about them?
SP60 : New Sofirn SP60 thrower using 2S cells
SC02 : New Sofirn sc02.
I think a lot of people would like to know more! 
1 Thank
Can you dedome the 2700k LH351D? That drops the CCT to make it closer to a candle flame and makes the tint less green. But the 519A is better. E21A 2000K would be PERFECT.
1 Thank
LH351D are not as easy as the 519A to dedome, I don’t think a big manufacturer like Sofirn would be able to do it. E21A is also very pretty but low output, I think 519A 2700k with a DIY dedome (around 2200k) might be best compromise between availability and CCT/tint.
Neat!
I’ve been out of the loop, didn’t know it existed until today… and now it’s almost ready to launch. 
It sounds like I should get in touch with @gchart to get the latest version of the code merged in upstream. It would also be helpful to have hardware to test on to make sure I don’t break anything during merges or updates.
3 Thanks
@ToyKeeper
I noticed my Wurkkos TS10 has a model number which isn’t in your models.text
0714
Firmware: 2022-07-19 0714
TS10 sent direct from Wurkkos 2023-01-31
I found 0714 on: gabe on launchpad
(I gues it is GCHarts)
It seems the numbers 07xx are for Sofirn/Wurkkos lamps
Maybe @Barry0892 knows more?
Maybe it is a good idea to have the link to Gcharts model.text mentioned in your models.text?
Or a hint like the 07xx models are mostly handled by Gchart?
2 Thanks
It’s an auto-generated file which pulls data out of the repository’s build targets to generate a list. I just need to merge changes more often, to keep things more synchronized and up to date.
3 Thanks
I‘m interested too!
2 Thanks
@ToyKeeper I hadn’t heard much of anything in the past couple of months, either. I honestly just figured the project might have died.
I just merged in your most recent changes. There were some conflicts, so I need to run a couple of tests before I push them. I agree… having some hardware to test the LT1S Pro code on would be good. I built the hex and sent if off to Barry, but I’ve never been able to test it myself.
2 Thanks
Yeah, that’s what I’m worried about.
I think I need to rework how multi-channel* lights work, again, because the current design has a bunch of issues which make it a pain to deal with. And the LT1S Pro would be a great host for that, since it has 3 separate channels.
* “multi-channel” as in multiple sets of primary LEDs with independent power control
There are a bunch of different hardware and software configurations to cover, since lights can have 1, 2, or 3 independent sets of LEDs and some need multiple channels active at once while others are one at a time, some need full power on all at once, while others need relatively constant current regardless of the blend, some might need a combination of tint-ramp and tint-toggle, etc.
Anduril wasn’t originally designed for this sort of thing, so it has been an awkward fit. It went onto 3H because everything else was already taken, not because 3H is a good interface for it. And the config options went into an obscure menu for similar reasons… there wasn’t a better place for it.
It probably should have a second button or something… one for regular Anduril functions and one for channel control. But that isn’t physically available, and the code also doesn’t currently support a second button. So it’ll remain awkward… but I hope I can at least make it less awkward.
2 Thanks
Maybe keeping 3H for the 2 CCT-ramping channels and 4H for third red channel?
I can’t imagine many cases where one would want to have ramps between 3 channels other than an RGB (or CMY) flashlight, but there’s probably better suited UIs for that than a single button.
Yeah. I’ve grown accustomed to the 3H for CCT ramping, but trying to add another channel made me scratch my head a bit on how to not rock the boat too much and without rewriting a bunch of stuff. So this is designed with 4C from On (previously Lockout) rotating through any available “output mux” offerings. So for the LT1S Pro, it would just rotate between white and red, distinctly. While in white light mode, 3H should work as usual.
I’ve gone ahead and pushed my updates. The only conflicts were really around single-color aux. I’ve been trying to keep my branch up-to-date with yours, so it was only your most recent update that I had to work in.
On a side note… I sure hope Sofirn kept the fairly standard 3-pin flashing pads and made them accessible. @Sofirn can you tell us if there are flashing pads? And a picture of them, perhaps?
1 Thank
It seems to me that making channel ramping continuous through the channel boundaries would be possible while keeping the same basic button configuration.
For example, ramp from cool white to warm white. At 100% warm white, the light blinks, and if you continue to hold, after a moment it still switches to auto-tint like it currently does. On the other hand, if you release and hold again within a short time, it begins to ramp from 100% warm white into red.
The basic principle could be extended to even more channels if that ever became relevant. And it could be a loop, so that at 100% red, if you immediately release and hold again, it begins ramping from 100% red into cool white (or where I think it would be most interesting is if anyone ever tries to make an RGB Anduril light, although I’m not sure how one would mix more than 2 channels at the same time).
I know it won’t affect the LT1S Pro. I just thought I’d bring the idea up for general consideration.
2 Thanks
Good news! The first batch will use nichia 519A LEDs.
13 Thanks
Same.
To @Barry0892 and/or @Sofirn, it’s worth repeating that lights need firmware reflashing pads in a standard arrangement. Nonstandard pads (or no pads), mean the lights will not get firmware updates. This makes maintenance and development painful, and also reduces the value to customers.
The later versions of LT1, plus the LT1M, use nonstandard pad layouts, like shown in the picture below. Could you get a message to your circuit engineer(s) that the reflashing pads on every light must fit the standard flashing adapters?
Additionally, if at all possible, Sofirn really should sell flashing kits. For example, @gchart designed a nice 3-pin adapter for Sofirn’s attiny1616 drivers. If he agrees, Sofirn could probably make and sell those.
Pic: LT1M pads are too close together to fit a standard pogo pin adapter:
4 Thanks