Review : Utorch UT01 Flashlight (XP-L V6 / AA & 14500 / e-switch)

LED Flashlights – General Info 1 x AA / 1 x 14500 Flashlights
298

Thanks for the report, tumbleweed48.

What lightrider has described sounds like a combination of electrical, mechanical and programming issues, with the switch being a locus of electrical and mechanical issues. Your description isn’t inconsistent with that.

From your description, I see another possible component of the problem, instead of or in addition to an issue with the switch that may remediating with use. You say you are still using the same lithium primary with this light. That means that the supply voltage is declining, which could also be playing a role in the way the MCU “observes” the signal from the switch.

This is consistent with some of my earlier, crude, operations, that the problem seems to have some relationship to the type of cell I’m using, and, with a given cell, may change over the discharge of the cell.

I just looked at this more closely. With an unprotected 14500, a couple days off the charger, I’d say the chance of any click being registered, by turning on the light, after the first turn-on after power-cycling the light, is about 1-2. With a Lada NiMH a few days off the charger, the success rate is closer to 10-20, and I just had a run of 100% success, until I removed the cell and tried again with the 14500, which again only had a 1-2% success rate.

In all cases, once the light is “on” ~100% of clicks are registered for switching intensities/modes, and turning off the light.

FWIW, I’ve been able to run through the programming cycle and then disable programming mode and have the changes stick. This works even if I have to power cycle the light, do a long press to enable programming mode, power cycle, click on and into programming mode, update the settings, turn the light off, and then power-cycle it again before doing a final 10s press to disable the programming mode. Or, to put it another way, the last state of the programming ritual seems to persist even if the battery is removed.

I haven’t found that going through the programming cycle makes any difference in turn-on efficacy.

299

LightRider, do you have either an actual O-scope trace, or a working hypothesis in your head of how the switch signal looks with a problematic switch, vs a good one?

How much of the circuit do you understand? I wonder if perhaps the addition of decoupling capacitance or a small RC filter, somewhere easily accessible could make the system more robust with the typical range of manufacturing, power supply, thermal and wear tolerances.

Pardon me if the above question is silly; I ask based on a rudimentary understanding of electronics and firmware.

300

I do not have an oscope. My observations were a result of swapping six different types of switches and testing it through different voltages with each switch. It was clear that each switc carried over its same functionality if swapped out and swapped back in. Right now I have a switch that the MCU is 100% satisfied with as aposed to the stock switch that was less than 30% successful. And another switch that I could only get to work a couple of times at most.

My knowledge of circuit s sounds to be about the same as yours. I was wondering how same ting. Capacitance and voltage level could have a huge impact on the way the switchs clicks are read. I would bet that the firmware was tested on better or maybe just different components than the drivers production components. I would not have the knowledge or equipment to test this stuff. I guess trial an error. I could hook up the bad switch an add/drain capacitance at the switch pin. By the way, capacitance could be draining with a power lockout and thus allowing the switch to function again.

301

There is something whacked in the software.
If it won’t turn back on with the 4.2 battery after having been on, just by twisting the head twice breaking contact and then Boom comes on fine until it is turned off again.
It is acting like an electronic lockout.

Doesn’t do it as bad with 1.2 Ni-Mh but still acts wonky.

What is the sequence for lockout on some of the other Manker flashlights?
Maybe software is the same?

I am just treating as a lockout feature for now :slight_smile:
Later,

Keith

302

Yeah me too… mandatory lock-out. So far this is the only thing wrong with it.

303

Sigh…
Got mine in today, only tried with Eneloop, same lock out problem…
Switch seems to be good though, but once turned off it won’t come back on unless i unscrew and tighten the tailcap first…
:weary: this sucks…

(edit)
Hmm… sometimes it does turn on, once every 20 clicks on average…
Maybe it is the switch afteral…

Very vague problem…

304

Good idea, that is, if everyone who bought one this time will vote.
I’ll start a poll.

305

So what do guys do with all these malfunctioning ut01 lights? Do you reach out to GearBest and demand a refund?

306

Try this;
Smack the flashlight (tail down) fairly hard onto a solid surface like you’re smacking a pack of Cigarettes and see if it doesn’t come right back on with a click after doing this.
The freakin driver assembly is free to move around, bad design.
I tried switching the tailcap and batt tube from my good one, no difference, problem is in the head.
Later,

Muto

307

I’m not going through the hassle of video, 14 PM’s and emails of bad translation and form letters for a $10 flashlight that works fine once you know what it needs to come on. It works fine once it’s on.

The older version I have does not have this problem, Progress they say?

308

Poll here:

Please vote to get an idea how many % is bad.

309

I may well open a ticket, yes.
See what solution they can offer.
I mean, a bargain is nice, but not when the product is faulty (obviously).

310

Just got mine today. So far, it appears to have no issue on either NiMH or Li-Ion cell, knock on wood.

However, visually, I don’t think this thing delivers 800 lm. Based on the results of the ceilingbounce app in my make-shift integrating sphere, lumen output is about the same as my JetBeam Jet-1 MK, which claims 480 lm on high.

311

Have you tried programming in the brightest setting? Some members suspect it comes programmed at a lower output level for its “turbo”.

312

Thanks. Programming to the brightest turbo setting helped. Looks like I’m getting upwards of 600 lumen now. I’m guessing the 800 lumen factory rating is for the CW emitter. Mine is NW, so it’s going to be lower. Plus, the cell I’m using (Sanyo UR14500P) isn’t exactly a high drain cell either, so that may also be limiting my output.

313

I don’t believe this light is spec’d for OTF-ANSI Lumens. IIRC the 800L is spec sheet emitter lumens.

Glad you got it re-programmed, and yours works fine with either cell chemistry.

It most certainly doesn’t do 800 OTF. I am not sure what the current draw is, but theres a good chance without an IMR cell you could be pushing the limits of the 14500.

314

Just a note: the problems with this light are not because of loose driver, bad contacts, or a bad switch. The switch however, is what manifests the problem. The problem is how firmware decodes the signal from the switch. When the light is off, something in the firmware tightens up the parameters that determine whether the button was pressed or not. Reason for this is unknown but I’ve wondered if it more “picky” with the handling of the signal from the switch to limit accidental turn ons. The firmware may not be broken through as it verywell may have worked with the switch used in testing(which may have not been actual physical switch at all). I say this because the light works fine with some switches and does not turn on at all with others. All my testing was done with the driver outside of the light so all other theories of mechanical problem from the host can be dismissed. Of course there is the normal one or two lights out there where this could be the problem.

I’ve read about all reported issues and all of them can be explained by my theory. Someone claimed my theory is in correct because their light started working when they straightened a twisted driver. However aligning the switch and pressing the button from a better direct angle changes the signal profile of the button press. It gives a better clean click so the driver reads the presses correctly.

Another claimed the problem is with the type of battery or because of different charge levels. These observations are probably correct but it doesn’t disprove my claims. Different voltages will also mess with the way the firmware views the signal from the switch. Either the voltage from the switch or the internal reference voltages of the MCU can be affected by different input voltages. This was confirmed by using a power supply to test the driver. Different voltages did affect the chance of the light turning on. Though, there wasn’t a general rule that deterermined what voltages did what. Each switch was different.

So, changing the switch may help defective drivers but not because the origional switch was “bad” it was instead not compatible with the firmware.

Good firmware design should take these factors into consideration. In fact, the designers of this light would have had to concider these things to some extent or the light wouldn’t work at all. The designers, however, must not have been thorough enough to acount for hardware variations.

This is my theory atleast. I admit, I am not fully qualified to make these statements. So maybe someone with a scope and a better understanding of firmware and switch press debouncing will test this theory further.

315

Sounds logical to me!!

316

I’m getting about 1.3-1.4A current draw on the highest Turbo mode.

317

I also wanted to mention, UT01 works great as a walking light, attached to the brim of a hat. On ‘High3’ setting, using a high capacity NiMH cell, it’s bright enough, and gives more than 80 minutes of runtime.