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.
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.
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!
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.
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 mediumshort 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.
Even the SW LED’s seem to be closer in brightness, Batt check voltage at 4.0 to 3.9
