Q8, PMS SEND TO THOSE WITH ISSUES BLF soda can light

17432 posts / 0 new
Last post
djozz
djozz's picture
Offline
Last seen: 3 hours 28 min ago
Joined: 09/07/2012 - 17:04
Posts: 17992
Location: Amsterdam

A real teardown will have to wait (I want to know if the ledboard looks any different from proto3, did they have a new type made after the delamination issue was found?), but here's my initial findings.

Out of the box output in djozz-lumen, I did wipe the contact area's of battery tube and driver cleam with a tissue:

 

with charged 30Q's:

3   seconds: 5400 lm

30 seconds: 5220 lm

 

with Panny BD (lower drain but still powerful):

30 seconds: 4780 lm

 

After cleaning up some stuff under the switch-board and swapping driver screws (I killed a driver screw while screwing it out):

 

with charged 30Q's:

3   seconds: 5560 lm

30 seconds: 5280 lm

 

(after some recent checks with reliable sources I believe that my djozz-lumen is about 9% high. But it still seems lower than most calibrations found on BLF and CPF, and what flashlight manufacturers list as ANSI -measured output of their flashlights)

 

Here's some pictures:

 

The tailboard screws look ok:

The earlier reported stuff in the screw-threads:

Some of that stuff is in between tailboard and body. I removed it and screwed down the tailboard really tight.

The driver screws look fine but are soft as butter, one was demolished while screwing it out with a well-fitting screwdriver.

I changed out the screws with a couple that I found in my box of screwy thingies:

The driver looks good, notice the 7135 with 'claw' mark.

The leds are more off-center than needed, you can see that the centering suffered from twisting the reflector. The beam is good though. But I will center the leds better when opening up the light in the near future.

 

Preliminary conclusion:

The production light is very close to the proto3, which is good. Wished that Thorfire was less sloppy with screws and screwdrivers, I don't really get that when they make a nice product like the Q8. But the performance of my copy is fine, also out of the box, nothing to complain about that, a 3.5% output drop in 30 seconds in a 5000 lumen soda-can-size light is a sign of a very very good heat path. And if I would not have opened up everything, the screws would not be an issue.

 

Now on to a busy weekend....

 

 

Tom E
Tom E's picture
Offline
Last seen: 55 min 6 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14681
Location: LI NY

Nice djozz! I'm finding lots of variations, but if I swap battery tubes with heads, the performance seems to track with the battery tube, not the head. Might be the first one I tested was the best. The material around the upper left screw hole in your pic appears to be the glue I've seen on several - just one out of 4 has it, mostly there is a blob stuck against the black outer tube, like it was squeezed out, then set hard.

hank
hank's picture
Offline
Last seen: 3 days 12 hours ago
Joined: 09/04/2011 - 21:52
Posts: 9592
Location: Berkeley, California
Quote:
And if I would not have opened up everything …

hahahahahaha …. this is BLF!
TF knows that’s what we do.
Well, almost everyone at TF except whoever picked the screws they used, I guess.
Our job is to find that guy — and professionalize him.

Jtm94
Offline
Last seen: 1 month 2 days ago
Joined: 02/22/2017 - 05:08
Posts: 400
Location: Pennsylvania

I will bring up something I experienced. I was using the light on a fairly low level maybe 25% to move some stuff around the basement and I clicked to turn it off, the indicator LED blinked, but the light did not turn off. It happened again when using it as a bed side light as I turned off the lights in my room. I almost forgot it was on and clicked to turn it off, but indicator flashed and it stayed on. Another click turned it off both times. I was curious if this was firmware intended once the light has been on for X amount of time.

MtnDon
MtnDon's picture
Offline
Last seen: 8 hours 47 min ago
Joined: 08/27/2015 - 18:25
Posts: 3831
Location: Canuk in NM

Back to my other post #13497

After much more on-off here’s what I think is going on. I don’t know if it makes sense.

Light #2 seems to require a more rapid click to go off than light #1. Slight difference, but it seems that #2 needs more of a “peck” to go off than #1. I switched hands thinking my left thumb was slower but that doesn’t make any discernible difference. I’ve been clicking on and off for 40 minutes in short groups of activity. If I consciously make the effort to short click #2 always goes off. But the light #1 is easier, a more relaxed light. Wink Even the SW LED’s seem to be closer in brightness, Batt check voltage at 4.0 to 3.9

saypat
saypat's picture
Offline
Last seen: 9 hours 29 min ago
Joined: 07/13/2011 - 20:32
Posts: 3579
Location: Calif

I have intermittent switch issues from time to time. I’‘l be in battery check mode and I click the switch 1 time and NOTHING happens. Seems to just get stuck. Keep pressing it and eventually it will exit battery check mode. This happens very, very, infrequently.

Tom E
Tom E's picture
Offline
Last seen: 55 min 6 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14681
Location: LI NY

Weird - I got switch debounce logic in the firmware that attempts to handle short jitters on the switch detection. Debounce logic and algorithms go way back - we used them in keyboard driver/firmware wayyy back. Every computer keyboard used to have a dedicated micro-controller built in to handle things like this - it's all transparently done for programs running on the computer.

These algorithms tend to be very hardware dependent, but don't think we've noticed these problems in prototypes, or have seen them consistent. Once in a while it might happen, but we don't notice it - click again and it works, and blame it on the mechanics not triggering. Not sure if it's another 1% thing or not: 5 units out of 500 is 1%.

If the 1 click got interpreted as 2 clicks, you'd think it would go to turbo, but the flash of the SW LED seems like it's seeing a click to OFF, then click to ON.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 19 hours 46 min ago
Joined: 01/12/2013 - 14:40
Posts: 10759
Location: (469219) 2016 HO3
Yokiamy wrote:
Even my wife, (who thinks i already own too much lights) said it is a nice light, well thats a compliment for her Big Smile

I gave my mother an original SRK with a “Narsil Lite” driver (er, Ferrero Rocher ramping UI from 2014), and she seems pretty happy with it. I showed her a few different interfaces she could choose, and she wanted the ramping one. It’s not as nice as a Q8, but it’s the same general idea and was the best I could fit on the hardware I had.

MtnDon
MtnDon's picture
Offline
Last seen: 8 hours 47 min ago
Joined: 08/27/2015 - 18:25
Posts: 3831
Location: Canuk in NM

Further interaction with it now has light #2 turning off the SW LED while it sits on the shelf in standby mode beside light #1. During this the SW LED on #1 burns brightly as expected.

So there is something not quite right with #2.

Etex
Etex's picture
Offline
Last seen: 6 months 4 weeks ago
Joined: 09/29/2016 - 00:57
Posts: 280
Location: East Texas

It’s no wonder some may have a little trouble stripping reflector screw heads, getting them out.

I have not touched this one.

Smittymojo
Offline
Last seen: 7 months 3 weeks ago
Joined: 07/31/2016 - 04:49
Posts: 186

Can you tell what it is Etex?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 19 hours 46 min ago
Joined: 01/12/2013 - 14:40
Posts: 10759
Location: (469219) 2016 HO3

Tom E wrote:
Weird – I got switch debounce logic in the firmware that attempts to handle short jitters on the switch detection.

These algorithms tend to be very hardware dependent, but don’t think we’ve noticed these problems in prototypes, or have seen them consistent. Once in a while it might happen, but we don’t notice it – click again and it works, and blame it on the mechanics not triggering. Not sure if it’s another 1% thing or not: 5 units out of 500 is 1%.

If the 1 click got interpreted as 2 clicks, you’d think it would go to turbo, but the flash of the SW LED seems like it’s seeing a click to OFF, then click to ON.

I ran into a few click-detection issues in the D4 firmware too. Specifically, it didn’t detect very fast clicks sometimes. I looked over the code to see if there was an easy way to fix it, but I didn’t see one so I didn’t fix it. I think it had something to do with polling in the watchdog timer interrupt for click detection.

While writing FSM, this was one part of the plumbing I rewrote from scratch using a completely different technique. It turned out that the pin changes were actually pretty noisy, so it took a fair amount of experimenting to find something which worked without spurious or missed events. I used the pin change interrupt for click detection, and combined that with some debouncing and duplicate-event prevention.

Then it does further processing to “cook” the raw events into meaningful abstracts like “double click” before the UI code can see it. A “double click” is a sequence containing “press, release, press, release, timeout”, so it doesn’t trigger anything until after the window has expired for a third click.

So, that’s how I eventually resolved it. Took a surprisingly long time to get it to detect button events reliably.

kaybi
Offline
Last seen: 4 months 1 week ago
Joined: 10/26/2016 - 23:53
Posts: 164
Location: Canary islands

I understood some of those words, TK. Silly

Tom E
Tom E's picture
Offline
Last seen: 55 min 6 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14681
Location: LI NY

Interesting TK. I assume it's all timing dependent? So if an event comes in faster than humanly possible, they are rejected, etc.? Always wondered how well it worked as designed, but I'd think it's dependent on quality of switches?

Yes, D4 baseline was NarsilM, so one in the same, just stripped out lot of things from Narsil not used for the D4, and added the basic functionality requested. Some things were streamlined as well. The debounce logic in Narsil was a carry over, not sure who provided it originally, maybe JohnnyC, not sure.

Flintrock
Offline
Last seen: 3 years 9 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

It's funny I was expecting and prepared to deal  switch bounce with OTSM, but I haven't ever noticed it being an issue.  I wonder how much having a 1uF cap on the switch pin makes a difference.  I would think switch bounce would be like ms range though?  Which is still kind of long compared to that cap drain.   I guess on entering and exiting sleep maybe I do double check pin state after getting a pin change, not always just assuming it was low so it must be now high, and on full start the interrupt to catch a switch event isn't enabled instantly so that along with startup time itself might block bouncing there, but it's not something I struggled with.  It could also be that clicky switches don't bounce as much as e-switches, or mine doesn't anyway.

brted
brted's picture
Offline
Last seen: 1 week 5 days ago
Joined: 01/12/2010 - 19:44
Posts: 2371
Location: Atlanta

I got mine today and it is really amazing. Two even bright green LED’s (probably too bright in the dark, but easy to turn off). Everything seemed clean and works fine. It does ignore a click every now and then when I try to turn it off. Click again and it goes off. The ramping is quick, easy, and intuitive. Great job!

hank
hank's picture
Offline
Last seen: 3 days 12 hours ago
Joined: 09/04/2011 - 21:52
Posts: 9592
Location: Berkeley, California

> reflector screw head

Ugly. OOOOgly.

Etex
Etex's picture
Offline
Last seen: 6 months 4 weeks ago
Joined: 09/29/2016 - 00:57
Posts: 280
Location: East Texas
Smittymojo wrote:
Can you tell what it is Etex?

It’s a slotted/phillips combo screwhead. I was able to loosen it without slippage using a #2 phillips with a more blunt tip (IOW, not sharp point). Takes a lot of down pressure while very slowly turning, to break it loose.

Flintrock
Offline
Last seen: 3 years 9 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Anyway, the way I was prepared to do it was just trigger the pin change interrupt, disable interrupts instantly, produce a small delay where with no interrupt enabled (would have been a minimum initial sleep in OTSM), then check the pin state.  If it's released after such an appropriate small delay, then consider it a short click done and finished, hmm I guess it's better to elave interrupts enabled and wait until you don't see two in short period, then check pin state, ; if still pressed, then go back to sleep with interrupts re-enabled to wait for the separate and future release.  But I just never had to do that.  Well technically I have a few microseconds with the interrupt disabled.

 

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 19 hours 46 min ago
Joined: 01/12/2013 - 14:40
Posts: 10759
Location: (469219) 2016 HO3

Tom E wrote:
Interesting TK. I assume it’s all timing dependent? So if an event comes in faster than humanly possible, they are rejected, etc.? Always wondered how well it worked as designed, but I’d think it’s dependent on quality of switches?

Yes, D4 baseline was NarsilM, so one in the same, just stripped out lot of things from Narsil not used for the D4, and added the basic functionality requested. Some things were streamlined as well. The debounce logic in Narsil was a carry over, not sure who provided it originally, maybe JohnnyC, not sure.

The issues I saw were mostly timing-dependent, and partly seemed random. The WDT-polling method generally doesn’t pick up really fast noise, but it can also miss the signal if it’s quick.

What worked for me was polling in the pin change interrupt, 16 times IIRC, spanning about 0.25 ms total, then going with the most popular result. This eliminated almost all the high-frequency noise but I still got spurious events sometimes like two “button pressed” events in a row without a “button released” event. So I got rid of that by ignoring any event which matched the previously-detected event. It could theoretically still do a “press, release, press” in under 1ms, but I haven’t seen it happen in practice.

Flintrock, I don’t think any of this applies to power switches or OTSM… just e-switches. The MCU already has power debouncing at boot (possibly also at wake?), and the drivers have lowpass components built in to eliminate power spikes.

Smittymojo
Offline
Last seen: 7 months 3 weeks ago
Joined: 07/31/2016 - 04:49
Posts: 186
Etex wrote:
Smittymojo wrote:
Can you tell what it is Etex?

It’s a slotted/phillips combo screwhead. I was able to loosen it without slippage using a #2 phillips with a more blunt tip (IOW, not sharp point). Takes a lot of down pressure while very slowly turning, to break it loose.

I feel silly, when I first looked at the picture of the screw head I thought it was full of some substance. Now I see that it was almost stripped out!

Flintrock
Offline
Last seen: 3 years 9 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

off topic, but here we are... OTSM isn't just about boot.  The power switch is acting exactly like an eswitch during much of the situation, because the mcu is still powered by the cap and running and there is no reboot.

 

Example the light is on steady.  Someone clicks "off" to do a medium click, clicking back on in 0.6 s.  What should happen is the software sees the off, goes into sleep cycles, sees the on, notes the 0.6 seconds, THEN does SOFT reboot (doesn't actually reboot the mcu at all, just restarts the code from a direct jmp call to main -- and stack pointer reset--, however this does disable interrupts briefly if I recall correctly)  with a medium press condition.

 

Ok, but if the initial off is quick off on off, then the code would see that on as a medium short press, would do the soft reboot, interrupts would likely be disabled missing the final off, and the light would try to run full power for 0.6 seconds off the cap without battery support.  It would drain, and restart triggering a long press condition.  

 

There are several very possible variations.  But they don't happen.  I think the difference is the big cap.  VERY high frequency bouncing won't bring the cap down enough to trigger anyway.  The switch needs to stay low for about 1ms to drain the cap enough to trigger.  By then maybe it's done bouncing.  Definitely it's possible to resolve this in hardware.  I'm not convinced that's enough RC to do it, but it might be, seeing as there's no problem.

saypat
saypat's picture
Offline
Last seen: 9 hours 29 min ago
Joined: 07/13/2011 - 20:32
Posts: 3579
Location: Calif

looks to me like a solid mass. It didn’t make any sense how u got that tip in there Smile

Etex
Etex's picture
Offline
Last seen: 6 months 4 weeks ago
Joined: 09/29/2016 - 00:57
Posts: 280
Location: East Texas

Yea, it’s a deep hole in center, lighting does make it difficult to tell, though.

Flintrock
Offline
Last seen: 3 years 9 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

In fact the similarity between OTSM and eswitch is exactly what led me to add experimental e-switch support to bistro-HD.  It uses the exact same code, with just a little more logic for different sequences.  It mght be that I got either lucky or more clever than I remember and I blocked against these cases in software in some ways I forgot(I did think about it some) or never realized.  If so I did it very succinctly.  Or it may be it's the hardware.

Jtm94
Offline
Last seen: 1 month 2 days ago
Joined: 02/22/2017 - 05:08
Posts: 400
Location: Pennsylvania

My friend gds95 received his and he has 2 different brightness indicator LEDs and he was upset I even pointed it out, but he knows to look out for the indicator acting funky so it can be reported if it becomes an issue.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 19 hours 46 min ago
Joined: 01/12/2013 - 14:40
Posts: 10759
Location: (469219) 2016 HO3
Flintrock wrote:
I think the difference is the big cap.

Exactly. It doesn’t need debounce logic because the signal doesn’t bounce. It does all that at a hardware level before the MCU firmware sees anything.

Older driver designs bounced, but that was fixed long before anyone here tried OTSM… and it wasn’t related to the switch; it bounced because of ringing from PWM on the FET.

The Miller
The Miller's picture
Offline
Last seen: 1 year 10 months ago
Joined: 12/14/2015 - 12:08
Posts: 9908
Location: Charente France

October first is Chinese National day followed by Golden Week Holiday. This means almost all of China is not working September 30th till October 8th due to travels and having a holiday.
Thorfire aims at sending out the Q8 before that, but to be on the safe side it is better to expect shipping at the latest inline with what the Banggood listing said from the beginning October 10th.
Of course we will announce it when shipping is about to commence.

Dimking
Offline
Last seen: 2 months 5 hours ago
Joined: 01/16/2013 - 12:52
Posts: 227
Location: SW Russia

I think lower current through the switch leds will solve the problem. Guess they blew up from overheating (no big news I guess)
Can’t they just swap the resistors and leave the leds the same?

JasonWW
JasonWW's picture
Offline
Last seen: 3 days 8 hours ago
Joined: 10/22/2016 - 11:41
Posts: 12871
Location: Houston Texas

Some people have gone to a higher current and got non working leds to work again. Swapping the 15k resistor with a 10k.

There is still something wonky about the pcb, though. Something is making the leds be different brightnesses even when the leds are swapped for a matched set.

Then there are the rare switch issues when turning off the light which might be related to the switch. We don’t know yet.

So I think TF is smart to just swap to a different switch assembly pcb. It might fix several things at once.

Texas Ace Lumen Tube and JoshK Sphere calibrated with Maukka lights

Click this to go to signature links. I'm still around, just not reading many new threads.

Pages