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

117 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 2 hours 22 min ago
Joined: 08/19/2012 - 08:23
Posts: 14043
Location: LI NY

loneoceans wrote:

Quadrupel wrote:
1616 is more recent, *3x3mm* , cheaper and have everything we need.

Not a bad choice, and has a bunch of extra peripherals maybe I can take advantage of for future designs. 3x3mm QFN is useful for smaller drivers (e.g. 17mm), 3216 will have more flash for more features too. Thanks for the suggestions! 

As gchart said, Anduril2 support is now available for the 1616 - many advantages. However the 3216 does not seem currently available in the 3x3mm QFN format - not in the specs or available from suppliers.

loneoceans
loneoceans's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 01/08/2017 - 00:18
Posts: 282

Here's a quick video of the general functions of this flashlight, mostly showing the Aux LEDs and how Anduril2 functions with the Lume X1.

Thanks everyone for your continued comments and suggestions, please keep it coming.

Gchart and Tome E, thanks for your efforts, most likely for any drivers or revisions going forward I'll pick up the 1-series MCUs and I do have some new ideas for them! It's so great to have talented friends like you all working on making improvements. Smile

icpart and thefreeman, using a high resolution or high precision part is expensive and significiantly drives up the BOM cost, and fortunately I managed to avoid using any of those components to enable the system to have a high dynamic range; not based on component precision but by system design. thefreeman, yes! I am actually using multiple sense resistors similar to what your drawing shows! I had the thought of trying it out last year but it took me some time to build a prototype, and there are a bunch of traps I had to work through with control and stability to make the entire system work well. I encourage you to try it out and see what works well though I can't speak for the linear FET version. On this topic, check out the Thrunite T2 which someone alerted me that was another nice new flashlight similar to what I'm trying to achieve with the Lume X1.

In the photo above, what struck me was that I see a few big resistors. I don't have this flashlight so I can only guess from the photograph that they're implementing something similar... or maybe not at all... just a guess. 

Will34, 94Z28, For the driver and LED aux PCB, they were designed specifically for this unusual build with a modified KR1, so I'm not exactly sure how practical they will be for most general builds. The Lume X1 is a general topology and easily adaptable to other flashlights, and I plan to design one for either a more general use or even better, if it can be incorporated in a flashlight. I'm thinking of doing some little adjustments, and trying out some new ideas with the newer AVR-1s... so I'm hoping for more to come soon (we'll see how much time I get to work on this since I've actually been super busy recently!).

ToyKeeper and iamlucky13, while the resolution is good at the low end, actually the ramp itself isn't quite as smooth as you'd think and it looks roughly the same as my regular AMC7135 drivers, mostly due to the 150 default levels.. I haven't really played around the ramp values yet I generated my ramp table like a x^3 curve. It seems like the smoothness of the ramp at the low end is is affected by the 150-level limit in Anduril (it's possible to increase the number of levels, but the ramp duration would increase, and each ramp level duration is controlled via a 'tick' in Anduril and it's not easily changeable at the moment without affecting the rest of the system (AFAIK from a cursory look at the firmware though I could be wrong). In other words, something like 1500 levels and 10x shorter tick times will make a smoother curve and the Lume X1 has the hardware to make use of it. Regardless, I'm thinking of trying out some other kinds of curves like higher polynomials or exponentials (which I think may actually like better), and will also make the gaps between the levels at the lower modes tighter and look smoother. 

www.loneoceans.com/labs/

- Next-gen Switching Drivers: Lume X1 and Lume1
- High Power Boost Drivers: GXB100 GAN 100W, GXB172 17mm 50W
- Older: GXF22, GFS16, GXB17 & GXB20

thefreeman
thefreeman's picture
Offline
Last seen: 6 hours 19 min ago
Joined: 01/06/2020 - 09:56
Posts: 473
Location: France
icpart wrote:
Any additional info about this nearly impossible dynamic range will be welcome. It will be very interesting for many of us. I think is used also full potential of 16bit timer. With current Abduril firmware is possible to get 10bit resolution. Here we talk for something like 20-24bit resolution. It used external DAC maybe? I can’t see how it is possible to be achieved with that attiny1634. Also submicro current measurements need also high resolution or larger shunt resistor.

Yes please, especially if this is better to the solution I came up with (probably Big Smile ) :

Here this is with a linear FET topology but the same applies to a buck or boost topology (inputs of the OpAmp would be reversed and output goes to FB of the converter IC)

By turning ON or OFF Q3 the shunt resistance is either ~10mΩ (R12+Q3RdsON) for the higher current range or 5Ω for the lower current range. Here with a reference voltage of 50mV that translate to a maximum current of 5A or 10mA respectively.

We know that with this type of circuit 10bit~1:1000 dimming can produce flicker (noctigon KR4, lume1), probably due to noise as the sense voltage become so low (with a 50mV shunt/1000= 50uV). So if we stick with 1:500 dimming we can go down to 10mA on the higher current range and 20μA on the lower current range, achieving 1:250000 dimming, less than 1:10 millions sure but I mean, both are already way sufficient anyway.

Here is a simulation :


Red is current and green is Vsense.

At first Q3 is ON so we’re in the high current range, then we dim to 10mA
At 9ms Q3 is turned OFF to switch to the low current range, the reference need to be put back to 50mV, we also get 10mA
Then we can dim to 20μA.

With this we avoid dealing with very low sense voltages.

The downside to this is that a very low RdsON mosfet is required so that a variation of its resistance doesn’t influence Vsense too much. Here the Infineon part I chose has a RdsON of 2mΩ at 2.8V (the logic voltage) for a 3.3×3.3mm package, but with part variations and temperature it can potentially go up to 3mΩ maximum, if the shunt resistance goes up from 10 to 11mΩ then the current is reduced from 5A to 4.55A, not terrible but not great either.

Fitting an aditionnal 3.3×3.3mm package isn’t an issue on a linear driver, on a switching driver board space is precious for 18650 flashlights, although still not critical when using both sides.

kennybobby
kennybobby's picture
Offline
Last seen: 2 hours 44 min ago
Joined: 05/10/2017 - 09:13
Posts: 698
Location: huntspatch, alabama

The TI PWM chip regulates voltage on a cycle-by-cycle basis at 500 kHz, so only 8 bits of current sense measurement can develop a 1:10M range. For example 240 current levels for each of 41666 voltage levels.

Now i used to think that i was cool,
drivin' around on fossil fuel,
until i saw what i was doin',
was drivin' down the road to ruin. --JT

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 7 hours 44 min ago
Joined: 01/12/2013 - 14:40
Posts: 10648
Location: (469219) 2016 HO3
icpart wrote:
Any additional info about this nearly impossible dynamic range will be welcome. It will be very interesting for many of us. I think is used also full potential of 16bit timer. With current Abduril firmware is possible to get 10bit resolution. Here we talk for something like 20-24bit resolution. It used external DAC maybe? I can’t see how it is possible to be achieved with that attiny1634. Also submicro current measurements need also high resolution or larger shunt resistor.

Analog resolution, not digital.

For example: The Emisar D4 has a dynamic range of 16,000 to 1… 14 bits worth. But it uses only 8-bit PWM, which is 256 to 1. How is this possible? It has two power channels — one which goes from 0.25 to 130 lm in ~0.5 lm steps, and one which goes up to ~4000 lm in ~15 lm steps. Two 8-bit channels combine and produce an effective resolution of 14-bits.

But what if the low channel was smaller, and it used 10-bit PWM instead of 8? If the low channel was only 16 lm, that would increase resolution to 0.015 lm steps. 4000 lm / (16 lm / 1024) = 256,000, or approximately 18 bits of analog resolution (on hardware which is only 10 bits digitally).

If it helps, some related ideas are shown visually here:

Ignore the bottom part. It is only showing the importance of good current control to make the ramp more smooth.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 7 hours 44 min ago
Joined: 01/12/2013 - 14:40
Posts: 10648
Location: (469219) 2016 HO3
loneoceans wrote:
while the resolution is good at the low end, actually the ramp itself isn’t quite as smooth as you’d think and it looks roughly the same as my regular AMC7135 drivers, mostly due to the 150 default levels … 1500 levels and 10x shorter tick times will make a smoother curve …

On every flashlight in the repository, the bottom of the ramp has been artificially shortened because the resolution isn’t high enough in the hardware. It would otherwise end up with a ramp which looks like “1,1,1,1,1,1,2,2,2,2,2,2,3,3,3,4,4,4,5,5,6,6,7,7,8,9,10”.

But with your solution, it seems like it’d be able to hit the in-between levels at the bottom. The intended values are “1.00, 1.07, 1.15, 1.25, 1.35, 1.47, 1.59, 1.74, 1.90, 2.07, 2.27, 2.48, 2.72, 2.99, 3.27, 3.59, 3.94, 4.32, 4.74, 5.19, 5.69, 6.23, 6.82, 7.46, 8.16, 8.91, 9.73, 10.62”.

icpart
Offline
Last seen: 8 hours 38 min ago
Joined: 04/15/2019 - 01:13
Posts: 277
Location: Bulgaria

kennybobby wrote:
The TI PWM chip regulates voltage on a cycle-by-cycle basis at 500 kHz, so only 8 bits of current sense measurement can develop a 1:10M range. For example 240 current levels for each of 41666 voltage levels.

I didn’t understood that. What do yo mean? 500khz is operating frequency of the boost driver itself. It doesn’t have to do with control loop. In our case we have CC driver not CV in most of time. Also Anduril firmware must support that functionallity with second channel of dirver. Now we have simmilar idea like old FET 3 channel drivers.
ToyKeeper thanks for the detailed explanation Thumbs Up
zoysiamo
Offline
Last seen: 2 weeks 3 days ago
Joined: 04/30/2017 - 15:18
Posts: 76

This is tremendous – I’d love to purchase a flashlight with this kind of driver design.

thefreeman
thefreeman's picture
Offline
Last seen: 6 hours 19 min ago
Joined: 01/06/2020 - 09:56
Posts: 473
Location: France
loneoceans wrote:

icpart and thefreeman, using a high resolution or high precision part is expensive and significiantly drives up the BOM cost, and fortunately I managed to avoid using any of those components to enable the system to have a high dynamic range; not based on component precision but by system design. thefreeman, yes! I am actually using multiple sense resistors similar to what your drawing shows! I had the thought of trying it out last year but it took me some time to build a prototype, and there are a bunch of traps I had to work through with control and stability to make the entire system work well. I encourage you to try it out and see what works well though I can’t speak for the linear FET version. On this topic, check out the Thrunite T2 which someone alerted me that was another nice new flashlight similar to what I’m trying to achieve with the Lume X1.


https://zeroair.org/wp-content/uploads/2020/07/zeroair_reviews_thrunite_... />


In the photo above, what struck me was that I see a few big resistors. I don’t have this flashlight so I can only guess from the photograph that they’re implementing something similar… or maybe not at all… just a guess. 

Ah so this is similar then, this is encouraging for my novice EE mind, thanks for the answer.

The thrunite T2 has a 0.3 lumen so that’s pretty low, especially compared to the max output. Zebralight have been producing flashlights with very low moonlight levels for years, it would be interesting to know how they do it as well. Manker E02 and E03, very small lights with boost converter and ultra low moonlight.

Attiny 1 series also have a calibrated temp sensor, if you added an external one then that’s that less on the board.

icpart
Offline
Last seen: 8 hours 38 min ago
Joined: 04/15/2019 - 01:13
Posts: 277
Location: Bulgaria

ToyKeeper wrote:

Analog resolution, not digital.

For example: The Emisar D4 has a dynamic range of 16,000 to 1… 14 bits worth. But it uses only 8-bit PWM, which is 256 to 1. How is this possible? It has two power channels — one which goes from 0.25 to 130 lm in ~0.5 lm steps, and one which goes up to ~4000 lm in ~15 lm steps. Two 8-bit channels combine and produce an effective resolution of 14-bits.

But what if the low channel was smaller, and it used 10-bit PWM instead of 8? If the low channel was only 16 lm, that would increase resolution to 0.015 lm steps. 4000 lm / (16 lm / 1024) = 256,000, or approximately 18 bits of analog resolution (on hardware which is only 10 bits digitally).


ToyKeeper what do you think about that: http://www.openmusiclabs.com/learning/digital/pwm-dac/dual-pwm-circuits/...
Also here is similar idea released with MSP430 mcu https://www.radiolocman.com/shem/schematics.html?di=278745 It is similar to your approach to combine two output current control channels. This is very simple and clever solution to achieve higher PWM DAC resolution from dual PWM channels. Also that will be very good for trusted old Attiny85. With linear driver this is very good solution I think. But I think there is needed little modifcation of code to be released LSB and MSB from dual channels. With that approach we now can have very good ramping.
loneoceans
loneoceans's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 01/08/2017 - 00:18
Posts: 282

ToyKeeper wrote:
loneoceans wrote:
while the resolution is good at the low end, actually the ramp itself isn't quite as smooth as you'd think and it looks roughly the same as my regular AMC7135 drivers, mostly due to the 150 default levels ... 1500 levels and 10x shorter tick times will make a smoother curve ...
On every flashlight in the repository, the bottom of the ramp has been artificially shortened because the resolution isn't high enough in the hardware. It would otherwise end up with a ramp which looks like "1,1,1,1,1,1,2,2,2,2,2,2,3,3,3,4,4,4,5,5,6,6,7,7,8,9,10". But with your solution, it seems like it'd be able to hit the in-between levels at the bottom. The intended values are "1.00, 1.07, 1.15, 1.25, 1.35, 1.47, 1.59, 1.74, 1.90, 2.07, 2.27, 2.48, 2.72, 2.99, 3.27, 3.59, 3.94, 4.32, 4.74, 5.19, 5.69, 6.23, 6.82, 7.46, 8.16, 8.91, 9.73, 10.62".

 

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. Smile

www.loneoceans.com/labs/

- Next-gen Switching Drivers: Lume X1 and Lume1
- High Power Boost Drivers: GXB100 GAN 100W, GXB172 17mm 50W
- Older: GXF22, GFS16, GXB17 & GXB20

Scallywag
Scallywag's picture
Offline
Last seen: 3 hours 33 min ago
Joined: 01/11/2018 - 22:23
Posts: 1830
Location: Ohio, United States

loneoceans wrote:
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. 

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...

agTac D25C TiL6 XHP70.2 P2 4000K FET+7135 | Jaxman M8 | MF02 | Jaxman Z1 CULNM1.TG | Blue S2+ w/ ML Special |

F. Premens
F. Premens's picture
Offline
Last seen: 3 days 8 hours ago
Joined: 08/07/2012 - 17:20
Posts: 71

Very impressive, the looks with the Olga.. Shocked

000-Bluefire
000-Bluefire's picture
Offline
Last seen: 2 months 4 days ago
Joined: 01/02/2021 - 01:54
Posts: 3
Location: California

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

Quote:
My ideal everyday flashlight would be something like the Zebralight SC700d – it’s extremely compact (smaller than many 18650 lights even though it has a 21700 battery), extremely well built, has a high efficiency driver, and has an e-switch. As far as I know, there is no competition anywhere close to this flashlight, and certainly none running the wealth of features provided by the open-source Anduril.

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.

Scallywag
Scallywag's picture
Offline
Last seen: 3 hours 33 min ago
Joined: 01/11/2018 - 22:23
Posts: 1830
Location: Ohio, United States

000-Bluefire wrote:
Lumintop FW21 […] 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.

agTac D25C TiL6 XHP70.2 P2 4000K FET+7135 | Jaxman M8 | MF02 | Jaxman Z1 CULNM1.TG | Blue S2+ w/ ML Special |

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 7 hours 44 min ago
Joined: 01/12/2013 - 14:40
Posts: 10648
Location: (469219) 2016 HO3
icpart wrote:
ToyKeeper what do you think about that: http://www.openmusiclabs.com/learning/digital/pwm-dac/dual-pwm-circuits/... … It is similar to your approach to combine two output current control channels.

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.

loneoceans
loneoceans's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 01/08/2017 - 00:18
Posts: 282

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..

www.loneoceans.com/labs/

- Next-gen Switching Drivers: Lume X1 and Lume1
- High Power Boost Drivers: GXB100 GAN 100W, GXB172 17mm 50W
- Older: GXF22, GFS16, GXB17 & GXB20

gchart
gchart's picture
Offline
Last seen: 2 hours 22 min ago
Joined: 03/19/2016 - 11:57
Posts: 2943
Location: Central IL

loneoceans wrote:
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.
Quadrupel
Quadrupel's picture
Offline
Last seen: 8 hours 8 min ago
Joined: 12/03/2017 - 10:40
Posts: 617
Location: Lithuania

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

loneoceans
loneoceans's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 01/08/2017 - 00:18
Posts: 282

gchart wrote:
"This bzr repo":https://code.launchpad.net/~gabe/flashlight-firmware/anduril2 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.

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

 

Quadrupel wrote:
"Amutorch 3":https://budgetlightforum.com/comment/1683463#comment-1683463 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

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..

www.loneoceans.com/labs/

- Next-gen Switching Drivers: Lume X1 and Lume1
- High Power Boost Drivers: GXB100 GAN 100W, GXB172 17mm 50W
- Older: GXF22, GFS16, GXB17 & GXB20

JaredM
JaredM's picture
Offline
Last seen: 59 min 32 sec ago
Joined: 10/31/2011 - 13:33
Posts: 1628
Location: Pittsburgh, Pennsylvania

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.

Quadrupel
Quadrupel's picture
Offline
Last seen: 8 hours 8 min ago
Joined: 12/03/2017 - 10:40
Posts: 617
Location: Lithuania

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

D'AVerk
Offline
Last seen: 3 weeks 6 days ago
Joined: 09/05/2018 - 07:48
Posts: 150
Location: Russia

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

hinbli
hinbli's picture
Offline
Last seen: 2 hours 25 min ago
Joined: 05/02/2020 - 14:05
Posts: 34
Location: USA

loneoceans wrote:

Thanks for the comments everyone!

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?).


https://budgetlightforum.com/comment/1725393#comment-1725393

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.

gchart
gchart's picture
Offline
Last seen: 2 hours 22 min ago
Joined: 03/19/2016 - 11:57
Posts: 2943
Location: Central IL

D&#039;AVerk wrote:
If this driver technology would be implemented in close release serial flashlights? Name, o sister!

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.

id30209
id30209's picture
Offline
Last seen: 8 hours 15 min ago
Joined: 05/17/2018 - 12:20
Posts: 1707
Location: Croatia

hinbli wrote:
loneoceans wrote:

Thanks for the comments everyone!

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?).

https://budgetlightforum.com/comment/1725393#comment-1725393 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.

OMG Yes!

FW1A X1 withFC40 would be a spot on.

WTB Titanium 4sevens 2xAA tube

JaredM
JaredM's picture
Offline
Last seen: 59 min 32 sec ago
Joined: 10/31/2011 - 13:33
Posts: 1628
Location: Pittsburgh, Pennsylvania

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.

Agro
Agro's picture
Online
Last seen: 3 min 3 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6671
Location: Ślōnsk

loneoceans wrote:

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 × 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.


PSOC 4000 goes down to 1.45×1.56mm BGA. Wink
I also think that the effort to port FSM would be high compared to the benefits though.
nzoomed
Offline
Last seen: 2 months 1 week ago
Joined: 08/01/2019 - 03:32
Posts: 113
Location: New Zealand

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!

D'AVerk
Offline
Last seen: 3 weeks 6 days ago
Joined: 09/05/2018 - 07:48
Posts: 150
Location: Russia

gchart wrote:

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.

!{width:600px;max-width:100%}https://i.imgur.com/bEvnqDy.jpg!

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

Pages