Keyboard debouncing

If you're having problems with the hardware of a DM42, post about them here.
Dave Britten
Posts: 71
Joined: Wed Jun 14, 2017 7:27 pm

Re: Keyboard debouncing

Post by Dave Britten » Thu Nov 08, 2018 1:33 pm

Augusto.Berg wrote:
Tue Nov 06, 2018 10:05 am
I bought one that is on the way and now I'm really worried about this "bug" :shock:

Waiting for news... :|
I wouldn't lose too much sleep over it. It's a very minor thing, and I think it was more common with some of the early production models like mine. I've cleaned the keys out, and it's pretty rare now, usually only affecting Shift or the arrow keys. It's just a bit annoying when it happens, because it seems like something that could be very easily fixed in software with only about 5-10 ms of debounce lockout.

tycho
Posts: 32
Joined: Sun Nov 05, 2017 3:09 pm
Location: Norway

Re: Keyboard debouncing

Post by tycho » Mon Feb 04, 2019 11:01 am

I think we should still keep this topic warm, because the problem remains for me on some number keys, although rarely. I have sample SN: 356.

I recently updated the FW straight from 3.5 to 3.12, and I noticed it more often - although I also did the "key softening" routine and use the calculator more. The "Slow auto repeat" seems to have no effect, i.e. not slower auto repeat, and not shorter delay before repeat, which is too short (and sometimes causes unwanted debouncing itself).

Maybe a coincident, but lately I have seen the debouncing problem ONLY with "Slow auto repeat" ON!
Please make the "Slow auto repeat" actually have an effect, and increase the delay before repeat.

Related: Why is the auto repeat so slow in menus? Here it would be nice to have more speed.
"The Answer to the Great Question... Of Life, the Universe and Everything... Is... DM42" ― Adam Douglas

boessu
Posts: 15
Joined: Mon Jan 28, 2019 9:40 pm

Re: Keyboard debouncing

Post by boessu » Mon Feb 04, 2019 9:18 pm

tycho wrote:
Mon Feb 04, 2019 11:01 am
I think we should still keep this topic warm, because the problem remains for me on some number keys, although rarely. I have sample SN: 356.
I think the topic is still warm.
I have SN:03279. I got it last week and I noted also this kind of problems after using it a bit. First I had the problem that sometimes a key won't be registered. But that's maybe also a "stiffy"-problem. The key domes have some hub and if you feel a "click", you feel the small spring dome and not the contact you expect. If the keys are a bit stiffer, a "click" doesn't mean it results in a contact if you press with a comfortable force (sounds a bit silly, but that's possible).

But on the beginning, the "-" was simply unusable as it flippered the number in sign. I also have the problems on some numbers like you. Sometimes I have it more, sometimes I have it less. That really points on debouncing.

There are basically three possibilities for me:
  1. The software has a debouncing problem. Software can be easily fixed... however I didn't saw any debouncing code on github. Maybe I just didn't found it... Hopefully it is in the part of the firmware you can easily update.
  2. There is a hardware problem. I hope that's not the case here, but... I noted the PCB isn't fixed like the HP's are (or other keyboard in phones I'm personally know of from the past...). The HP's pressed the board on the keys and melted the tips of the plastic to fix them. This is not really an elegant way and I wouldn't do that, but that worked. The DM42 is just fixed with the flat screws below the display and with hooks on the bottom. I would expect a few more screws or something in-between (The more "high quality" way I know is to fix it with a few screws, of course). Maybe that's not a issue as the PCB seems rather high quality and thick. But as it seems the problem happens often somewhere around the numbers, it could be a stability problem of the PCB. The keys in the middle area would get a bigger debouncing problem then. I didn't noted the problem on the topper level where the screws are... Even if this is the case: it's possible that this results in heavier debouncing which can be fixed with software. At least there is a chance.
  3. I got the lucky punch and they sent me a device which was returned from another customer without reason. I noted some older customers here in this forum have a bigger S/N than I. That would be a bit of a bummer... But anyhow the effect is only noticeable if you really use the calculator. So a 5-minute-function-test wouldn't fail and if that would be the case, it's easily understandable why SwissMicros didn't found a problem in the device.
Beside of some notes here, I really don't think this is a problem of a small batch. The switches make a high quality impression on me. I simply don't believe the switches (that much of them, all somewhere in the number areas) are really the problem. Since you've also noticed that in the number area like I, it is far more feasible that is somewhere on 2.). But this also means there is the chance that it can be fixed by software.

So keep it warm...

User avatar
Jaymos
Posts: 355
Joined: Sun Nov 04, 2018 6:03 pm
Location: Cape Town

Re: Keyboard debouncing

Post by Jaymos » Tue Feb 05, 2019 12:11 pm

StreakyCobra wrote:
Tue Oct 16, 2018 1:59 pm

I often find myself typing numbers at the same time that I'm thinking of a problem...

Maybe I'm doing something wrong and I'm the only one to have this problem with "enter", but for this use at least "exit" is changing my life right know :-)
No, you are not alone. Since discovery in this thread of EXIT entering a number into x only, this is becoming a pleasant habit. I think you described the thought process well for my mind too. Maybe I used the 28C too much long time ago, and this method positively gets the number into x only and allows my focus on the problem instead of on the stack duplication.

More proof that you are not alone, is that the iOS ‘42s’ Free42 implementation by Byron Foster of a few years back has a ‘no ENTER stack lift’ option, which I set years ago already. This is my goto Free42 implementation on iOS. On the hardware 42S and DM42 this is now done with EXIT.
Jaco Mostert
Elec Eng, South Africa
WP34C, HP42S, DM42 for complex math; 35S, 28C, 32Sii, WP34S, EL-506P, EL-W506, PB700; owned FX702P & 11C; used 67 & 85. iOS: 42s (Byron), Free42, WP31S/34S, HCalc.
43S operators right. DM42 sn. 03818.

cdmackay
Posts: 90
Joined: Fri Oct 05, 2018 6:33 pm
Location: Cambridge, UK
Contact:

Re: Keyboard debouncing

Post by cdmackay » Tue Feb 05, 2019 4:44 pm

Jaymos wrote:
Tue Feb 05, 2019 12:11 pm
No, you are not alone. Since discovery in this thread of EXIT entering a number into x only, this is becoming a pleasant habit. I think you described the thought process well for my mind too. Maybe I used the 28C too much long time ago, and this method positively gets the number into x only and allows my focus on the problem instead of on the stack duplication.
I may be missing the point, but an alternative might be to get out of the habit of pressing ENTER immediately after typing a number, and instead only use it before typing a second number.

And if you don't need to input any more numbers, you then immediately press the operator etc key you need without pressing ENTER for the last number input.
Cambridge, UK
41CL 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)

User avatar
ijabbott
Posts: 165
Joined: Fri Dec 15, 2017 1:34 pm
Location: GB-MAN

Re: Keyboard debouncing

Post by ijabbott » Tue Feb 05, 2019 5:59 pm

There are definitely places where the habit of using EXIT to enter a number can bite you as it has side effects. A safer habit is to press X<>Y twice, as that won't have the side effect of exiting menus, although it does have the side effect of setting LASTx to the number you just entered. Another option is SHIFT SHOW, but that is harder to type.

Thomas Okken
Posts: 619
Joined: Tue May 02, 2017 3:48 pm
Contact:

Re: Keyboard debouncing

Post by Thomas Okken » Tue Feb 05, 2019 11:17 pm

X<>Y does not affect LASTX

cdmackay
Posts: 90
Joined: Fri Oct 05, 2018 6:33 pm
Location: Cambridge, UK
Contact:

Re: Keyboard debouncing

Post by cdmackay » Tue Feb 05, 2019 11:49 pm

ijabbott wrote:
Tue Feb 05, 2019 5:59 pm
There are definitely places where the habit of using EXIT to enter a number can bite you as it has side effects. A safer habit is to press X<>Y twice
I don't quite get what people are trying to achieve here, would you please explain?

i.e. what state is different after pressing X<>Y twice, compared to not pressing it at all?

I can see that we're no longer editing the line, the trailing edit cursor goes, but what else does that affect? What else is different? How is it useful?

[not trying to be clever, just trying to understand the point]
Cambridge, UK
41CL 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R :)

rprosperi
Posts: 502
Joined: Mon Apr 24, 2017 5:48 pm
Location: New York

Re: Keyboard debouncing

Post by rprosperi » Wed Feb 06, 2019 2:47 am

cdmackay wrote:
Tue Feb 05, 2019 11:49 pm
ijabbott wrote:
Tue Feb 05, 2019 5:59 pm
There are definitely places where the habit of using EXIT to enter a number can bite you as it has side effects. A safer habit is to press X<>Y twice
I don't quite get what people are trying to achieve here, would you please explain?

i.e. what state is different after pressing X<>Y twice, compared to not pressing it at all?

I can see that we're no longer editing the line, the trailing edit cursor goes, but what else does that affect? What else is different? How is it useful?

[not trying to be clever, just trying to understand the point]
I'm not 100% why folks are advocating these alternates (there seem to be multiple points being made) but the main difference is that [Enter] disables stack-lift, so the next thing entered replaces X without pushing the stack up, while the other methods terminate entry with stack lift enabled. To me, there are corner cases where this can make a difference, but typically it's not important. The usual reason folks pursue this is if they learned RPL before RPN, where all terminated entries always enable stack lift. These tricks better simulate the behavior of RPL.
--bob p

DM42: β00071 & 00282

User avatar
akaTB
Posts: 307
Joined: Tue May 02, 2017 11:56 am

Re: Keyboard debouncing

Post by akaTB » Wed Feb 06, 2019 6:52 am

rprosperi wrote:
Wed Feb 06, 2019 2:47 am

The usual reason folks pursue this is if they learned RPL before RPN, where all terminated entries always enable stack lift. These tricks better simulate the behavior of RPL.
Correct, and that's the main reason why we should avoid this and show them the light. :lol:
Greetings,
    Massimo

-+×÷ left is right and right is wrong :twisted: Casted in gold

Post Reply