【Group Buy】LT1S Pro with Anduril2, Nichia 519A + 660nm Red LEDs

Commercial Sellers' Spot
264

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
265

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.

266

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
267

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
268

Good news! The first batch will use nichia 519A LEDs.

13 Thanks
269

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
270

Probably a good choice. I don’t remember the last time I used 4C from on. It’s meant to make lockout more convenient to use as a safer version of “off”, but I pretty much never use it. Instead, on lights which need it, I just set an auto-lock timer.

I wonder if it should use 3C for channel toggle, 3H for channel ramp, and 4C to toggle smooth/stepped ramp style. I think it would make more sense, on lights which have independent channels… but it would be awkward on lights with only 1 set of primary LEDs, which is most lights.

I’m also wondering if I should make the tint value 16-bit instead of 8… where the lower 8 bits represent the tint, and the higher bits select which pair of channels are being ramped between. Or perhaps just use two 8-bit numbers. Not sure which would result in a smaller compiled size.

271

Exciting! Looking forward to getting my hands on one of these soon!

272

I’m going for one of these Nichia. Will the different colors be available in the launch versions?

273

@ToyKeeper Just make sure to merge my stepped tint ramping branch first because I guess it would be a hell of a rebase for me otherwise. :rofl:

1 Thank
274

Interested

1 Thank
275

Welcome on BLF !

1 Thank
276

There are enough branches to merge right now that it’s probably going to be messy no matter what I do… especially for tint-related stuff, since that entire part of the code probably needs a rewrite to handle the variety of multi-channel lights being produced lately.

More thoughts on it are here.

I think it may need multiple different tint algorithms which can be inserted into fsm-ramping.c at compile time, depending on the hardware type. It may also need multiple different 3C+3H handlers (tint-ramping.c), selected at compile time. The idea is to make the interface as consistent and convenient as possible, while still working on many different types of lights.

Like, on a cool+warm+red 3-channel light, perhaps 3C would rotate between 3 different tint modes:

  • 011: warm+cool tint ramping + auto-tint modes
  • 100: red only
  • 111: red+warm+cool ramping, in a circle

There are 8 total combinations, but only 3 seem like they would be useful on this particular light… so I’d probably have a tiny array somewhere with those 3 values, and 3C would rotate through the array.

I hope that makes sense.

The channel bitmask approach is just an idea for now, but I think it might help facilitate a wider variety of hardware with a variety of different needs. Like, a light with white, red, and UV would have modes 001, 010, and 100… because it’s not useful to have 2 or more active at the same time. Or a light with flood and throw LEDs might have 01, 10, and 11 – flood only, throw only, and ramping between.

Edit: In practice, the flood+throw interface would probably be:

  • 3C: toggle between flood-only and throw-only (01 and 10)
  • 3H: switch to ramp mode (11), wait a moment, then start ramping

Something similar could be used on the LT1S:

  • 3C: Rotate to next tint mode (white ramping, red only, red+white ramping)
  • 3H: Ramp tint. If in red mode, switch to white mode, wait a moment, and start ramping tint.

But since these are different, it would need some compile-time magic to select appropriate interface code.

1 Thank
277

Is there a ETA on 519a LT1s and how many will be produced in the first run?

3 Thanks
278

Interested

279

Very interested.

1 Thank
280

Welcome to BLF!

1 Thank
281

Welcome on BLF !

282

Can’t see the pics??

1 Thank
283

Yep, me neither. :thinking: