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.
I’m not an EE here guys, so be prepared for this to be a dumb question. Would it be possible for just critical components to receive RPP? Like a diode on the VCC/gnd pins of the MCU ? In other words, the RPP diode/pfet is on a parallel branch to the main current path?
I guess I’m in the dark about what components are going to give up the ghost when reverse biased in the present design. Any clue what’s going to fry and what’ll be safe?
I noticed something strange in work of reverse polarity protection:
Also not an EE but I’ll voice what I think I understand. In some drivers, like a lot of the direct driver or linear ones… absolutely. We protect only the MCU; pretty much everything else (FETs, 7135’s, etc) survives reverse polarity just fine. In a switching regulator (boost, buck, buck/boost), the controller needs protected, but frequently the control circuity’s power feed is shared with what gets piped to the inductor and thus to the LEDs. So you would end up needing to protect the whole thing, which is going to add some level of resistance in the power path.
Ouch! That driver is toast.
For most switching designs, the power path goes through the main switching transistors and inductors; so for the case of this driver, the reverse-polarity power-path goes through the main buck-boost IC, through reverse body diodes in the switches, and through the inductor. As expected, this will cause the magic smoke to escape from the buck-boost IC, which is exactly what appears to have happened. Adding RPP will necessarily add resistance in this power path.
Gchart is right in that it's easy to add some reverse polarity protection, and there is in fact space on the board to do so, but at the cost of reduced DD-FET performance. I'll be happy to add that in for future versions if there is sufficient demand, but in initial discussions, the desire was to have the maximum amount of lumens in turbo mode...
Thanks for the reply guys. I’m certain that if there was a simple solution that it would have been thought of and implemented. Just trying to learn more in this area. For this driver, I like the decision to forgo RPP for the sake of efficiency.
….protection will decreases perfomance like ….1% or more? Maybe 1,4%? ;)) 20cent protection can save whole 25$ device.
we’re still talking about flashlight drivers, right?