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

I don’t believe the problem is the switch though changing the switch can solve it. I believe the problem is how the MCU reads the signal from the switch. I just did some thorough testing on my unit and replacing the switch does not always solve the problem. In fact the problem can remain even while manually shorting the switch input by tapping two wires together. It also will not work with those really flat switches that are held together by some sort of thin plastic/tape. Don’t know how to describe them. There were some other switches that did not work as well. However, some switches work every time without a hitch. I also tested the “misfiring” ut01 switch on another driver and it works fine. It confused me for half a day at least. :slight_smile:

In general, low resistance switches with a sharp “click”, worked the best. Of course this is just one driver I have tested and others will have to check for themselves but I do think this can explain some of the problems others are having as well.

For my light, I can’t power cycle it ON-OFF-ON-OFF, without doing this…. ON-OFF-Loosen/tighten tailcap-ON-OFF-Loosen/tighten tailcap-ON-OFF-Loosen/tighten tailcap. This ONLY occurs with a 14500 cell. Eneloop works 100% perfectly.

Do you think this light is die-ing a slow death? Have you guys seen cases where a light behaves as I have described and then suddenly without warning stops working entirely?

In an earlier posts in this thread, I mentioned that my first two UT01s worked perfectly while a third does not. I have an update to that. I decided to keep the two ‘good’ ones for gifts, and struggle with the balky one myself.

Oddly enough, the more I used it, the better it worked. To begin with, it was reluctant to come on, reluctant to turn off or to change modes….it would ‘stick’ in low and need to have the tail cap loosened to regain any function. In one of its more co-operative moments, I did manage to run the programming cycle, which it remembered… (The driver board in this one is stuck tight, and I can neither budge it nor get the nose cap off; I’ve applied force to the point of fearing damage.)

After a couple of days of relentless and frustrated clicking it began working more and more consistently. Now, while still on its first lithium primary, it works as well as the other two. There remains a sense of something not being right in the switch - a feeling of two clicks ‘on the way down’ for lack of a better explanation - but it’s much better than before and it obeys all inputs without hesitation.

While I don’t doubt there might be a variety of problems with these lights, mine appears to have a mechanical issue in the switch which is somehow rectifying itself through repeated use. I’ll continue to use it. Mercilessly.

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.

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.

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.

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

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

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…

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

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

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

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?

Poll here:

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

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).

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.

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

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.

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.

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.