It’s similar, but not really.
First, it’s 18650, so more bulky. For this reason it also needs a 2-strap headband adding to the bulk.
And it has only one white LED, which is less efficient. 6*XP-L2 V6 does 700 lm @ 200+ lm/W. Add a boost driver and such light doubles the sustained output of a 1-led + linear one.
Have you seen my contest light thread from last year? I made a light bar of sorts, using XP-E2 mounted on a board I designed myself. That board could be tweaked a little to make your desired project. I would actually love to see something like this made by a “real” manufacturer as it could be a really popular style if done right.
Interesting, thanks!
For the reference, here’s the thread:
As to the Q8-based thrower, here’s a nice idea for cost cuts from Astrolux. Though the light with 18350 tube looks so cute that I’d probably take it.
What about a headlamp with 2 LEDs driven at low current for efficiency that uses a 20700/21700 battery? More capacity than 18650 and more efficient led setup should result in pretty long runtimes with the lower modes en a very high (but short!) Turbo output possible.
Possible led choice would be sst40.
I’d rather have a lightweight 18350 based headlamp and bring a few spare batteries when the runtime is really needed. If you really depend on it, it even makes sense to bring two headlamps.
*I would love to have to have a lantern head that would work with the Q8-lego system. I made a diffuser out of a translucent bottle that works well with the Q8, but I am sure that a dedicated lantern head would be much better. USB charging and power bank function would be amazing. I wish that the Q8 had USB charging to make it easier to give them as gift’s to non-flashlight crazed family members.
*
Yes the BLF lantern of DBSAR ideally should be ready before summer 2018 right 
Has anyone made drawings of what the lantern might look like?
There is a whole topic about it, DBSAR made one based on an SRK.
Pics in OP
And a general idea here
It would be interesting to see a zoomie built around this optic:
http://www.polymer-optics.co.uk/wp-content/uploads/2016/03/130_Zoom_7Cell_Optic.pdf
and some small, powerful LED. Oslon black maybe? Not very efficient, but I see nothing better…
Please can you show something about it without my phone getting very unhappy for being bounced to a doc?
A zoom lens that is:
- 7-emitter
- 39.15 mm diameter
- 5.1 mm height (+0.2 mm distance from the emitter)
aha, does that give a hexagonal or even round(ish) effect when zoomed in?
Zoomed in - nice big round hotspot, minimal spill.
Zoomed out - ugly hotspot+spill, overall shape between a hexagon and a star.
Though as far as I understand, zooming out the way they recommend rotates the lens. The TIR has 7 tiny lenses. They are in front of emitters when zoomed in, between emitters when zoomed out. Except for the central one. I guess this is the reason for ugly beam when zoomed out. Moving the lens linearly should be better, no?
ADDED: Though their way has the benefit of compactness. Only 30 degree turn moving the lens 3.75 mm to change between zoomed in and out.
Those are completely different as far as I can tell.
Frankly, I feel similar. This LED Lenser has 7 emitters too. It may be an indication of how a zoomed-in beam looks. But we know this already. Other than this it’s quite different.
Actually the ramping UI is the shizz, a lot of people seems to really like it for many reasons but one thing that I don’t like is that it makes a flashlight way less predictable concerning runtime.
An OLED displaying remaining capacity in % would be a nice addition and it would be very useful to have a calculation of the remaining capacity in hour / minute, particulary for the DBSAR, even without ramping UI.
I don’t know if it would be better to calculate it based on the voltage or by entering (somewhere in a configutation menu) the total capacity of the battery(ies).
Or could it be possible to have this with a flashing feature without OLED screen to stay more budget friendly ?
I’ve been thinking about it last evening. I think this may be the only major use for modes instead of ramping.
Yes, it’s important for the user to know runtime.
Yes, ramping firmware makes it harder.
The problem has 2 parts.
- Learn the runtime
- Communicate it to the user
Let’s start with 1).
For real accuracy you need to know:
- current amps drawn from battery
- current battery voltage
- battery discharge curves
- cutoff voltage
If you’re a flashlight manufacturer who supplies battery together with firmware, you can have all these variables.
If you’re a driver developer things are much harder.
Several approaches:
A) Don’t worry about runtime. You know amps, your user knows capacity and can figure out runtime by themselves
B) Track voltage drop, it can give semi-accurate predictions, but shortly after inserting the battery it just won’t be able to tell
C) Let user enter capacity in configuration
D) Use a smart battery that can tell you its capacity
E) Remember the capacity of the previously inserted battery
F) When user changes modes, amps change. So does voltage sag. You can use it to make more accurate prediction of what will be faster, low voltage cutoff or drop-down from near-full discharge
G) Remember voltage sag of the previously inserted battery, so you can better recognise that it was a different one
Communication is hard too. You can:
A) Blink it out
B) Bink it out with the indicator LED
C) Make blinks as the voltage drops, so user can judge the discharge rate by themselves
D) Have a set of several colours that are distinctive enough and light the indicator diode to such colour (for several seconds?)
E) Use a LCD
F) Send it over bluetooth, so the user can read this info from their smartwatch