Keyboard debouncing

If you're having problems with the hardware of a DM41X or DM42, post about them here.
Post Reply
etn
Posts: 22
Joined: Sun Dec 10, 2017 2:14 pm

Keyboard debouncing

Post by etn »

Do you guys also notice the following behavior? when pressing a key, it sometimes repeats itself several times "instantaneously".
This is not auto-repeat, as it happens within about half a second of the 1st press.
It seems more like key bouncing to me. A longer "delay" (or integration time constant maybe?) in the debouncing algorithm should solve the problem.

Thanks!
Etienne
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Keyboard debouncing

Post by grsbanks »

Actually, it almost certainly *is* autorepeat.

You can slow that down by going into [SHIFT] [SETUP] -> Settings -> Slow autorepeat
There are only 10 kinds of people in the world: those who understand binary and those who do not.
etn
Posts: 22
Joined: Sun Dec 10, 2017 2:14 pm

Re: Keyboard debouncing

Post by etn »

I have had the Slow Autorepeat setting in place since more or less day 1 I got the calculator.

What I am talking about is definitely not autorepeat. Among others, I had this behavior happening with the ENTER key: I typed a number then pressed ENTER. I "suddenly" (it all happened in a fraction of a second) got the entire stack filled with that number.

This cannot be autorepeat, as there is no autorepeat on ENTER. (try entering a number and keep the ENTER key pressed: the calc displays "ENTER" and remains there, but never fills the stack!)

Thanks
Etienne
c785
Posts: 84
Joined: Mon Apr 24, 2017 11:22 pm

Re: Keyboard debouncing

Post by c785 »

I can confirm this behaviour. It's definitely too fast even for "fast" autorepeat. On my calculator, it appears most often on the key "3", which, incidentally, is also the one that has the most "mushy" click point and rather different feel from most other keys.

It's a shame we haven't got access to the OS source code yet (or have we)? If we had, this problem would be solved in a matter of hours (or days at most).
DM42 #84
rprosperi
Posts: 1698
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Keyboard debouncing

Post by rprosperi »

Since this occurs on only a very small number of keys on a very small number of machines, it seems logical (to me) that the issue is more likely some dirt or contaminant in the affected keyboards and cleaning them inside (as detailed in a couple different threads here) should resolve the problem. If the issue was a fundamental key-bounce design (or code) flaw, nearly all machines and keys on them would be affected and there would be hundreds of complaints by now.

Have you guys looked into that?

And here's a question for folks that want to take the SM code (when available) and start tweaking for their own needs/issues/desires:

I'd assume that using modified code invalidates any warranty, but more importantly that problems encountered using modified code should not be reported and treated as SM product bugs, right?

Obviously true improvements are possible (in fact likely) but they would need to be submitted back to SM to assess and if approved, integrated for later release in a future update.

Hopefully (this is a request) people will not publically share their modified versions without clearly identifying them (on the About screen) and documenting all differences.

Also, it would be very useful (IMHO) if SM would document their desired policies and procedures regarding modified versions (e.g. Warranty impact, possibly a new sub-forum here, etc.) once the code has been released; it seems lots of folks are eager to roll their own DM42 special variant.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: Keyboard debouncing

Post by Walter »

Well, here does start project management. At least it has to ... ;)
Let's hope it knows it.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: Keyboard debouncing

Post by ijabbott »

I noticed the key-bouncing problem when I first got the calculator, but I haven't noticed it much recently. I don't know whether the improvement is due to "bedding in" of the keyboard, or due to firmware updates.

I do occasionally get a bounce on releasing the SHOW (shift '.') key, leading to a stack lift with "." mistyped into the X register editing line (displayed as "0." with the cursor to the right of the ".").
etn
Posts: 22
Joined: Sun Dec 10, 2017 2:14 pm

Re: Keyboard debouncing

Post by etn »

rprosperi wrote:
Fri Feb 02, 2018 8:49 pm
Since this occurs on only a very small number of keys on a very small number of machines, it seems logical (to me) that the issue is more likely some dirt or contaminant in the affected keyboards and cleaning them inside (as detailed in a couple different threads here) should resolve the problem. If the issue was a fundamental key-bounce design (or code) flaw, nearly all machines and keys on them would be affected and there would be hundreds of complaints by now.
No offense or disrespect meant, but I am not sure I agree with that statement.
There might be some variations due to production tolerances, usage model (or any other reason - even possibly contaminants, although I think we have too little information at this point to draw a definite conclusion that this is indeed the root cause of the problem.)
The key bounce design (or code) as it is today might catch only, say, 99% of all possible use cases. This accounts for the little amount of occurrence of the bounce issue. A slight change in code might enable covering for 100% off all cases.

I can't help but draw a parallel with what happens from time to time in my industry (semiconductor): we design a part, launch it to production, everything looks fine and after a couple million units sold, we suddenly get a failed unit returned by a customer. After analysis it turns out that there are rare occurrences of issues not covered by the production test program. Is it a fundamental design flaw? no. Just some sample variation due to an external reason (production tolerance in this case) which is solved by modifying the program. Note that we do not address the root cause: this is generally either unrealistic or uneconomic. We address only its effects - but it is sufficient to solve the issue.

Does this make sense?
User avatar
Jebem
Posts: 21
Joined: Sun Jul 23, 2017 12:21 am
Location: Portugal

Re: Keyboard debouncing

Post by Jebem »

etn wrote:
Tue Feb 06, 2018 9:32 am
Does this make sense?
Yes it does to me. My experience in the field is the same. Hardware design specs only exists in paper. Implementation involves tolerances that may or may not being violated on some production batches or even single units. This introduces "hardware bugs" that in many cases can be fixed by software alone.
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: Keyboard debouncing

Post by ijabbott »

I'm wondering whether the ENTER key is more likely to bounce than the other keys due to it having two switches in parallel underneath the key top. Or perhaps only one of the switches is wired up and the other one is just for balance?
Post Reply