I can definitely recommend the i-CON Pico and Nano. We have a Nano at work and it is amazing. Pico is basically the same thing but with no ESD protection.
Not doing anything wrong. The voltage mode is there twice, to make it easier to select. When there was just one, people found the timing difficult… so a second one was added to give the user a wider time window.
That means the battery is full, or close to full.
Thanks! I think you are the first to try it.
About the fuses, I vaguely recall that some avrdude versions report swapped values for two fuses… so it might just be that. Not sure.
About double-click going to mem after turbo has stepped down, that sounds strange. If you have the ceiling set to 149/150, and the current brightness is below that, double-click should go back up to turbo. If it’s not doing that, something doesn’t sound right. Could it be that the ceiling is set to a lower level?
The main areas of risk in this version are the voltage and temperature measurement, and thermal regulation. If those are working though, it’s probably safe to merge into a bigger branch for more people to use.
Convoy S21A or B, M21A, B…
That would be great.^^^
Those are not e-switch though so a bunch of functionality would be gone and new firmware needed.
I think these, in order of highest preference, are all good choices:
- Skilhunt headlamp or side switch light
- Any Emisar/Noctigon light
- Any Sofirn side switch
- Smaller Lumintop GT models
- Any FireFlies light (though I think they are making their own?)
- Any Astrolux FT or Matenmico MF series
If I understand correctly, that was the goal. Lume-style driver for non-e-switch lights running non-e-switch firmware.
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.