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
Keyboard debouncing
Re: Keyboard debouncing
Actually, it almost certainly *is* autorepeat.
You can slow that down by going into [SHIFT] [SETUP] -> Settings -> Slow 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.
Re: Keyboard debouncing
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
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
Re: Keyboard debouncing
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).
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
Re: Keyboard debouncing
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.
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
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Re: Keyboard debouncing
Well, here does start project management. At least it has to ...
Let's hope it knows it.
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
Re: Keyboard debouncing
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 ".").
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 ".").
Re: Keyboard debouncing
No offense or disrespect meant, but I am not sure I agree with that statement.rprosperi wrote: ↑Fri Feb 02, 2018 8:49 pmSince 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.
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?
Re: Keyboard debouncing
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.
Jose Mesquita
http://www.radiomuseum.org/collection/j ... quita.html
http://www.radiomuseum.org/collection/j ... quita.html
Re: Keyboard debouncing
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?