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.
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
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.
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.
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.
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!
No, a buck driver is different than linear. The difference between cell voltage and the LED vF is not just burned off, it’s “bucked down”. This should help.
Thanks! The Lume X1 is an E-switch topology. I chose that specifically over clicky topologies because the clicky switch adds significant input resistance, and is non-ideal for this high power driver (40W nominal). This is the reason why getting the GXB172 to work well in a clicky design is challenging and requires very careful assembly and was why I designed the FET-based-tailswitch to reduce the switch resistance - the tailcap mod is not the same as an e-switch, if that's what you're asking. In an e-switch, the battery is always hard connected to the driver and the switch is just a signal net connected to the MCU; in a clicky or a clicky with my tailcap FET switch, the power flows through this switch when it is On. The Lume X1 also uses ToyKeeper's Anduril, which is designed for E-switch use only.
D'AVerk, the Lume1 driver in the Fireflies flashlight is a 6A Constant Current Buck + FET + Charging driver, not a linear driver. It has a fair bit higher efficiency than linear drivers. The buck regulator converts the battery voltage to a lower voltage to match the forward voltage of the LED at a desired forward current. In an ideal world with ideal switches and inductors etc, there would be 0% loss (as opposed to linear drivers where an ideal linear regulator would still have the same loss as a simple resistor), but in the real world, the efficiency at most outputs is around 90 to 95% with some losses in DCR, gate drive, and switching losses in the buck regulator elements.
Thanks! It does take a non-trivial amount of time to layout a board for each flashlight so I'm trying to pick something that has potential for lots of people to enjoy. I noticed that Kaidomain sells some individually-wired 3-XP MCPCBs (looks easy to connect in series with two solder jumpers), but the FW3 series is a little challenging for the Lume X1 to be run at its full potential due to its very shallow driver cavity (limiting inductor size), and generally small-sized PCB with E-switch ring (this takes up a lot of layout estate). I'm curious about the Amutorch E3 with its unibody construction, and I ordered one to see how good it is. It could be a good candidate for me to build my 'Zebralight SC700d' compete, though I suppose ideally it'll be nice to work with a manufacturer to develop a flashlight that would fit this driver better. I'm also looking at making a revision to use the AVR 1-series too..
forgot about the limited Z height of the FW lights. Bummer. I’ve gotten so spoiled by the tail e-switch layout (YMMV), but it complicates design and either adds girth or necessitates proprietary cells,the latter BLF hates with a fiery passion. The Lume1 will have to be good enough for the FW3a then and we shall find or create a new host moving forward.
forgot about the limited Z height of the FW lights. Bummer. I’ve gotten so spoiled by the tail e-switch layout (YMMV), but it complicates design and either adds girth or necessitates proprietary cells,the latter BLF hates with a fiery passion. The Lume1 will have to be good enough for the FW3a then and we shall find or create a new host moving forward. 