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.
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.
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.
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. 
Even the SW LED’s seem to be closer in brightness, Batt check voltage at 4.0 to 3.9
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.
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.
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.
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.
It’s no wonder some may have a little trouble stripping reflector screw heads, getting them out.
I have not touched this one.
Can you tell what it is Etex?
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.
I understood some of those words, TK. 
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.
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.
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!
> reflector screw head
Ugly. OOOOgly.
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.
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.
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.
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!