The YLP Gekko 1.0 is the bee’s bollocks in this price range. 4000K LH351D 90+CRI, ramping or discrete/good programmable UI, very good thermal control, 49 g, quite a bit more efficient than the H04. I was cross researching against the HL3A, H04/H04RC, YLP Panda 2 CRI/3, some Acebeams, etc. The HL3A was initially the most attractive, but button design and Lumintop design/quality issues knocked it down. I decided to jump the gun before the reviews rolled in to get the initial discount price from the code in the YLP thread here (with code was $30 USD, $36 USD shipped to USA, currently ~$41 USD not shipped without coupon code if you do the conversion from rubles), and I’m very satisfied.
There is some criticism of the heat path/build quality between the star and body, but, if you don’t open it up to see, the construction looks impeccable externally on mine. It’s not super high powered, 3 amps max, so the heat path issue actually doesn’t affect use to a noticeable degree. Mine actually does sustain 900 lumens in actual, cooled (running) outdoor night use on a cool night. 300+ lumens is sustainable uncooled indoors.
Much better efficiency than the H04RC (lumens*hr, area under the graph) at 350 lumens from zeroair’s review using a 3400 mAh cell. Both headlamps use the LH351D, though the Gekko is 4000K and the H04 is 5000K. If everything else was equal, you’d expect the 5000K to be more efficient than the 4000K, so the efficiency gap between the drivers is pretty big.
H04 have same hi-cri 4000K led, superior build quality and switching driver which is more efficient. You can compare Gekko to this one, they probably are made by same manufacturer because have same hole under star
It is not correct to compare efficiency on 300 lumes and 350 lumens, moreover on the 300lumens real output could be 280.
But stabilization is really flat.
Bt you shold take in accont quirks in Gekko TK.
As example, if you turn Max (900) and work for some time (TK will lower output as example 400lumens), and switch for 300lmens mode, the real output would be significantly lower (~180-200) for 1.5 mins while TK will raise it up to 300 lumens. Because it’s “TK overheat gap” d’t take in account that 300lumens mode by default is lower heated then previos “downlowered maximum”.
Other - it would be very good to check how good LED star attached to body. There was case of overheating LED and not good screwing.
There is difference between direct current regulation in Gekko and unknown, but very possible PWM regulation in fake.
As example, on “equal” 350mA LED in Gekko would work on Vf as 350mA with much better efficiency, then 3000mA PWMed LED in fake (and with more fast flat reglation lost, if even there are some).
When I pointed to those graphs on reddit, m4potofu investigated the H04:
“I have an H04 driver lying arroud so I quickly checked its efficiency on high with an LH351D, well I only did one measurement because I seems to have killed it afterwards (oups), 80.2% at 3.7V in, which is not good at all, it has a rectifier diode so it’s an asynchronous buck which partly explains the low efficiency.”
I’m aware of that the thermal control works like that, and I like that for the reasons that Inferion has stated. It provides a visual indication that the button press is working. If I’m using the light such that the thermal control is working, I’d either keep it at that setting (for example 400 lumens) if I need that light, or be happy that the lower discrete level is lower than normal for a while the light cools down. What’s the problem with that? I’ve switched to the ramping mode anyway, and like I said earlier, in my case, if I’m using 900 lumens or something near that, I’m outside running in generally cool weather at night, where the cooling has been sufficient to maintain max lumens despite the divot under the star issue. I basically haven’t seen any issue in my real use.
May be you are topic starter? So we are giving advices for TS now, and he/she should analize HIS/HER real use, not yours.
And if Nitecore do something “unknown” with light flow - this called as “narcomany”,
and if such unknown things do Inferion driver - this is “wow, cool feature”? Not at all. This is just bug, and this should be declared as BUG.
No any reason do such things against simple check of current on mode changes and reset TK if current on new mode is LOWER then before.
Two-three program instructions and light flow could be transparent for all, not only you, with yours pattern of use.
