Lume1-FW3X: Constant Current Buck-Boost & FET Driver with Anduril1/2 + RGB Aux

Thanks WTF and Moderator007 for the kind words. I'll definitely look into revisiting those drivers in the future but likely not in the near time-frame since I have many things on my plate. I'll also be testing out Anduril2 (thanks TK!) for the driver and making sure all systems are working.

[Update - Anduril2 is working well! Please see first post for details]

I am finally getting caught up on this thread (I have been away from BLF for a little while). Here is my recap of the last 8 pages (please correct me if I got anything wrong).

Lume1 driver is now available from nealsgadgets, announcement in post #212 (GitHub page with datasheet).

There seem to be three minor issues with the current batch:

  1. MOSI and MISO programming pads are swapped compared to Emisar drivers (the printing on the driver board is correct), when using the Emisar flashing kit the corresponding wires need to be swapped.
  2. The four solder pads on the AUX-LED board are small and fairly close together, making soldering a bit challenging.
  3. Neal/Lumintop has chosen lower RGB resistor values than the recommendations in the datasheet for brighter AUX-LEDs, however it seems that the resistors for green and blue have accidentally been swapped during production (or maybe the wrong values were chosen) causing green to be too bright.

The first and and second point have already been addressed by loneoceans with a new revision of both boards, but these are not yet available (or in production).

For the third point there seem to be four possible solutions:

  1. Don't install the AUX-LED board at all (easiest solution).
  2. Deal with the AUX-LEDs being a bit more rGb than RGB.
  3. Swap the resistors of the green and blue channel (I expect this solution to be implemented in future production runs).
  4. Get some 0402 SMD resistors and install the ones of your choosing (recommendations are in the datasheet and here in this thread).

The question to which I haven't really found an answer to is weather or not there will be a second production batch that addresses these three small issues. Is it worth waiting for such a second batch, or is that too far out? Will there even be a second batch? Or will there perhaps be a second batch but without any changes?

Hello Noir,

  • Previously I had sent Neal the updated fabrication package with the correct MOSI and MISO pads; this was well before final fabrication. I'm not sure why the updated fabrication package wasn't used in the end... regardless, I clarified with Neal again and hopefully for any future batches, the updated one with the correct pad pinout (same as Emisar D4 etc) will be used. The existing pads are labeled correctly though, as you pointed out.
  • For future batches, unfortunately I don't have any timeline from Neal, and I haven't been able to get any concrete plans from him yet. My guess is that he will produce another batch if it is popular enough (i.e. when first batch sold out). I've asked a few times about this but I haven't got any response about those questions, nor any hard numbers for future batches. He has said he plans to have the driver in some FW3A flashlights stock though, but he hasn't given me any timeline yet. I suppose if there is enough community demand, Neal will produce it, since after-all he does have a business to run.
  • Neal/Lumintop chose the RGB resistor values themselves and these were different from what I suggested. My guess is that they wanted to make them brighter. I have suggested some possible new values to Neal and Lumintop, but I don't know if they will pick them up. Regardless, I have also since sent them updated fabrication files for the RGB aux boards with wider pad spacing for easier soldering. These boards can also be ordered on Oshpark (see link on first post of this thread) if you want to assemble one yourself, but if you are able to solder the SMD LEDs and resistors, the original aux PCB should be no problem for you.

Hope this answers your questions.

Thanks!

Thanks for your reply loneoceans,

unfortunate that you haven't gotten a decent reply from Neal regarding future batches. I guess we will simply have to wait and see.

Thankfully the above mentioned issues are fairly minor, I see them more as an inconvenience. Not having to solder tiny 0402 resistor would have been a bit more convenient, but you only have to do it once.

Are there any plans for a mechanical switch version of this? I’m looking for a high efficiency 1S 17mm/20mm buck driver and this looks almost perfect!

Hello Merlot, there are no current plans just yet, but perhaps in the future. Thanks!

The Rev B board was a bit easier to solder really just due to more room for wire positioning. The solder melts super fast so that isn’t different but it does give you a bit more room to hold things in place while you give it a quick touch with the iron.

I pulled the components from a first generation board that I filed a bit too much.

Does anyone have any spare RGB LEDs or a non working aux board I can pull them from? Can trade for resistors or reflow a Rev B board for you.

I wonder what the cost and feasibility would be to use a mini 4 pin connector for the aux board and driver would be. Or even a ribbon cable… would it clear the optics? Maybe not

Even the 3 pin connectors from LED4Power I have used barely fit through LED wire holes in shelf/mcpcb. You have to cut the tabs off the side to fit. It would be too tight. I think there is probably not even space on the board unless you moved resistors to the driver or had all in one triple/aux custom MCPCB.

Yeah. Flex ribbon cable would be the only option then. Not worth it I guess

The newer revision board is easier to solder and that is good enough. Part of the reason LED4Power did it was because his MosX PCB’s are a pain in the ass to solder anything onto. These thin aux boards melt solder instantly and if you cant solder the RGB wires on the aux side (on the new revision) you will likely have trouble on the driver side too. Assuming some future batch has the resistors values corrected this is about all we can ask for from this project.

I don’t have a problem with it. Just thinking of ways to make it more accessible to others and more friendly to emitter swaps.

Hello all,

I hope everyone is doing well. Thanks to all who got themselves a Lume1-FW3X driver, and I appreciate all the feedback and support!

Many of you may have heard of Anduril2, an evolution of Anduril, and comes with a new UI and a whole bunch of updates, including a bunch of whole refactoring. Many thanks to TK for her amazing work on Anduril2! For more information on Anduril2, check it out here: https://budgetlightforum.com/t/-/62656

I had some time to put together a new .hex for Lume1. This was done on Windows and complied with Atmel Studio 7. I tested most of the basic functions and they're working well, but there may be some small bugs here and there which I missed, and some features like the Sunset timer have not been validated fully yet. For now, if you're interested, you can find the .hex file here which you and flash to your own Lume1 driver.

  • Anduril2 for Lume1-FW3X - https://github.com/loneoceans/lume1-fw3x (updated 14 Dec 2020)
    > Note that the pinout for the programming pads has the MISO and MOSI pads swapped, when compared to the HarleyQuin programmer / Intl-Outdoor programmer. The final PCB was unfortunately not picked up by Lumintop even though it had the changes. The silkscreen on the PCB is correct, so use that to make sure the pins are connected appropriately.

  • Anduril2 Manual by TK - http://toykeeper.net/torches/fsm/anduril2/anduril-manual.txt (please read this in detail for all the new features of Anduril2 and some UI changes)

This build has the following parameters by default:

  • Ramp mode by default (as opposed to step mode)
  • SimpleUI has maximum current setting at 2A (instead of 3A for AdvancedUI)
  • Stepped mode is 4 steps for SimpleUI and 7 steps for AdvancedUI
  • SOS mode enabled in Blinky/Util modes
  • Model number is "0314" as suggested by TK

I'll be testing it more over the next few days. If anyone is interested, I'd appreciate any feedback as well. Finally, be sure to check out the new 'disco mode' for your Aux lights!

Thanks Contactcr for testing out the Rev B board! I'm glad it's working better.

As for connectors, I think solder-on wires make the most sense. Having a small 4-pin connector will be too fragile for either the main driver PCB and/or the aux PCB. It is also possible to have a flex from the driver to the aux board, but again the connection point will be tricky to implement and much much more expensive than wires. The key is to use thinner wires with thin insulation. For example, 30AWG wire-wrapping wire or teflon wire or similar is ideal, instead of silicone wire where the insulation is typically quite fat. Hope that makes sense!

Thanks again and keep safe!

Thx for the update.

I was wondering when Anduril2 will be implemented in these amazing drivers.

So far I'm happy as it is now so waiting for the final build sounds good to me. After all, swapping resistors and soldering tiny wires was challenging enough.

What is the max current in the advanced ui?

The max current is the same as the regular Anduril1 driver, 3A regulated. Of course, it still has direct-drive Turbo mode in addition to that.

All these values can be easily modified in either the cfg files when building your own binary file, or via adjusting the ramp values (min and max) in the UI :). Anduril2 is very customizable so you can adjust it to whatever you like, as long as it is within the hardware limitations.

Today someone released a Magic Smoke from lume1. Looks like this advanced driver have no simple reverse polarity protection!??

Hello Quadrupel, sorry to hear that happened. Unfortunately, precisely because this is an advanced driver specifically for hobbyists with an interest in DIY and modding, a conscious decision was made to not include reverse polarity protection. This is a simple add-on, yet looking at the effort people go to in order to maximize turbo brightness (spring bypass, choosing specific batteries with high V_fwd under load / lower internal resistance, etc), this will detrimentally affect the performance of the Turbo Direct-drive FET mode and introduce more resistance in the power path.

As I've mentioned before often, personally I'd prefer a driver without unregulated direct-drive mode, and additional features. However, at the moment I haven't got sufficient interest to build such a driver since these kinds of driver often don't have as much wow-factor on the spec list... hopefully we'll see more interest in the future and I'll be happy to work on something like that.

Wasn’t me , but i guess it should be written in manual to be cautious about it.

I was curious about this. After staring at the Lume1 boards for a while, I couldn’t figure out where RPP was happening.

I recently put together buck-only (no FET direct-drive mode) driver (completely untested at this point) and was on the fence on how to handle reverse polarity protection. I ended up putting in a SOT-23 PFET right up front in the power path. That’ll add ~26.5 mOhms of resistance. For my purposes, I’m willing to accept that. But if you were to do the same thing with a direct drive channel (and assuming my math is right… questionable), at 10 amps of draw with the same PFET, you’re talking about a 0.265 voltage drop across the PFET. So you’d be dropping a fair amount of voltage, not to mention the additional 2.65 watts of power that the PFET would need to be dissipating. Granted, if you have the board space, you could move up to a slightly bigger and more expensive MOSFET like this that has RDS (on) around 5 mOhm. Better, but as loneoceans said: any added resistance decreases performance.