In that case just standard sizes 17,20,22 (with as much edge clearance as possible for retaining rings). Most mechanical ones donāt have very specialized layout like FW lights.
If loneoceans can put an e switch solder pad the on driver it could be used for both clicky and e switch lights.
Would you happen to have Anduril functioning on an 841? This would allow him to adapt his GXB172 clicky firmware existing for the 841instead of starting over.
I started adding 841 support at one point, but there was no hardware for it, so I had nothing to test on and no concrete target to add support for. So it never got finished.
Hello all,
ToyKeeper is right! The Lume1 hardware can be applied to other flashlights as well, though it's not possible to adapt a Clicky-type flashlight (i.e. the switch cuts off power completely) to work with an e-Switch firmware like Anduril. What I was saying is that there are no hardware nor software limitations that would prevent the Lume1 design to be adapted to clicky-type flashlights as well. Personally I do like the classic Convoy S2 but I haven't really had time to adapt the Lume1 to that driver just yet.
For the GXB-series, I'd recommend that project only for people who know what they are getting themselves into and have a fair bit of experience with hardware work, since those are very high power drivers are generally impractical to use in real life, and will not achieve the designed performance without proper care in construction, component selection, etc. It's a much more involved overall system than the lume1-series. For those drivers, the reason why I chose the 841 was due to it's tiny size (it comes in 3x3mm package, which the others like 1634 do not), but other than that there's no reason why another MCU wouldn't work. A good candidate will be the 1-series in the near future :).
I am hoping to expand the driver to more flashlight but due to the slightly more complicated nature of the switching drivers, I'd like to focus on one project at a time to make sure it's robust and reliable. Hope that makes sense!
I respectfully disagree about your GXB driver being impractical, its a masterpiece. Itās a shame more people arenāt using it.
I use one three times a week for mountain biking driving an xhp70.2 with a 21700 battery. Its super efficient and with the C8 size host runtime on turbo is pretty good and lights up a very large area. My rides are about 100 minutes long using a modified level two (three is too bright) and the charger never reads below 85% battery capacity.
It can be tricky to build if your soldering skills arenāt great and the parts are expensive compared to most drivers around here, but its the only driver that gets that much power and efficiency out of a 17mm pcb. There arenāt many people able to do this and even fewer that would share it for free. Thank you for making it available to us.
+1
Its a beast of a driver for its 17mm size.
Thanks again for sharing with the community Loneoceans. :+1:
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:
- 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.
- The four solder pads on the AUX-LED board are small and fairly close together, making soldering a bit challenging.
- 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:
- Don't install the AUX-LED board at all (easiest solution).
- Deal with the AUX-LEDs being a bit more rGb than RGB.
- Swap the resistors of the green and blue channel (I expect this solution to be implemented in future production runs).
- 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.