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