SwissMicros Calculator Forum

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

Actually, it almost certainly *is* autorepeat.

You can slow that down by going into [SHIFT] [SETUP] -> Settings -> Slow autorepeat

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

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

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.

Well, here does start project management. At least it has to ...
Let's hope it knows it.

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 ".").

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?

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.

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?