<< Lume X1: 40W Single-Cell Boost Driver with Anduril2 and UDR >>

Thanks ToyKeeper, your diagram is instructive and explains it well.

I'm not sure if I explained myself well; Lume X1 helps with the lower part of the ramp table in that the lower values are not rounded off to their nearest integers; i.e. in the Lume X1 ramp table, all values of each of the 150 levels are different. However, because there are only 150 levels, each jump from level n to level n+1, is still noticeable, especially at the lower levels (at least with a x^3 curve). We can increase the smoothness of the curve by adding more intermediate values (e.g. more levels), but I have not done it yet because adding more levels increases the ramp up and down time (and AFAIK, it's not a straightforward change to change each tick duration).

When I have more time, I'd like to try out some different ramp curves and ramp lengths though. Browsing available literature, it seems like there is a guideline that Perceived brightness = Sqrt ( radiant flux ), so I'll be trying out those kinds of curves, which flattens out the lower end, making each step less at the lower end (where my eyes seem more sensitive), and larger at the higher end.

icpart and thefreeman, interesting discussion, I'd like to try it out to see how it could improve performance. :)

Yup - it takes about 4,000 lumens to seem "twice as bright" as 1,000 lumens. This square law is why I abandoned my hot-rod mod quest after I built a light that should be doing 10k+ and couldn't really tell the difference (especially with radically different lux values) to my ~7,000-8,000 lumen light. I figure I'd need to crest 30,000 to actually start caring about the difference, and I'm not ready to build something with the proper combination of size, active cooling, etc...

Of course, we have the same issue with throwers, where throw is proportional to the square root of candela. So to get twice the throw of a 1,000,000cd light you need 4,000,000...

Very impressive, the looks with the Olga… :open_mouth:

Amazing work - another level. I feel I’m peering into the future of flashlights. Hopefully the near future!

Although it wouldn’t have fit this exquisite Olga optic, I would like to call some attention to the uncommon Lumintop FW21 (non-Pro), a light which I thought was unfairly dismissed upon release. It was an FW3A scaled up very slightly to fit a 21700 cell - even smaller than the SC700d in all dimensions. The body had rather superflous trit slots, and it advertised the same 2800lm max output as its smaller sibling. Furthermore, early production examples (mine is one of them) have an extra-long body tube that only works properly with protected 21700s. Still - it fit a 21700, while being the same size as a Noctigon KR4. I wish more work had gone into its development.

That’s exactly the thing: Lumintop just did it, and as with most of the rest of the stuff they just did themselves, it came out pretty poorly. Even the original FW3A never got the manufacturing quality we wanted from Lumintop, and they’ve continued to “cost-optimize” it and all its variants ever since.

I can only recommend the FW3A with caveats these days, and the rest of the lineup I can’t recommend at all in good conscience.

Yes, it is almost exactly what BLF flashlights have been doing since ~2014 or so. But most BLF lights only use the extra resolution in low modes, because that’s the only place the resolution is perceptible, and because it eliminates the hassle of dealing with variable ratios between power channels. Like, the size of the FET channel’s steps changes throughout the life of each battery charge, but the 350mA channel’s steps stay pretty constant. So adding them as shown in that link results in step size alignment problems — like shown in my diagram where the 20 mA channel and 5A channel produce different shapes depending on voltage.

The next thing I hope to try is a different method entirely… combining PWM with DSM (delta sigma modulation). The effect is similar to increasing the bit depth, but it doesn’t have the downside of slowing down the pulse rate. Basically, instead of doing a value of 5 / 9ths as “111110000”, it encodes the value as “101010101”.

So this would effectively enable 15-bit or perhaps 16-bit digital resolution on an attiny chip, while still pulsing at ~16 kHz. The main problem is that it’s more difficult to implement, since it requires doing some math and adjusting the pulse width on each pulse cycle. So it needs extremely tight timing on an interrupt which fires off rapidly.

The other difficulty of increasing the digital resolution this way is that it would require some changes to the abstractions on which Anduril is built. Some of the code, like the “set level gradually” mechanism, works by adjusting the output in hardware-resolution steps of 1. It works for the current set of lights, but it would be way too slow when the resolution is increased. Some of the underlying code would need to be rewritten to change from abstract ramp steps to actual hardware power levels… and that’s tricky.

Thanks for the comments everyone!

ToyKeeper, a nice idea, but like you mentioned, could be a little tricky to implement in code to achieve the desired performance. I'm not sure if a PSOC (they come in a 2.3 x 3.2mm BGA for the 4200) has sufficient programmable logic blocks and peripherals to implement it on chip, but I suppose it's not a realistic scenario since we're working with ATtinys for now. But it's an interesting approach for sure.

Scallywag and 000-Bluefire, I think the FW21 was a decent flashlight, but like you said, it felt a little like a copy and paste. I had one for a while and had palnned to use it for a prototype, but I sold it in the end because it was a little too similar to the FW3A and didn't really offer anything additional other than it holds a 21700 cell.

Speaking of the FW series, I have a FW1A on hand... wondering if you all think it would be a good idea to put a Lume X1 in it, with say a XHP70 LED, or even an older but fun MTG2!.. (anyone know any drop-in TIR replacements for the FW1A aluminium reflector?).

I recently got a Amutorch E3 (which looks like a Zebralight copycat), but I like the idea of the side switch, unibody machining, and very compact size for a 21700.. could be a good candidate for the Lume X1. I wish more manufacturers went with this kind of unibody design, but preferably not copying Zebralight since many manufacturers have shown that they are capable of good, original designs.

Gchart, I started working on a 1616 or similar proto, thanks for the work you've put in! From what I see it looks like Anduril1 has been ported over; has Anduril2 been done as well? I could have missed it..

This bzr repo was branched from TK’s anduril2 branch. It should have all of the Anduril2 goodies running fine. I’ve got Anduril2 loaded on several t1616 flashlights. I haven’t tested it with RGB Aux yet, but the code is there. To my knowledge, that should be about the only untested thing. This is same repo that I had linked to previously, but I changed the name/url today… I’m relatively new to bzr and I didn’t realize that I didn’t have it linked back to the main Flashlight Firmware Repository properly.

Amutorch 3 looks good only from outside but its not really good option for powerful boost driver modding. PCB have fixed button and 2 holes and bad contact with host

Thanks! I'm going to take a look at it.

The fixed button looks perfect IMO; for the manufacturer it allows lower part count cost and simple assembly. Though from what I saw of some teardowns, it uses a RA switch instead of a board in-line design which would be more robust. As for the contact with the host, that is true, but I think it could be mitigated with some brass screws or hard gold plated ones (ideally they would mill out the anodizing for the shelf which would also help). I won't know until I see it in the metal though..

Loneoceans, I have a bunch of exact diameter TIRs I can send you. They might be short by a mm or two, but I’ve seen you make easy work of that before. I haven’t been happy with their performance, but they’re free to you. PM me and I can ship them over.

…specific PCB shape it will fit only this flashlight ;))

If this driver technology would be implemented in close release serial flashlights? Name, o sister!

The thread above is from Lume1. I modded FW1A with the optic and Lume1 with AUX LED’s. That optic is Ledil 10613. It is about 3mm shorter than the stock reflector. The holder which came with the optic needed to be modified. But, it worked. It can be used with Cree MC-E. So, large LED’s should fit. The beam will be wide/big hot sport.

I like the size of FW1A, but it is thermally limited. I am not sure if it can handle the maximum potential of Lume X1.

Well, it’s not this fancy boost driver with “UDR”, but Loneoceans has the attention of at least one manufacturer actively (not my image, link to post) for what appears to be a very nice 6A buck + FET driver with Anduril2.

OMG Yes!

FW1A X1 withFC40 would be a spot on.

Even better IMO would be the B35AM Nichia in the FW1A and light pebbled, narrow TIR or a 21700 KR1 (would thinner straight battery tube create enough girth for 21mm cell?)

And honestly, I’d rather run this in a triple FW3A in series rather than a parallel with the Lume1.

PSOC 4000 goes down to 1.45x1.56mm BGA. :wink:
I also think that the effort to port FSM would be high compared to the benefits though.

This looks a great driver, as far as it requiring an E-switch, does this mean it could be installed into a convoy host with a tailcap mod in much the same way as the GXB driver does?
The RGB LED support looks pretty cool too!

But this would be still linear driver, where difference between Vf and BattV would be fired on the chip?